Ownership continued
In recent posts we have shared our views on ownership and how we use that @ Coolblue to develop our software. We value ownership on a team level as also seen in re-designing / re-engineering our 'backoffice' monolith.
Since last time we wrote about our Tech Principles, we actually added a Tech Principle to our collection that should help our teams understand ownership when we look at services, events and the connections between them. Especially how we want teams to handle these interdependencies in relation to new developments and maintenance. But that is something for another post (Soon ™).
This post will focus on our journey towards the "technical design" for our next implementation of our webshop (https://coolblue.nl). Our current webshop codebase is considered a Monolith. As far as I can see in Github the first commit dates back to June 17 of 2010. Over 13 years ago.
Today we have about 10 to 15 development teams working on this single codebase to make our customers smile. Each one of those teams has a pretty specific goal. And as such have to work together in this single codebase. This makes efforts that touch on large parts of this code base, like an upgrade to the next version of PHP, a shared and a multi team problem. Our Design System is tied to this same codebase.
Secondly we mainly use PHP and Twig for the implementation of our current Webshop. Great technologies, but we want to leverage a more modern set to allow for more fluid user interactions and to keep and attract talent.
Time for a change.
From Monolith to ?
In the introduction I already mentioned a few of the concerns we have with our current Webshop implementation. Based on those, we decided to investigate how we could address them.
Team Scope versus Team Disciplines
Technology wise we are looking to “downsize” the solutions a development team owns. Reduce the overall size. Size is still non-deterministic. It is a meta-unit composed of multiple factors: complexity, lines of code, number of services, number of classes and more.
From a monolith towards multiple smaller solutions that match closer to what a team with a goal can manage, build, maintain and enhance to deliver more value for our business.
A piece of history
About 2 years ago we held our first brainstorm session "Webshop Tech vNext".
One key decision we took back then already was to start using React as the base for our back office applications and the design system for them.
About 9 months ago, we held another brainstorm session to look at options for our Webshop. At that time we noticed that NextJS, together with React, could be a replacement for our Webshop tech stack.
We also learned about microfrontends. I myself found the explanation on this page on microfrontends useful. We were already doing more and more with Services and API's in many of our other solutions and the analogy made total sense to us. Especially in light of our ideas around ownership.
Proof of Concept time
We set out to test a few topics to learn how these would work for us in a microfrontend world.
During the Proof of Concept (Q1-Q2 of this year 2023) we actually implemented a piece of the routing needed for microfrontends in our Coolblue.nl webshop production (codebase). Only to be visible and used by our developers of course;
We found no large blockers and we decided to move ahead.
Roadmap it
Rebuilding our Webshop is a tremendous effort. And that is why we created a plan in the last few weeks. And have started on this massive journey.
In a year, we hope to share more on our learnings going through this process. But looking at the plan, I am sure that if you are a customer of ours, you will have been served a page or two based on this new implementation.
Technologies that help us achieve this
If you are reading this post just to learn: "What technology is Coolblue using for their webshop?" Sorry to have kept you waiting for so long.
- Requests (users) will be routed to the right microfrontend application with AWS Lambda@Edge
- The Application(s) will be hosted as Serverless Containers with AWS Fargate
- For our Front End we will use React and TypScript
- To serve our Front End we will rely on NextJS
- Our background processing and services are built mostly with C# or NextJS/TypeScript. When needed, we will consolidate services via GraphQL.
Top comments (3)
My understanding of the problem here is rather dated. however I find the decision a little strange based on the above reasoning (and my own prior experience).
Im curious to know what ownership means here, it seems to be a key part part in the decision to move away from the monolith, outside those already stated.
Although code size of the app maybe reduced, there are now additional pipelines, build tools, and maintenance of each repo that should be taken into consideration. This is only more pointed out with the
Solving the above in this environment would be key, so I'm curious to know how this problem would be solved here as there are at least 2 ways to go about it (assuming not a monorepo)
Mico-anything is nice, but there are drawback, some of which I mentioned above.
Ownership more on a team level teams can move in their pace with focus on their part of the customer journey.
I am not a big fan of Micro-everything, I like the term Microlith more. No need to make everything needlessly small. Find the 'size' matching what a team can own.
And we are eagerly watching NextJS's growing support for Module federation. We will keep you posted on our progress.
Cool to read! NextJS is more powerful than I initially thought it would be. It brings new issues to the table, and other old issues are easier to move away from.
Myself learned that it’s easy to bloat assets in NextJS and does require more knowledge from front-end developers than just plug a micro-frontend with i.e styled-components. Or load multiple versions of a font. But the speed @ edge is absolutely amazing.
Great to read. I love to read what other challenges there had been. It must’ve been a hell of a job,… 👏