Java-micro – A lightweight framework for building Java microservices | Hacker News Reader

Java-micro – A lightweight framework for building Java microservices

github.com

68 pointsdomwong13 comments

This looks a lot like dropwizard.io. There are a few differences, like Flyway over Liquibase for DB migrations, and Guice for dependency injection, etc. DW is pretty active and has a reasonable community; I'm curious why Sixt created this.

Can't find it in the introduction, how's authentication and authorization handled?

The framework does not handle authentication and authorization

I'm kinda ok with that too. Spring tries to provide that kind of feature. For my present work I can't use it. Rights are document based. Authentication isn't even possible because any given doc could actually be allowed to the public or tightened down to a specific group or groups. So here I am leaving a huge piece of the web framework on the table.

not claiming that spring does it well but handling the user identity across microservices is kind of the major pain point for me.

Nice to have side-by-side implementations in Go and Java that can work together.

It does appear to deliberately disable pipelining / connection pooling though (setting Connection: close) : https://github.com/Sixt/java-micro/blob/389a7ee4da2e50888bf4...

That would make each new rpc call a new socket connection, which would limit how well it could scale.

This is a byproduct of the early implementation of go-micro which did not handle keepalives. Basically go-micro would handle a request and then close its side of the connection. It now handles that more gracefully so pipelining/connection pooling could be enabled. One for someone to PR ;)

I have seriously considered open sourcing my companies framework but just don't have the time. We have an awesome message bus that will route messages to AMQP, zeromq or Kafka and you can convert the returned messages into futures (guava),observables, or plugin your own reactive deferred object (aka future Java 9 flow).

We have a cool config framework as well as a weird jdbc wrapper (we now mainly use jooq).

I also have an ocaml app that updates the maven dependecies (pom file) for continuous deployment as the maven version plugin is too slow.

Someday...

How does this compare to for example Lagom (http://www.lagomframework.com) ?

This reminds me of Microprofile.io... a cool industry gathering trying to do the same thing. Really neat to see the Go integration right from the start.

I'm genuinely curious: what is considered light-weight in the land of IAbstractFactoryCreatorBeanSingletonProviderDecorator? I.e. how do you consolidate OOP abstraction practices and conciseness, performance and usability?

That is a dank meme at this point. Even if you use a complex framework like Spring, your code won't need to do any of this. At worst you program to contracts, interfaces. At best Sprong does all the heavy lifting without any implementation. For example with just an interface and a few annotations you can have all of you data late provided by spring.

Thank you for answering the question seriously. All the down-votes were giving me the impression that the answer was "you don't". It's good to hear/read that the Java community is moving on from those practices.

Reply on news.ycombinator.com