GraphQL had been on my ‘one to watch’ list for some time. Upon casual glances it looked both expensive to implement and lacked any burning issue it could solve (at least for me). So there it sat. Then GitHub announced they were adopting GraphQL for their next generation public api, and around the same time, our micro-service based product started having growing pains. Those growing pains came from the disparate API jungle our consumers needed to navigate. Was a GraphQL server the answer?
Running a Neo4j Graph Database alongside a traditional JPA relational database within a SpringBoot micro-service can help solve a lot of problems. This is a great way to leverage the power of a graph database within an enterprise environment where you cannot escape the RDBMS entirely.
Having worked for a large global corporation for over 10 years I’ve seen and felt the impact of corporate performance reviews first hand. Every year there is some re-launch or ‘improvement’ in the process, but every year the results are the same; a feeling it really wasn’t worth all the effort. So what’s wrong?
If you haven’t yet read about Graph Databases you really should. While many traditional and newer ‘NoSQL’ databases provide a lot of brawn, Graph databases really are the brains of the database world. OpenCypher, recently announced by Neo Technology, is a query language for graph databases. It will bring Graph Databases into mainstream.
Big fan of using the Builder Pattern for my Java domain objects. Builders are also becoming increasingly common in other libraries (e.g. guava). What struck me recently was the variations in Builder pattern implementation styles. Here I will summarise the two most common implementation styles, and introduce my own variation I call the ‘Soulmate Builder Pattern’.
Have you ever just wanted to load multiline properties values into Java and sank in your seat at the choices available? I had the exact same ‘sigh’ on a new lightweight project when I needed to store some database statements. After quickly refusing to accept the usual suspects (Java string concatenation, XML bloat, properties files or JSon escape ugliness) I thought it shouldn’t be too hard to load from a Markdown file. No frameworks, no more dependencies, just a few lines and simple rule for beautifully maintainable multiline properties.
The react site itself has a very good getting started tutorial but I also found a few quality blogs that were useful for getting quick overviews and a better understanding.