East Pole Site

← Back to portfolio
Bol.com Front-end Rearchitected
2022

Acting team lead and surrogate product owner of a virtual team working on an architecture replacing Bol's existing front end architecture, involving GraphQL and React.

GraphQLNext.jsNxReact

Why we did this

In 2022, Bol.com's architecture relied on a home-grown rendering layer and ad-hoc integration of a slew of back-end services.

  • Being a homegrown and non-standards based solution, it became increasingly hard to find developers capable and willing to work on front-end code.
  • The fan-out into back-end service calls was weighing on page rendering times, further aggravated by many components needing similar data.

Image of bol.com's original architecture, involving custom page rendering and REST back-end services

What we aimed for

With bol.com being a retailer, we obviously needed server-side rendering. Based on my suggestion, we picked Next.js, and went with GraphQL federation on the backend.

  • Next.js would make sure we switched to React while retaining server-side rendering.
  • GraphQL federation would allow us to abstract from the back-end services and have smart resolvers calling only what we really needed.

How we achieved it

We started working on the landing page as the test-bed for our ideas. We knew we would have to accept that we would not be able to do everything in a single go, so we decided to leave header and footers out, and continue to to rely on the existing rendering solutions for that. Ultimately, we would rely on the load balancer to allow us to slowly starting support for other pages to.

Also, inside the page, we couldn't rely on the whole GraphQL federated back-end being present right from the get-go. Rather than waiting for everything to be present, we stubbed out access to a GraphQL backend by having an "embedded" GraphQL gateway. That gateway allowed us to pretend the full GraphQL backend was there, define the contract and work on the rendering.

Within two days after start, we had a working landing page. I like to think of this as a proper example of rather seek for denial than ask for permission. Instead of waiting for architecture boards and teams coming together on a solution, we just picked the most obvious that would get us results quickest, and iterate on that.

First, we focused on feature completeness, next on qualitative aspects (performance, instrumentation). Once we felt comfortable, we started sharing our progress with other developers and organized some workshops to give them a taste of what we were doing, allowing them to start working on other parts of the codebase.