The other day I was having a conversation with Doug, a Staff Engineer on our team, about whether pragmatism and idealism are at odds (when applied to writing software). He mentioned that he thinks it’s more that they’re on a spectrum than being at odds against each other. Essentially, the idea here is that on one end of this spectrum there is pragmatism. On that end, the approach taken is realistic and more down-to-earth.
Blog
For a long time at Root, we’ve used pub/sub as a way to decouple parts of our application. This was done with a small ruby class. Essentially, you’d call publish with an event and the associated attributes, and any subscribers would run inline at that moment. That has worked very well for us, but we wanted to have the option to eventually extract some “macroservices” from our monolith. To make that extraction work, our current pub/sub solution wouldn’t quite cut it (since it needs to be able to call the subscribers directly).
Recently at work, I’ve had a lot of time to think about how we architect and design our server in a way that will scale for our current needs and future ventures. While doing that, I feel like I keep coming back to a few guiding thoughts that I’m planning on writing about. In some applications, you’ll find that to build new features or add functionality you build on top of other things.