Problems of Java ORM in a microservice architecture

By microservice architecture here I mean an app split in independent parts, connected via MQ, database, internal RPC or independent APIs. Usually deployed as containerized microapps onto a horizontally scaled cluster.

Main problems with ORM

Different technology stack

Most likely you have a mixed tech stack, using different tech/framework/language for different services. Some parts are JVM apps, but others are easier to write using Golang or Python. In some cases you use an external 3rd party app, customized for your needs.

Lifecycle and backward compatibility

You probably don’t want to restart whole cluster, every single service, just to upgrade some part of the db layer. So you have to deal with different versions of Data Models, that should live together in same shared environment (remember «caching»)

Subset of data

Another important moment that each microservice operates own subset of data, and does different types of operations against the data. It’s even common to split app into microservices that do only following:

  • put data into db from a 3rd party storage
  • process/transform stored data
  • display data for end user



RESTful using Spring Framework

I don’t need to say that RESTful web services are very popular this days. So, you need it, for sure, but what to choose? I’ve tried different Java frameworks for REST, most times it was Jersey and Spring MVC, and think that for most cases Spring is the best option for building RESTful applications using Java.

If you already have a Spring app, then you don’t need to make complex configuration to start implementing RESTful API with Spring. Just configure view resolver for JSON, and use standard annotations like:


Hsoy Templates – client- and server side templating

Introducing “Hsoy Templates”, a html templating library for modern web. The main goal was to make a templating library with easy to use syntax, that can be used on both server and client side. It have HAML syntax, and compiles into Java on server side and JavaScript on client side.

Actually it’s a version of Google Closure Templates (.soy templates) with HAML syntax.

Why you need this?

In modern web development it’s very common to update some parts of current page by data received from server, but the problem that it’s annoying to write and support same HTML view two times – for Client and for Server. Just breaks DRY principle.

Hsoy Templates gives you a way to write such templates just once, and use it on client-side, and on backend.


  • one template (a *.hsoy file)
  • HAML syntax (see
  • fast
    • compiled into Java (so can be used from Groovy, Scala, Clojure, etc)
    • compiled into Javascript (so can be used from Node.js)
  • based on Google Closure Templates library
  • commercial friendly (Apache 2.0 licence)

Niche for Scala

At last post I mentioned that i’m not using Scala because of academic nature, syntax and so on. BTW, i’ve different used programming languages, sometimes with worst syntax. I spent much time on Perl. And also i’ve used Q programing language. You know, Scala have much better syntax :) I only don’t understand why they are drop standard java syntax for standard cases? Why

for(i <- mylist ){

is better than standard:

for (i: mylist) {

, etc. I see only one reason: to be different. What for?

But actually it doesn’t matter. I’ve used Perl and Q only because they have their niche, where they’re works best (ok, perl lost it now, but you know, when I used it, 10 years ago it has it). But I don’t understand niche of Scala. What is it for? If I want to develop fast code – i will choose Java. If I’m looking for syntax sugar and easy development – Groovy. Want functional code – choose Clojure. It’s just my current vision.

I definitely will try Scale one more time. Just because i see that many interesting project are using it, GridGain for example. But first I need to understand what project better fits for Scala. Can someone help me with it?