
Java-micro – A lightweight framework for building Java microservices - domwong
https://github.com/sixt/java-micro
======
javajosh
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. 

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

~~~
chuhnk
The framework does not handle authentication and authorization

~~~
virmundi
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. 

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

------
tyingq
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...](https://github.com/Sixt/java-
micro/blob/389a7ee4da2e50888bf418d072ece91b62fd6725/src/main/java/com/sixt/service/framework/rpc/RpcClient.java#L81)

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

~~~
chuhnk
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 ;)

------
agentgt
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...

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

------
exabrial
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. 

------
thwd
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? 

~~~
virmundi
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. 

~~~
thwd
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.