TL;DR
Solve friction between backend and frontend with an API mocking server, GraphQL, automatic server side rendering and a schema first headless CMS of your choice.
About
Back in the day, web development was a lot less complex. Those days the backend basically was the frontend, today the backend and frontend are two distinct and often rather complex entities. Syncing frontend templates and assets with backend rendered markup is often anything else than straight forward. Depending on the CMS driving your site, you get more or less container markup wrapping the data outputted by different modules and either you overwrite a lot of server templates (if that is even possible!) or you adapt your CSS (not always possible either with flex based layouts) to integrate your markup.
But thankfully there’s finally a promising path out of this mess! By doing as much as possible on the frontend, ideally component based so you can abstract complexity into smaller more focused pieces, and than render the routes and markup with a server side rendering framework, you never again have to sync markup from different sources. And by additionally mocking the API server, we can flexibly and much faster tinker with the project till everything is perfect, without first implementing the feature on the backend, making us more responsive and our clients happy.
Let’s be honest, letting the backend render markup was never a great idea anyway. Not only does it create the described friction between frontend and backend, it also isn’t really the expertise of backend developers, especially when it comes to things like accessibility and above the fold performance optimisations. A frontend first development workflow can solve us all these problems and this place here will try to do it’s best to point you in the right directions.
A content management system is for managing content, not for content rendering!
Why
Let’s first have an overview why we actually need to move to a frontend first development workflow by comparing its advantages and possible disadvantages.
Advantages:
- Less friction between FE & BE: Because a headless CMS only manages contend and delivers it to the frontend over ideally a GraphQL API, you never need to sync markup between frontend & backend and as GraphQL APIs are auto documenting, you always know exactly what’s available to you as a frontend developer.
- Enables tinkering: As you are mocking the API, changes can be implemented much faster than actually building the backend service first. So fast actually, that you can do live tinkering together with the client, right on the product.
- Easier debugging: Moving most of the business logic to the frontend and having a strongly typed auto documenting API makes it very clear where an error comes from. In 99% of all cases it will originate from your frontend code and you can debug it at one single place. Strongly typed languages like TypeScript or Reason ML or even Elm can tell you where bugs are even while you code.
- Client friendly: Clients often don’t have the expertise to judge an abstract technical concept without something they can interact with. By developing frontend first, clients can judge a feature as realistically as possible before any backend is implemented, making sure that stakeholders involved make informed decisions.
- More focused backends Frontend first enables the backend to focus and optimise the right thing. By knowing exactly what the frontend queries are, for example with the help of Apollo Engine, they can add caching layers exactly where needed and use the freed up time to optimise the content management forms, delivering the best experience to clients.
- Skill targeting Frontend developers are the experts on writing HTML5, accessibility, optimising above the fold performance ... why should the backend developers ever render markup for them?
- Focus on the right thing: With frontend first, you spend most of the development time where it counts, the thing people see and interact with, and automate as much of the rest as possible.
- Decouple backend implementation: As you are developing data structures frontend first, the backend is forced to develop the API service decoupled from the actual implementation details like the database table names, field names in that table or the attribute names of an external API. This is very good practice as it protects the API from changing after an implementation change, but is often not done because of the extra overhead in development.
Possible disadvantages:
- Frontend developer maturity: Designing normalised data structures is traditionally a backend job, so frontend developers need to acquire this skill first so they can perfectly mock API services. But looking at what the frontend community achieved in recent years, I’m not at all worried that this will be a big issue. It is no surprise that the frontend community made the Flux paradigm popular again in favour of MVC, solving many issues of the past.
- Works better with a serial workflow: Ideally, the backend starts to build the real GraphQL API right after the frontend has implemented all features. While there are often external API integration tasks the backend can focus in the meantime, it definitely can happen that the backend is blocked by the frontend, waiting for an implementation. But to be honest, up till now, the frontend was often blocked by the backend for the same reasons, so this is not exactly a new issue after all.
Less friction between FE and BE
Let’s have a closer look at one of the pros, one that creates a lot of issues with current workflows, to get a better idea why frontend first is such a tempting idea.
Usual developer workflow:
This workflow creates friction when both paths meet!
Frontend First Workflow:
Only one development path, no friction!
Information architecture and technical specification is mostly a first draft. Than changes happen after the client can interact with the frontend or living style guide, while iterating till every stakeholder is happy. Without a frontend first approach, this leads to friction everywhere. Even content creation is more and more frontend first focused these days, just think of headlines that have to be limited to certain lengths to match the design and use fitting word lengths to break nicely in the limited space designed for that element.
Key technologies
Thanks to some key technologies of recent years like GraphQL and all the tooling around it, we are now pretty close to make a truly frontend first workflow possible!
API server mocking
The first key technology is API server mocking. On a frontend first workflow, you want to start working before any backend is set up. Traditionally we used hardcoded data and mocked JSON endpoints to mock our API endpoints, but these days it’s now possible to mock a whole REST or GraphQL server with just some sample data. These kind of servers support all the CRUD operations (create, read, update and delete) and especially with GraphQL, can feel like the real thing, but with almost no effort. This is very important, as you can create prototypes that are so close to the real thing, that your client can get a very realistic impression of the final product, without ever having to first setup a backend CMS. The other important feature of this approach, is that you can design your sample data so realistically, that you can test frontend edge cases, for example different content lengths, right from the beginning. As you’re working with sample data, changes to your API are done in seconds, even changing normally complicated stuff like relationships, becomes really easy.
If you want to have super fast iterations on your API, there’s no way around an API mocking server.
Let’s have a look at an example. The following sample data defines a blogging API where users have posts and posts can have comments and comments can be replies to other comments.