Hacker News Reader

So the "remedy" to bigger spaghetti is a bigger debugger?

No, I was answering the statement "it looks like an absolute nightmare to debug".

Amazon's page request and rendering pipeline, I would estimate, is necessary complexity. Due to the large engineering force and the speed at which they want to move, it's imperative that the infrastructure support distributed teams delivering at their own pace while minimizing integration points via shared repos but instead integrate via defined APIs. This is a fallout of that need. Do most companies have that need? Probably not.

It's arguably necessary complexity for Amazon. I would argue that the necessity of the complexity arises from the way that Amazon treats its teams as individual standalone business units, which prompts teams to treat their part of the website as a standalone application which communicates with other parts of the website as if the were third parties. This has advantages and disadvantages, which have been outlined elsewhere.

However, even assuming that this is necessary complexity for Amazon, it does not mean that this is necessary complexity for your organization. In fact, I would argue that this is very likely unnecessary complexity for the vast majority of organizations. I concur with others in this thread who say that this framework is the result of an assumption that splitting everything into tiny components communicating via API is a good idea for user interfaces. The main problem I have with this approach is that it encourages divergence in user experience for different parts of the web site or web application. This is definitely a problem that Amazon has, and it's a factor that should be kept in mind before moving to a UI pattern that's modeled off microservices.

Reply on news.ycombinator.com