I currently have a Vert.x codebase. I was using Golang, but Golang kinda sucks and doesn't have a good ORM. But apparently, Vert.x doesn't have a good ORM either, primarily because Vert.x is non-blocking and most ORMs for Java were based on blocking APIs.
Anyhow, I have a specific question - I read that Hibernate/JPA could be used with Vert.x - what we could do is put the Hibernate calls in a different Verticle and then it would be non-blocking.
Is that a good idea? Can someone show an example of doing that with 2 different Vert.x verticles?
If it's not a good idea, what might be a good ORM to use? Naked SQL calls sounds cool at first, but for migrations and stuff, might get kinda crazy.
@tsegismont, as he usually does, already provided a good solution in the comments. I would like just to clarify the following sentence:
I read that Hibernate/JPA could be used with Vert.x - what we could do is put the Hibernate calls in a different Verticle and then it would be non-blocking
There is a true and a false part there:
Hibernate/JPA could be used with Vert.x
True. By putting blocking code in a worker verticle you don't block Vert.x event loop, and that allows frameworks based on JDBC to work with Vert.x
put the Hibernate calls in a different Verticle and then it would be non-blocking
False. You don't make Hibernate non-blocking. JDBC is blocking in it's nature, and there's not much that can be done to solve that (although R2DBC is a nice initiative). You'll use the same thread pool you were using before, with the same limitations.