<story><title>Under Deconstruction: The State of Shopify’s Monolith</title><url>https://engineering.shopify.com/blogs/engineering/shopify-monolith</url></story><parent_chain><item><author>lmarcos</author><text>Great article. Main takeaway: microservices is not the only option when managing big codebases. In a parallel universe I imagine that the coolest trend in software development right now is a tool for monoliths: all code in a single repo, independent deployable components, contracts in the boundaries and mockable dependant components where needed. As opposed to our universe in which building microservices is the non-official way to go.</text></item></parent_chain><comment><author>gen220</author><text>What you describe is microservices developed in a monorepo, and a lot of companies (including the one I currently work at) have gone this route.&lt;p&gt;Some people might disagree, but imo the cult of microservices does not require 1 repo per microservice.&lt;p&gt;The tools you describe are build-graph management tools (bazel pants buck etc) and rpc tools (gRPC + protobufs, cap&amp;#x27;n proto) and they are indeed pretty cool, albeit to a niche crowd.</text></comment>
<story><title>Under Deconstruction: The State of Shopify’s Monolith</title><url>https://engineering.shopify.com/blogs/engineering/shopify-monolith</url></story><parent_chain><item><author>lmarcos</author><text>Great article. Main takeaway: microservices is not the only option when managing big codebases. In a parallel universe I imagine that the coolest trend in software development right now is a tool for monoliths: all code in a single repo, independent deployable components, contracts in the boundaries and mockable dependant components where needed. As opposed to our universe in which building microservices is the non-official way to go.</text></item></parent_chain><comment><author>hliyan</author><text>I often find myself saying &amp;quot;never do at runtime what could be done at compile time&amp;quot;.</text></comment>