It’s been a while since the first two posts about Dapr!
In those first installments, we looked at the basics of Dapr, from a very conceptual point of view.
We also looked at the bare minimum HTTP API that Dapr exposes to the applications that use it.
But writing enterprise applications like would be slow, and it would inevitably lead to mistakes.
In this article, I will introduce you to a higher abstraction level of working with Dapr.
Earlier this month, I introduced you to Dapr, the Distributed Application Runtime.
That was a mostly conceptual introduction, showing you how Dapr works and what it can do for you.
But how do you integrate it into an existing application?
That’s the topic for today.
Building distributed applications or microservice applications brings a whole new range of problems.
All those application components, or microservices, need to communicate with each other.
How will we do that: using messaging, or would direct HTTP calls be a better choice?
Often, we must make such decisions early in a project.
Since it’s hard to change it later, we call it an “architectural decision”.
But this is often an excuse so we can blame the architect if the choice turned out to be wrong.
Following the recent kerfuffle around the security manager deprecation, I was curious to see if a codebase I’m working on would also suffer.
But how could I find out? There are no early access builds of Java 17 yet with the latest changes for this JEP.
Maybe… I should set out and try to build it myself?
But that’s sure going to be a lot of work… Or is it?
Java evolves at a much faster pace than it used to do.
But not all of the projects we work on keep up with that pace.
I have projects on Java 8, 11 and 15 - and sometimes I want to play with early access builds of newer versions as well.
How to make sure I can build them without having to constantly switch Java runtimes?
Recently, the Maven community decided to push forward and start workingtowards a 4.0.0 release.
The first question after this announcement is of course: what can we expect Maven 4 to bring us?
A lot - and in this post, we want to highlight some of the features that we are particularly excited about.
Over the years, badges have become a way for open source maintainers to show the state of their product.
Badges can give a quick overview of the code quality, test coverage or build health of an open-source product.
The problem with code coverage is, however, that a high coverage doesn’t mean the tests are any good.
If only there was a way to show the quality of the test suite…
Together with four “AwesomeSauce” colleagues from Info Support, I’m attending DevNexus this year.
For me, it’s the second time I’m here, as I spoke here in 2018, too.
Next to delivering my own “React in 50 minutes” session I’m attending some sessions to update with new technology advancements.
Shipping a new release of software usually involves quite a few steps.
Depending on the type of software, this may be something you rarely do.
Thus, it often involves manual steps.
This is not necessary!
Maven has had its “Release Plugin” since approximately April 2007; yes, that’s over 12 years!
It has served both the Maven project and many other software projects.