Bit of context: in June, I changed companies and thus changed projects. In the world I work in, it can take a bit to get new accounts and be viable as a developer, so I think by mid July I was committing code into an established baseline for a monolith service. Technical architecture: Spring Boot, providing RESTful services, interacting with JPA repositories, and a smidge of interacting via Feign clients out to another service. Code is there, can be interactively debugged, etc. Plenty of meat to dig into, plenty of tools to do it with, but a decently robust codebase for a heavily used system for our customers.
Over the summer, we changed objectives. Instead of adding new capabilities to the project, we were figuring out how to safely port it to another environment, where most of the original code for the monolith wouldn’t make it just yet. E.g., rearchitecture it a bit, figure out how we could stub some things out, borrow what we could of the build system, and make it work. Our code would be developed in the new environment and imported into the old, and the goal was to be able to develop new things while not breaking things in the old. Challenging, particularly since the old thing was still moving forward with or without us. Still the same technical architecture, but less code to work with (since not all of the production code made it into our new environment). And moving targets on versioning: is our version foo+1 compatible with the production foo+1 in the production environment? Did they change something we rely upon? Note that things don’t change often in the areas we’re dealing with, but, since the production code’s model is that all things are at the same version, there’s a bit of extra strat-eg-ery to work through. And, of course, we don’t have a strongly built out test dataset or deployment infrastructure in the new environment.
We’re not quite resolved as of early October. But now we’re pivoting to a new thing. Entirely new objectives, entirely new codebase, entirely new architecture. Switch to providing multiple microservices, using Reactive programming and API calls for the microservices. Reading up this morning on Reactive programming, I was relieved to see the statement: “If you’re familiar with Spring MVC and building REST APIs, you’ll enjoy Spring WebFlux. There’s just a few basic concepts that are different.” (1). I’ve long thought Matt Raible was a good geek whisperer, from I think well back in Struts and AppFuse development days.. Matt apparently collaborates with Josh Long (@starbuxman), who wrote much of the code Matt included in that post. So I hop out to @starbuxman and see the following near the top of his feed:
Amused that “a few basic concepts that are different” could translate to “480 pages 😯”. Recognizing that reactive style programming’s been out for a few years now and is a mature construct, I’m not super worried. I do have some development background in asynchronous programming and event handling, after all, based on an interesting websockets-based web user interface I built out a few years ago. Still hoping that 480 pages of “Reactive Spring” is really a rehash of “everything you otherwise need to generally know about Spring” with a few extra Reactive details. Else I’ll start keeping this emoji ( ☢️ ) a little closer at hand and “reactive” might start referring to my facial expression when we get the next new shift in direction.