4 ms·
I have to use vertx for work. It's not my favorite. It's not Maven friendly. It's not Spring friendly. Callback spaghetti is hard to read and maintain. It use
by eip 14y ago
I have to use vertx for work. It's not my favorite.
It's not Maven friendly. It's not Spring friendly. Callback spaghetti is hard to read and maintain.
It uses it's own half baked messaging framework instead of something more powerful like AMQP.
The documentation is confusing and often times self contradictory. ("Worker verticles use threadpools" vs "All verticles are strictly single threaded")
It encourages message passing and queuing even when it doesn't make sense. That leads to code that is very hard to understand and even harder to debug.
It uses Hazelcast for in memory datagrid but doesn't explain it at all in the docs. It also doesn't expose any of the useful Hazelcast APIs. So unless you are already familiar with Hazelcast you will miss most of its benefits.
I think Spring Integration is a much better solution to the problems vertx tries to solve.
That fact that vertx tries to be polyglot friendly doesn't really seem like a benefit to me either. Just makes feature development much slower.
- voidlogic 14y agospartango: "Vert.x is a decidedly "modern" Java codebase" eip: "[Vert.x] Callback spaghetti is hard to read and maintain." My take, "modern" = like node.js = Callback spaghetti = hard to read and maintain Of course this is coming from someone who hates callbacks, javascript and has ported node.js apps to Go and finds them faster and more maintainable in that form.