Chicken or Egg

These days it is practically hard do not use a Spring. I suspect the explosive blooming of JVM languages nowadays may be just a desperate attempt to escape this beast, gradually acquiring the Java world. And despite I'm not especially thrilled about it, my last three contracts were around so, I might admit this. Last its reincarnation on the market, the Spring Boot, looks solid on glance. The dependency hell of its previous incarnation was polished by Maven's BOM. I barely can see areas it doesn't cover, it looks like a pretty mature framework that seems self-sufficient and, no doubts, it is a pretty handy tool for practically any Web related PoC. Swiss knife in middleware, give or take. Design microservices from scratch or moving an old monolith towards to, most likely brings the Spring Cloud into consideration. Plenty workforce resources on a market are familiar with it thus gives it advantage over alternatives. Plus it requires only declarative configuration with minimal or even none of code: so, less code, less bugs.

However such apparent simplicity and minimalism have a side effect sometimes outspokenly ignored: it demands clear understanding what you are doing in details, what is under the hood. Especially for a young brains so vulnerable to distorted perception of objective reality. Underestimating that leads to really wonder conclusions. And important to add, the higher abstraction level it gets, much easier to fall into a rabbit hole of the common sense entropia.

Autodiscovery and cloud configuration provided by Spring Cloud Config working well just from the box. By default the client is trying to fetch its configuration from a server on bootstrap, specified by provided URI. Unless the autodiscovery is not in the place. But once you decide to use discovery mechanism, no matter which one: Eureka or something else, it would make much more sense to discovery that URI instead of specifying it explicitly. Just because it require less URIs to be predefined when system is deployed somewhere. Imagine my wonder when I came accross a project that implies the configuration first bootstrap with discovery in place. And funniest was a reasoning behind: "it's kind of chicken or the egg problem, we did considered both and decided that configuration should go first". For me it sounds like: "the genetically bred broiler came first as somebody have to laid the stegozaur's fossilized egg" or "this morning we ate the egg that was laid by tiranosaurus". Yes those are still the chicken and the egg but for a pity's sake, between them a huge time lapse! The service discovery and their configuration are quite parallel processes and what go first has nothing related to a famous paradox. Discovery just aliases your URIs in convenient form of service identifiers, configuration service is a just another service that can be also discovered on bootstrap. The benefit would be obvious when you would try to organise deployment of your service into staging / production environment or just a sandbox for integration tests.

By the way, the testing is yet another aspect that is transformed once you landing to the Spring. I think everybody saw the Fauler's testing pyramid. He is particularly grand in explaining complex things and here he demonstrate this yet another time. However, taking into consideration the mostly declarative principle of development in the Spring, where you are doing not so many parts actually, certain things may be simplified without any risk. And implying that most likely you take on board the "Spring Boot Test" that may easily lift up the unit tests into component level, changes the landscape of testing. Borders between levels blured and its easy mess up which test is which. At least it become not so obvious as in theory. It is not a failure or fundamental disaster, there are the same testing pyramid as it was difined by Mr. Fauler. It's classics, it's never goes out of style. Just eventually the tests in project would be harder and harder classify and even a mature developer may not say straight forward is it component or unit test.

And, you know, may be it's not so important, as far tests do what they supposed to do. Really, as far as test covers particular test case and allows uniquely identify the buggy part of the code in case of failure, its perfectly cope with devoted assignments. Everything else is just a theoretical fluids around real life practice.