Despite the headline, this isn’t about xml.
I always end up looking like an asshole because even though I’m a high technology guy I’m also always saying “hey, calm down, this looks like it’s lot more complicated than the ad and the staged demo make it look”
I always try to ask what problem is being solved.
Is it having a universal parser? Actually xml kind of did solve that problem. You could easily exchange data without having to write a parser and as long as the data was mostly text, it was fine.
But that’s all it solved. It made it so you didn’t have to write a new parser. You still had to figure out on a schema to serialize and deserialize though. And you needed to parse non-scalars.
I enjoy this article and it hurt a little to read. Tha part about RabbitMQ especially hurt. This has been my life for a while. Give me our monolithic software any day.
You do need a message queue sometimes. Though I’ve often found that just inserting into a table works well enough if you plan your indexes right.
My view on it is that companies build cargo ships when most just need a normal boat. For the particular orchestration I am thinking of, it scales to massive use with billions of transactions. The problem is, the idle infrastructure is so big and the bulk of deployments don’t need that potential. I agree with you. For much of what I have done for myself I have learned to love sqlite3. I love the simplicity of one process and one file.
The projects I’m working with are big enough to rule out one process/one file, but I agree. Part of all of this is why things like Heroku, Google App Engine, and fly.io all appeal to me (especially the early Guido-era App Engine). They had all this infrastructure, but using it was no more complex than just using a normal project.
Right now at work I’m banging my head against SQS.