In Defense Of The "Monolithic Microservice"

Great concept, and I appreciate finally having a good term to describe the way we’ve been building things. As requested, one section that was a little hard to follow was the example of the various services you were building there. Perhaps a high level architecture diagram of the small handful of services and which ones talked to each other as a static diagram on screen while you were talking about them would help folks follow along.

Thank you for the talk. I came into this talk expecting more of a "here's how to organize your code in a monolith so it's easier to maintain" discussion. I'm not sure I still wouldn't think that from the description.

That being said, when the concept finally sank in it was really eye-opening. I already have plans on how we can us this pattern in our main application (which will be 6 applications in the future :-)).

I appreciated the concept of splitting systems into different components, particularly the idea of a dedicated "service" for authentication. From my understanding, the approach here suggested setting up multiple, likely full-stack, applications alongside each other. However, with modern frameworks like Symfony, I wonder how large an app must be to justify this structure and what the specific trade-offs are. Also, how can we ensure a cohesive front-end experience across separate applications? Is the aim essentially to build internal APIs? Overall, I enjoyed the talk, but I felt it stayed somewhat at the surface level.