Spring Boot and Dropwizard in microservices d...

ABOUT US
BLOG

http://www.schibsted.pl/blog/spring-boot-and-d...

NEWS

CAREER

CONTACT

DANIEL JAGIELSKI

SPRING BOOT AND

DROPWIZARD IN
MICROSERVICES
DEVELOPMENT
1 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

In this article I will compare these two frameworks from my

teams needs perspective. You can treat it as an opinionated guide
on how to choose between them when you have similar
requirements.
ABOUT THEPROJECT
The SPiD team, that I am currently working for, was established in STP in
September last year. Since the beginning, our goal is to build a payment platform,
that integrates various payment types. We have justhadrst production release in
June this year, and the scope of that release included some basic functionalities.
The main objective now is to provide a functionality of Peer-to-Peer payments.
This also requires some surrounding features like depositing money into the
system using credit card, transferring it between the users, or withdrawing it to
the real bank account. When the system is stable and gets broader audience we
plan to extend it with new features and payment types. In order to fulll our goal
we also need to provide a custom users wallet solution that is something
similar to Google Wallet.
Our decision was to becloud based and use Amazon Web Services like EC2, SQS
queues, S3 and their other goodies. One of our main concerns about building that
platform wasto make it as exible and agile with developing new services and
functionalities as possible. When we concluded all our objectives, it occurred that
the most appropriate, and probably the only right solution for us was to take the
microservices approach.

SYSTEM ARCHITECTURE
Our system is built of several different modules. Most of them use REST to
communicate with each other. As it is for now, we have 3 types of components:

Order/Payment module the main entry point of the system, something like a
governor for other services. That will be the only public component that is meant to be
used by end users of the platform. It handles all requests from the users and perform
proper operations on other internal components.

PPAs which in our terminology means Payment Provider Adapter. Each of these
components is responsible for communication with the provider of particular payment type.
These providers are called PSPs (Payment Service Provider) in our dictionary and most of
them are 3rd parties, but we also built one called SpidCash which is responsible for

2 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

handling users wallets. Every PPA uses a different communication protocol to reach its
vendor. As presented on the design picture Telepay PPA, supporting withdrawal of money
to the real bank accounts, utilizes SFTP, Klarna PPA, which handles invoice transactions,
uses XML RPC, Payex PPA, that serves credit card transactions, is based upon SOAP and
nally our internal wallet solution SpidCash uses REST.

Callback server this is the third type of our services its only responsibility is to
expose an endpoint for callback communication from PSPs, and pass that information to a
particular PPA, using SQS queues. PPA will handle that message and, if needed, pass it
down in the ow to other components.

As presented in thepicture below, some of our modules are based on Spring

Boot(referred to as SB) and some on Dropwizard(referred to as DW). Initially the
platform skeleton was based only on Dropwizard, but since it is a microservice
world, we decided to try Spring Boot for new services, and hence we can compare
how we feel about working with both of them.

-Architecture overview

DROPWIZARD (DW)
This project was founded rst. In overall I would say DW is just a little bit of glue
code between popular libraries that were commonly used in web apps
development for a while, and nothing more than that. It does not come with any
3 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

enterprise heavy stuff, that couldprobably slow it down. It is incredibly fast and
easy to learn. It glues Jetty for HTTP, Jackson for JSON, Jersey for REST,
optionally Hibernate or JDBI for persistence support, Metrics and others like
Guava or Logback.
It is nicely aligned with the microservices way of thinking. Its authors had this
brilliant idea with revolutionary way of building and running web applications. DW
allows you to build one jar, that contains all needed dependencies, so that means
you do not have to deploy it inside any specic application container or server it
is runnable from a basic console with use of java jar.

SPRING BOOT (SB)

WhenDW was born, Spring Framework was already somewhere out there. It was
very popular and had a well grounded position in Java web dev world. Due to the
complexity of Spring Framework, DW was much easier to use with microservices.
To be honest, when I was learning Spring few years ago, it was quite difcult, and
it took me some time to feel comfortable with it. There were tons of XMLs and
other conguration that had to be done in order to run your application. They
needed something to lower the threshold of entrance, which was very low in
Dropwizard.
Maybe one day, one of the Spring team sat down, looked at what DW offeredand
got really amazed. They wereso amazed that they told their colleagues Hey, we
should denitely gothat way, because that is how peoplewant to do things right
now.
And they did. They adopted many of DW ideas for example the concept of
self-runnable jar with all dependencies or healthchecks support. They called it
Spring Boot, and I would say it wasrather an evolutionary step in Spring
Framework history. They didnt clone Dropwizard they adopted these nice ideas
to their existing platform, so that when using SB you wouldt loose any of Spring
Framework power and abilities it had before.

COMPARISON AREAS
I was thinking a bit about some metaphor for these two frameworks, and the best
one that I came up with is based on Marvel characters.
I can identify Dropwizard as Spiderman it is just a regular guy from our
neighbourhood that has perfect combat skills, and simply glues some things
together.

4 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

Spring Boot on the other hand, can be considered as the Iron Man a billionaire
with the latest high-tech stuff packed inside one well suited armor, that may look
heavy, butsomehow doesnt cause any agility and quickness issues.
Lets return back to the project and present areas which are important tous, that
will be used as comparison areas of Spring Boot and Dropwizard:

REST support our components use REST for internal communication.We also expose
RESTful API to ourclients.

DI support it may be controversial right now, because of the trend to get rid of such
features, but inside our team we agreed that we like it, and we can get great benet out of
it.

Persistence Support we dont want to create SQLs, and extract result sets manually
because we store high amount of various type of data. Thats why we need an ORM.

Transaction support we have some volatile areas in our platform that need to be
handled inside transactions and it is good when we dont have to create them manually.

Conguration management since we are cloud-based and have multiple running

environments we need good way to manage module conguration.

Dependency management one of our main objective is to compile our modules with
maven-enforcer plugin, and we invest our time in order to have a clean classpath and to
omit dependencyhell.

Metrics we want to have an insight into our application and gather some stats, so any
kind of support for it is very appreciated.

Good Community Support it is quite obvious that sooner or later you will need
somebody to give you a hand with doing something, and that is very important to have live
community around frameworks that you use.

REST SUPPORT
As mentioned above, we use REST for communication between our microservices.
To achieve this, we decided to use theJersey 2 library, because it is fully
compatible with JAX-RS. One of our principles is that whenever possible we
should code towards specication, rather than be tightly coupled with one of
libraries.
Starting from Dropwizard when we entered a project, there was already a basic
skeleton created with the latest version of DW at the time version 0.7.1.

5 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

However, the problem wasthat this version wastightly coupled with the legacy
version of Jersey 1.18, whichwas not compatible with JAX-RS. We tried
manually to make it use Jersey 2, but we did not succeed and we gave up. There
was also a note from DW authors that they planned to integrate Jersey 2 in the
next release of their framework, so we decided to wait. Finally, their kept their
word, because in March 2015 we migrated to the newest DW 0.8.0 at the time and
it came with Jersey 2 on board, so it solved our problems.
On the other hand, Spring Boot by default comes with its own solution for
exposing REST endpoints, which is Spring Web MVC. We did not want to use it,
because it also isnot compatible with JAX-RS. We tried to integrate Jersey 2
inside a project based on Spring Boot and not only it was possible, but also quite
easy. What is more, starting from 1.2.0 version Spring Boot has integrated support
for Jersey 2 (sample congurationcan be found here), so it is even easier right
now.
To conclude this area, I would say that if you asked me few months ago about
thistopic, my answer probably would be that Spring Boot is more exible and
gives you a freedom of choice, but now the situation changed, and these
twoframeworks are quite similar and even looking from that point of view.

DI SUPPORT
Another important feature of such frameworks is thepossibility to use it with
some Dependency Injection solution. Even though we strived to keep our
microservices small and simple, we found using DI very helpful. From the start I
want to markthat comparing Dropwizard and Spring Boot from DI support
perspective may be a bit unfair, since DW authors probably did not intend to use
itthis way there is no single word about it in ofcial project docs. Hence, there is
no ofcial package with integration of any existing DI solution, but there are some
built by community. The most popular one is dropwizard-guice, and it is an
integration with Google Guice, that is also supported by community right now.
We do not like to use beta or snapshot version of any libraries, but at the time we
started the implementation of microservices based on DW, the only version of
Guice that was possible to use with Java 8 was Guice 4.0-beta5.
To be honest that solution wasfar from perfect. There weremany bugs in that
integration for example these connected with two modes of Guice: DEV and
PROD, that differed on how they initialized components (DEV it lazily, during rst
call to particular component, PROD inited everything at startup). Since we wanted
to use some of the application properties at startup in our code, we needed to

6 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

stick with the DEV setting, otherwise we wouldnot be able to do this. That is not
something that you want to have on production. It also created some problems for
us when talking about testing with DropwizardAppRule and ResourceTest classes.
When tests that are using them were ranone after another, one of them failed,
but when ranindependently they worked, so we were forced to create some
workaround.
At the end of April a new dropwizard-guice was released and it nally
integrateswith stable Guice 4.0, but unfortunately we havent tried it yet, so there
is a chance that some of our issues are xed byit.
Generally, allDI integrations for DW are community based, so they have different
release cycle than pure DW and such situation often cause new bugs to pop up.
The important matter is what I mentioned inthe beginning of this section DW
was probably never supposedto be used with DI frameworks, and it is a very
possible misuse of the framework from our side.
Spring Boot stands on a totally different side of the road. It provides its own,
mature and stable DI solution that has beenpopular within Spring based apps for
a couple of years. Its main advantage is that it works just as you expect, and does
no nasty surprises to you. In my mind it is one of the most important things about
features like DI that they just work as they are intended to. We havenot had any
problems with it so far, so using it caused huge productivity gain for us.
Summing up this area the verdict is quite clear SB gives us just what we need
and is much more suitable for us.

PERSISTENCE SUPPORT
As statedin REST support section, we try to use specication whereverit is
possible. Talking about persistence, we wanted to base it on JPA 2.1 specication.
Unfortunately, it is not possible using Dropwizard, because it is very tightly
coupled withHibernate (dropiwzard-hibernate is ofcial package from framework
authors). Hibernate is compatible with JPA 2.1, but with dropwizard-hibernate you
cannot inject EntityManager for example, and you have to use Hibernates Session
and SessionFactory. Contrary to community DI support, this integration is very
stable and works ne. However, it requires quite a lot of manual conguration,
which in my opinion is quite verbose. Itmeans that for example you have to list
entities and converters by hand in order to make them working. It also provides a
very basic DAO abstraction, which in majority of cases is sufcient.
Spring Boot gives much more in that area. To start with one thing, it uses Spring

7 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

Data module that is build on JPA 2.1 specication, so it is possible for us to use
callback methods like prePersist, preUpdate, etc. Moreover, it has very easy
automated conguration when compared to DW. That is achieved by providing
nice solutions that speed up everyday development, like entity scanning. Another
brilliant concept is Repository interface (from Spring Data module) that makes
creation of CRUDs and simple DAOs as simple as you can imagine. And nally,
less important but also worth notingis thefact that it is possible to use SB with
differentORMs than Hibernate, which is very difcult to achieve with DW.

TRANSACTION SUPPORT
Payment platforms need to be trustworthy and consistent. Error situations always
happen, and you need to be aware of them. For instance, in microservices world
you need to handle situations like connection timeouts or services being down. We
have some volatile areas that consist of multiple service calls, that change the
state of payments, wallets, etc, so they need to be atomic. We use transaction
mechanism to achieve this, because we want to be able to rollback all the
changes, if any error occurs.
Both frameworks provide a way to use declarative transactions. Dropwizard
comes with @UnitOfWork annotation which can be applied only tomethods in
REST resourceclasses. That means that whole request processing is bounded
inside of transaction, and if any exception is thrown, all changes are rolled back. In
most of the cases it is not what we want. If we want to decide what takes part in
the transaction, and to manage that in DW based projects, we have to start
transactions manually. There is also one very important information about DW
0.8.0. When we migrated to that version, we got to knowthat it comes with a
serious bug that does not rollback a transaction after failure. That is something
totally unacceptable for us. DW authors knew about it, and they patched it in the
sources available on github, but they decided to wait for over a month with
releasing it to public repository. That forced us to build a patched version of that
artifact and host it on our own. Finally they xed it and released Dropwizard 0.8.1.
When it comes to Spring Boot and that matter, I have to admit that it offers much
more. Its @Transactional annotation can be applied on any method or class, not
only on endpoints, so it gives much more exibility. What is more, it also supports
transaction isolation levels, what makes it very powerful and suitable for
advanced use cases. Finally, it is a very well tested and stable solution, and it is
barely possible that one of its versions will have a bug similar to one that DW 0.8.0
comes with.
Wrapping up this area, it is much more comfortable for us to work with SB when it
8 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

comes to transactions, because it has a more advanced and mature solution for
that.

CONFIGURATION MANAGEMENT
Every application that runson multiple environments needs to be congurable
somehow. With microservices architecture things get more complicated than in
monolith application with a single property le. Since we deployed and ran every
microservice separately and hadmultiple conguration les, we quickly realised
that the maintenance of this amount of cong les ispainful. That is why we
decided to have one cong le for each component, and have settings for all
environments in there.
Dropwizard and Spring Boot are both compatible with conguration le in YAML
format, and SB also supports simple .properties le format. DW has no built-in
functionality to support multiple environment congs in one le, but we found out
that integrating Constretto library woulddo the thing for us. Spring Boot has its
own solution for that, and it is called Spring Proles. It also provides an easy way
to access your properties, because you can simply inject them to your bean by
@Value annotation. Besides, similarly to DW framework, they canbe retrieved
from Environment object. There is one issue that I mentioned inDI area when
using Guice inside DW based microservice, we have to stick with DEV mode to get
our properties at startup.
Summing up, the conguration management is by default supported better in
Spring Boot, but Dropwizard, supplied with Constretto, also meets our
requirements.

DEPENDENCY MANAGEMENT
Dependency management is very important for us, because we put much effort
into keeping our classpath clean. We decided to use maven-enforcer to fail build at
compilation stage, in case it discovers duplicated jars.
Unfortunately, that area is probably one of the weakest points of Dropwizard,
because its authors did not put much attention into this. The project itself has only
few managed dependencies. Dropwizard framework is divided into few core
modules, and even though they are compiled with maven-enforcer, we
encountered some issues with dependency convergence. Some of DW modules
are incompatible with each other, some haveissues inside. For example
dropwizard-logging from DW 0.8.0 module comes with 2 versions of slf4j-api
artifact. Same issues concerncommunity modules, whichalso donot align their
9 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

dependencies withofcial packages and if you use them, you have to struggle a bit
to make your project compiling with the enforcer.
Spring Boot authors present totally different mindset about that case. They
provide very nice dependency management pom, which can be either imported, or
set as parent in your applications pom. Spring framework is build of multiple
packages, has higher granularity of them comparing to DW. So, at rst you may
feel a bit dizzy which of them you have to pick to achieve your goal, but Spring
teamcame with this idea of starter modules that ease the use and conguration
of other Spring modules, or 3rd parties in order to supply everything that you need
for a particular objective. For example there are starter poms for Spring Data JPA,
whichprovides repository interfaces and other goodies for persistence, also
starter modules for Big Data, NOSQLs, security, and nearly everything you can use
to build your web app. One last fact to markabout Spring Framework is that all its
modules are compiled with maven-enforcer, so that is simple and smooth to
include these packages into our pom.
The overall impression looking from dependency management point of view
theabsolute winner is Spring Boot, because it does not require any effort from us
to have a clean classpath, and it is structured betterthan Dropwizard.

METRICS
We value the meaning of application metrics. For now we have notput much
effort into specic gauges inside of the platform, but we want to get stats about
some parts of it so we did initial work to have them.
Since Dropwizard was initially developed by Coda Hale, it is more than obvious it
adopts his ownsolution codahale-metrics inside of Dropwizard. It was great
decision, because this library can be nicely integrated inside of web application.
They are easy in use and are very powerful at the same time. It comes with the
most popular gauges dened, but still you can dene any type of custom
measurement. What is more, Dropwizard also provides good support for health
checks that are a must-have feature for microservices and cloud based
environment.
Spring Boot provides only basic metrics and stats for example some system
metrics, and support for health checks. It does not provide its own solution for
advanced metrics like Dropwizard. In ofcial Spring Boot documentation, in the
metrics section, we can nd that they suggest using Dropwizard metrics package
for any advanced measurements, so they pay honours to DW authorsfor their
work in that matter.

10 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

In the metrics area, we give huge credit to Dropwizards solution. Usingits

metrics you can have well measurable application without putting much effort
into it.

COMMUNITY SUPPORT
When it comes to community support, I did some research about both of these
frameworks in the web.
Surprisingly, it turns outthat on StackOverow there are 4 times more topics
about Spring Boot, than about Dropwizard (accurate numbers are: 6,326 about SB,
and 1,482 about DW data collected at 24th June 2015).
That is not what one can expect, because Spring Boot is youngerthan Dropwizard
(SB was created about 2 years after DW). The numberof contributors on Github is
quite similar 183 vs 163 for Dropwizard, but in both cases 90% of them are
rarely active. Release cycles also favours Spring Boot, they are much more
frequent than Dropwizard (last interval was about 9 months between 0.7.1 and
0.8.0). The ecosystem is also more sophisticated around Spring Boot it provides
aforementioned starter modules, that allow integration with lots of other ofcial
Spring goodies. What Dropwizard offers here is a few ofcial integration packages
(like hibernate one), and a lot of community projects.
There were moments that we were stuck with something when working with both
of these frameworks, and then we tried to contact the authors. Sooner or later, we
got their responses, but it seems that Spring Boot has some coders also delegated
for contacting users and they are much more responsive. Generally speaking,
Spring Framework is sponsored by Pivotal, so there is much more activity around
it. Dropwizard is no longer developed by Coda Hale, hedecided to entrust further
development to community, and that has some impact on the quality of the
support.

CONCLUSION
Over half of a year of work withthese two solutions gave us some thought on
them. Both of them are achieving their goal of building microservice components,
and also are very devops-friendly, but they are built upon slightly different ideas
and mindsets.
We feel that we are more productive using Spring Boot than Dropwizard. You may
say that we abuse microservices idea with features like DI or ORM, but I think that
if they work for you, that is the right path to go. Since we are building payment

11 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

platform, in some places we need to use this enterprisy things to make our lives
easier. Even though it seems Spring Boot is more suitable for us in most of the
areas, we dont throw Dropwizard awayand we still use it in some of our
components. In my opinion for smaller services, with a simple domain, Dropwizard
is a way to go. Most of our components are rather small, but some of them have
quite a complex logic that is easier to implement using Spring Boot. What is more,
it seems that the maintenance of components based on SB is less painful. We also
value its popularity, when it comes to community support. A lot of modules that
are used by Spring Boot under the hood havemuch longer history than the project
itself and they are considered as stable and mature. There is one thing that should
be noted, though all these features provided by Spring Boot, come with a price of
a longer startup time. Vanilla Dropwizard distribution starts a lot faster than
Spring Boot but it does not concern us, because in our project we utilize
blue-green deployment technique, whicheliminates downtime.
All in all, you should always consider what do you want to do and choose the tools
that will make your work easier and more pleasant to go through. Whether you go
with Dropwizard or Spring Boot, if you put some thought to this decision
beforehand, it is more likelythat you will benet from frameworkscharacteristics,
rather than curse itsauthors.
Like

Share

Tweet

COMMENTS
SEBASTIAN EICHHOLZ

July 4, 2015 at 10:11 pm

Thank you for this great article!

I am using Dropwizard and stopped experimenting with Spring Boot after a short time,
because it seems to be too fat for me. Doing something unusual with DW looks easier
for me than with Spring Boot.
As for the persistence thing: Do you know GuicePersist?
https://github.com/google/guice/wiki/GuicePersist
I am using it with Dropwizard (which means: I can use Hibernate / JPA 2.1 with DW).
Reply
DANIEL JAGIELSKI

12 de 19

July 6, 2015 at 3:59 pm

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

Hi Sebastian! Thanks for nice words about my article. As I mentioned above, it is always a matter of
taste and your own calculations when you decide which one to use, so maybe you feel more
comfortable with DW because of your use case. A fact is, that Spring Boot brings more jars to your
classpath comparing to Dropwizard, but I wont say it is fat.
Unfortunately I havent tried GuicePersist yet, but thanks for your suggestion about it probably well
give it a try in future.
Reply
MARK

July 9, 2015 at 6:51 pm

I had the opposite reaction (and more like Daniels). While i applaud DW no Spring/DI, older libs, etc
there was no competition for my perspective for me. It just works. YMMV. I dont have to time to
worry about versions and looking for solutions for 90% of things i need to do and etc. My time is more
valuable than disk space. Spring Boot has been to me what Spring was when it rst came out. I got to
throw away a bunch of my code and stop doing things that i was doing because Spring did it for me.
About 12 years ago I was working with an Architect (and yes he was smart and talented) who was
trying to create his own DI/IoC framework but didnt know it. I kept telling him just use
Spring.NET. He nally realized he should just use Spring.NET and quit wasting his (and his employers
time). It did what he wanted and needed.
Reply

JOSH LONG

July 5, 2015 at 6:03 am

Hi,
This is a very nice post!
I just wanted to add some points:
when we built Spring Boot we _ABSOLUTELY_ were inspired by DropWizard and have a
lot of respect for it. Spring Boot even integrates the Dropwizard Metrics library if its on
the CLASSPATH, in addition to its own metrics subsystem that was inspired by what DW
provides. Theres a _lot_ of great ideas in DW, and other technologies like Grails and Play
framework, which also for example support standalone applications.
Spring, as well as a large portion of the Apache Tomcat team, Redis, Cloud Foundry,
RabbitMQ, etc., _were_ at VMWare but were now in a spinoff company called [Pivotal]
(http://pivotal.io).
I think youll nd that Springs dependency injection mechanism has been popular in
Spring-based applications for more than just a couple of years LOL
I am glad that things are working for you, however, we are _ALWAYS_ eager to learn how
to improve to make things better for developers. If people have questions we do our best
to monitor the StackOverow tags, and we respond on the [Spring Boot Gitter channel]
(https://gitter.im/spring-projects/spring-boot?utm_source=badge&utm_medium=badge&

13 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

utm_campaign=pr-badge&utm_content=badge) and if there is a way to improve things

[_please_ le a GitHub issue](https://github.com/spring-projects/spring-boot/issues).
Reply
DANIEL JAGIELSKI

July 6, 2015 at 4:14 pm

Hi John,
thank you for your approval of my post, and for noting the mistake about company behind Spring
Boot, Ive already xed it.
I enjoy your attitude to customers requests. We have already contacted you with one matter in past,
and we got quick and professional response, so please keep it this way
Reply

DAVID CARR

July 6, 2015 at 4:20 pm

> They didnt clone Dropwizard they adopted these nice ideas to their existing platform,
so that when using SB you wouldt loose any of Spring Framework power and abilities it
had before.
Doesnt pulling along all the power and abilities of Spring Framework also bring along its
complexity? In my opinion, Dropwizards strength is its simplicity. It has few mandatory
dependencies, carefully picked to be relevant to the core of its mission (providing
ops-ready RESTful web services), and doesnt get in the way by trying to abstract them
away. It then also provides a small number of optional integrations with commonly used
capabilities (database access, migrations, views), which you can use if they meet your
needs, or you can write your own if they dont.
Reply
DANIEL JAGIELSKI

July 8, 2015 at 10:15 am

Hey David, thank you for your opinion. That is true that simplicity is one of Dropwizards assets, but
sometimes you need a bit more than just simplicity, even though you have to pay for it with additional
dependencies and abstractions. When it comes to Spring, by providing these abstractions it reduces
the amount of code that you have to write yourself, but I know that one can feel uncomfortable
having some of the logic hidden by the framework. Still, after Ive got some experience with Spring
products I found that the authors really do make things easy to be adjusted.
Reply

14 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

FRANK PAVAGEAU

July 6, 2015 at 5:42 pm

Hi,
Nice post.
I have a small correction to make, though: Coda Hale is a single developer, not a company,
who initially developed the metrics lib while working at Yammer.
Reply
DANIEL JAGIELSKI

July 8, 2015 at 8:50 am

Thanks Frank for your comment and pointing it out, that was an obvious mistake
Reply

MARK

July 6, 2015 at 6:14 pm

Daniel, I believe JHipster incorporates DWs metrics (well, Codehales). If youve not
already, Id take a look at what theyve done.
https://jhipster.github.io/tech_stack.html and look for metrics.
Reply
DANIEL JAGIELSKI

July 8, 2015 at 8:43 am

Thats nice I didnt know about JHipster. Although I do not like some of its ideas, like entity
generation for example, I will take a look for sure, thanks.
Reply
MARK

July 9, 2015 at 6:39 pm

Daniel, I dont disagree

For instance, I am using things like webjars/gradle instead of JS tools. That being said I think it
is, at the very least but not in the least something minor, an excellent example of Spring Boot and AngularJS and other
related tech and how to use them. As with all things YMMV (as you mentioned to Sebastian
).
I do suggest to keep occasionally looking at JHipster for ideas I had not looked at in a few months and it looks like

15 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

theyve done new things recently.

Reply

JULIEN DUBOIS

July 8, 2015 at 9:50 am

Thanks Mark! Im the JHipster lead developper, and in fact we started before Spring Boot existed,
and we copied a lot of ideas from DropWizard. Basically I loved everything about DropWizard, but I
wanted to have Spring for DI and Hibernate for ORM So this is why we have a mix of both today,
using Spring Boot and DropWizard metrics together, as you wrote.
Our main focus today, however, is to do a fast and easy-to-use application generator, from the
back-end (Spring Boot) to the front-end (AngularJS), with lots of tooling pre-congured (Grunt,
Bower, Maven, etc.).
Reply
MARK

July 9, 2015 at 6:54 pm

Julien, thx for all your good work for the community! It (along with SB and DW) is a prime example of why people need to
look beyond language syntax and IDEs to decide what language and platform they choose.
Reply

ANAND SHARMA

July 9, 2015 at 10:10 pm

Josh: Do you have a Slack Channel besides Gitter for Spring Boot?
Reply

VOLKAN YAZICI

July 25, 2015 at 10:15 pm

That is a really comprehensive write-up which really sums up the core of the issue, thanks
so much Daniel! I think all your points are valid, with the exception that Spring totally
lacks a proper community support channel. Let me share an experience: At the beginning
of this year, I started writing a REST application using Spring Boot, Spring Web MVC, and
Spring Data Neo4j. Here is a brief list of my community & documentation support
complaints:
Spring Data Neo4j assumes that you know by heart what Spring Data is all about (you
need to understand pages and pages of doc in order to have just a simple idea) and it
never clearly speaks about how it maps queries to actual Neo4j calls.
16 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

While both Spring Web MVC and Spring Data Neo4j look like a stable projects, there are
(were?) still some major problems that are not documented (see
http://stackoverow.com/questions/28324994/empty-exception-body-in-springmvc-test/ and http://stackoverow.com/questions/27933035/failed-to-mark-transactionas-rollback-only-in-spring-data-neo4j/) and you are expected to apply brute-force
try-and-fail approach.
The so-called community support pointed out by the ofcial Spring website redirects
you to Stack Overow. And according to my experiences, regardless of how valid your
question is or how well-formatted to easily reproduce the problem, none of the core
Spring developers care at all. And a majority of the answers you get are written by other
people who are also confused and puzzled as much as you and most of the time could not
even manage to gure out what the question was really asking. I see it like a mud pool
that users get into a wrestle with each other in while Spring developers doing a barbecue
against the view.
To sum it up, I think Spring has no community support. Just a (sh*t) load of people who
wrestled and survived in this mud pool long enough to keep the newcomers questions
answered.
Reply
RUSLAN STELMACHENKO

January 23, 2016 at 1:13 am

Sad but true. My experience is similar. Stackoverow is good but often we need support and answers
from Spring developers or at least someone very experienced in subject almost like the developers.
Most of the time I havent any problems with Spring at all but when they come then that problems is
hard and often blocks future development and usually no one on Stackoverow can (or want to)
answer.
But I can understand of course why is it. It is open source. Developers need invest their time to
develop. And not only Spring but also their main work. And Im _sure_ they are tired of these endless
questions.
I cant imagine myself in their role. So Im very respectful to them anyway!
Reply

17 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

KRISHNA

http://www.schibsted.pl/blog/spring-boot-and-d...

March 29, 2016 at 12:56 pm

HI,
It is sad to know that your experience is not pleasant one with Spring developers. But, I have been working in spring for
last 10 years and using Spring Boot for last one year, I found that they are very helpfule and approachable for any urgent
queries.
I have even posted some of the questions to StakOverFlow, those are answered by the Spring developers instantly. But,
there will be always when it comes to bigger framework like Spring.
Thank You,
Krishna
Reply

RAJA

July 28, 2016 at 1:07 pm

What do u mean by Blue Green Deployment

Reply

Leave a Reply
Your email address will not be published. Required elds are marked *

Comment

Name *

Email *

18 de 19

19/08/2016 10:05

Spring Boot and Dropwizard in microservices d...

http://www.schibsted.pl/blog/spring-boot-and-d...

Website

POST COMMENT

Get the latest job positions, hear about our events and
learn how we work

SUBSCRIBE TO OUR NEWSLETTER

Summer Internship at
the right place
Read more

Copyright Schibsted Tech Polska

19 de 19

19/08/2016 10:05