Sadly, this is more of a teaser with architecture diagrams than actual content about best practices in React and DropWizard. Looking forward to the future posts, though!
On the note of architecture diagrams... if you're geeking out about how to simplify architectures like their "before" picture, I'd highly recommend checking out Confluent's article on LinkedIn's data platform: http://blog.confluent.io/2015/02/25/stream-data-platform-1/ It's much in the same vein as this article, but focusing on backend organization. Highly recommended.
Since this is taking off a bit: Here's an excellent talk that provides some context to the Confluent article, and takes us through the thought process of simplifying convoluted database-cache-user interactions by thinking in terms of streams of derived data: https://www.youtube.com/watch?v=fU9hR3kiOK0 . Also highly recommended.
If the authors are reading this: in your later articles, I'd love to see some details about what method of authentication and authorization you settled on for the REST API and how well it plays with Dropwizard.
The upshot is we settled on OAuth 2.0 with JWT auth tokens, along with some custom DropWizard filters and annotations to enforce authz. We found two-legged OAuth 2.0 pretty straightforward to implement and use.
Sounds like you guys might have used Apache Oltu? If so, I (and I'm sure many others) would be interested in hearing more about that, because modern, non-trivial authorization and authentication is probably the single biggest missing piece for Jersey/Dropwizard.
This may be covered in one of the future articles, but how have you found HBase as a storage system and Hadoop as the primary system for data processing? If you could start from scratch, what do you think you'd use?
Great article. I developed a (real world) personal budget app[1] using Angular 1.x + DropWizard. If anyone interested to learn/see source code, the source code is available on Github[2].
Important note: React doesn't attempt to solve any data modeling issues itself. It just gives you a way to describe to a browser what it should draw when given some data. It's not trying to provide solutions to all the same issues as Angular or other MVCs--it just makes some of those issues not even exist, although it obviously requires you to find solutions to other issues on your own.
As for the benefits: React components are super composable. I find myself comfortably reusing modules way more when those modules are React components. Also, there's also low overhead of abstractions to keep track of, so the learning curve is very shallow compared to the ones for figuring out how to draw stuff in a framework like Angular or Ember in my opinion.
These aren't by any means the only or even necessarily the biggest ones, they're just ones that I am very fond of.
On the note of architecture diagrams... if you're geeking out about how to simplify architectures like their "before" picture, I'd highly recommend checking out Confluent's article on LinkedIn's data platform: http://blog.confluent.io/2015/02/25/stream-data-platform-1/ It's much in the same vein as this article, but focusing on backend organization. Highly recommended.