I like going to conferences. One of my regular conferences remains Devoxx, but I’ve done a lot of other conferences the last couple of years. However, over the years, I’ve noticed a very unsettling trend: the prices of conferences have risen each year. And not by a little. Whether the content quality has equally risen is debatable, but it seems like there’s no stopping in the rise of the price of admission to one of the most crucial parts of IT: learning.
Sometimes you want a bit more resilience in your application and not depend on a single database instance. There are different ways you can do this, but recently I’ve come across a really simple way of enabling failover and load-balancing to any Java backend using JDBC. The library is called HA-JDBC and allows you to transparently route calls to multiple datasources. It will automatically replicate all write calls (using a master-slave mechanism) and load-balance all read calls. If a datasource gets dropped, it can also rebuild a datasource when it gets back up.
I thought it would be nice to see whether I could add Spring Boot support which transparently enables HA-JDBC support. And thanks to the simplicity of Spring Boot, it wasn’t that hard.
Those who are familiar with databases and persistence have probably had the same discussion like I have had a couple of times over the last couple of years:
Do you use numeric or String values as an UUID?
Having done a lot of distributed, multi-tenant development, my stance on this is very clear: I prefer String. Or better said, I prefer UUIDs.
When it comes to building integration tests for web applications, nothing beats Geb for me. The concise and readable syntax, together with excellent Spock support, makes testing a web application a joy. For those not acquainted with Geb, it’s a Groovy library on top of Selenium that provides a more easier API to interact with the browser from your unit tests.
In my previous articles I compared 4 frameworks commonly used in communicating with MongoDB from the JVM and found out that in that use-case, Spring Data for MongoDB was the easiest solution. However I did make the remark that it doesn’t use the GeoJSON format to store geolocation coordinates and geometries.
I tried to add GeoJSON support before, but couldn’t get the conversion to work propertly. But after some extensive searching I found out that the reason for it not working was my use of Spring Boot: its autoconfiguration for MongoDB does not support custom conversion out of the box.