Our Next(JS) Webshop
Tags: nextjs, webdev, react, technology
Published: 2023-07-17 07:48:00

##Ownership continued##
In recent posts we have shared our views on [ownership] (https://dev.to/coolblue/guided-ownership-422j) 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] (https://dev.to/coolblue/the-monolith-in-the-room-1947).

Since last time we wrote about our [Tech Principles] (https://dev.to/coolblue/tech-principles-coolblue-1a2k), 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 &trade;).

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](https://coolblue-blueprint.com) is tied to this same codebase.

Secondly we mainly use [PHP](https://www.php.net) and [Twig](https://twig.symfony.com) 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](https://www.careersatcoolblue.com/tech/development/?query=front).

> 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". 

![Frontend Futures](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f7o5nhxcpt6sqy0ip3km.png)

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](https://micro-frontends.org) 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.

![microfrontend in our Tech Radar](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vs63c1wq1xtvcriex8zy.png)

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;

![Proof of Concept in Production](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wqkqh7k411dluxs1icyo.png)

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. 

![microfrontend Roadmap blurred 07-2023](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/toadjm5xdy76b6c70yrl.png)

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](https://aws.amazon.com/lambda/edge/)
- The Application(s) will be hosted as [Serverless Containers](https://aws.amazon.com/blogs/apn/serverless-containers-are-the-future-of-container-infrastructure/) with [AWS Fargate](https://aws.amazon.com/fargate/)
- For our Front End we will use [React](https://react.dev/learn/describing-the-ui) and [TypScript](https://www.typescriptlang.org)
- To serve our Front End we will rely on [NextJS] (https://nextjs.org/learn/foundations/about-nextjs) 
- Our background processing and services are built mostly with [C#](https://dotnet.microsoft.com/en-us/apps/aspnet/apis) or NextJS/TypeScript. When needed, we will consolidate services via [GraphQL](https://graphql.org).