Frontend Platform Engineering. What is it, and why do I need it?

FrontenderZ is on a mission to help Frontend Developers in large software organizations by building Frontend Platforms that help reduce cognitive load, increase their Developer Experience (DX) and improve their productivity. When we talk about this, we notice not everyone understands what Frontend Platform engineering means, and why anyone would need it. so let's dive right into it!

What is Platform Engineering anyway?

Platform Engineering in general focuses on building and maintaining Internal Development Platforms (also called 'Digital Platforms') to streamline software development and deployment for developers. It's about creating self-service tools and environments that reduce cognitive load for Developers and improve their overall developer experience. 

Not too long ago, the DevOps movement advocated for the motto "you build it, you run it", combining the previously separate areas of Development and Operations. It meant these fully autonomous DevOps teams were not only responsible for developing code, but also where and how it runs in production. They became owners of the entire process. As a consequence, you heard a lot about Developers having to become "T-shaped", meaning they had to develop skills beyond their Development specialty. They needed to know about Server Platforms their software needed to run on, how to build dashboards for monitoring their code in production, provision their own databases, and a whole lot of other responsibilities they didn't have before. Their technological landscape broadened dramatically.

All the while, all kinds of other concerns kept mounting as well. Not only the choices in variation of their own Tech Stacks kept increasing, the number of Legal, Compliance and Risk factors to keep into account became almost impossible to keep track of. 
On top of all of that, all of these newly acquired DevOps tools and technologies kept evolving at a dramatic pace as well. This is what we refer to as the "Cognitive Load" developers have to deal with in their daily work. 

To address this, organizations have been making the move towards Platform Thinking: take away the complexity that Developers these days have to deal with, by building a self-service product -a Platform- for internal Developers that abstracts away all of the underlying complexity, with built-in Compliance and Security - always up to date.

A very good definition of an Internal Development Platform comes from Evan Bottcher:

[...] a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.
- Evan Bottcher

It's good to emphasize that the goal is still to have autonomous teams. They still own the full process: to build and to run the product. A Platform just makes it easier to live up to all of the responsibilities, because developers don't need to know all of the intricacies of the underlying infrastructure, and whatever Platform Components or Services they consume, they can be sure it adheres to all Compliance and Risk measures the company needs.

In order to build a great Internal Development Platform, you meticulously analyse the bottlenecks your developers deal with. Typically, you'll find that Infrastructure is the first thing to address. You want your developers to be able to say 'provide me a machine to run my new application in' and not having to think about compute size, scaling, redundancy, how and where it fits into the network and how to protect access to it. As you build out your Platform, you'll discover more and more areas where friction can be removed, where you can improve the Developer Experience, or add new and innovative ways to speed up development.

Frontend Platform Engineering

Now that we know what Platform Engineering in general means, what an Internal Development Platform is, and what the intentions behind Platform Thinking are, let's project that on the complexities Frontend Developers deal with in their daily work. 

Before we dive into this, let's first establish that Frontend Development is a discipline with fundamental differences to Backend Development. Those differences lead to different workflows, architecture and requirements that need to be part of an Internal Development Platform.

The whole nature of the Frontend is that it runs on the client's hardware and operating system, over which you have no control. You can't just scale your application by throwing more hardware at it, or to break down a monolith into micro services, because it always runs on one client's device. Depending on your target audience, your client-side application may run on hardware that is 20 times slower than where you develop it on. Not only that, you also have no control over the device characteristics, capabilities, or even the runtime environment (OS/Browser/Webview combination).

Then, there's the inherent security issues that come with running interpreted (not compiled) code on a client device where the user is able to tinker with the source. Client-side persistence means storing readable data that can be modified, so never to be taken authoritative. To make matters worse, everything¹ happens on a single thread. So if you think you can easily add some code to gather performance telemetry, this will happen on that very same thread and therefore degrade the performance you were trying to measure.

The Frontend Development ecosystem at large has become a hugely fragmented landscape of sub-ecosystems around Frameworks (such as Angular, React and Vue), Concepts (State management, Reactive programming) and another group proclaiming 'The Web is The Platform', and trying to leverage full-blown applications with just Web Standards and no frameworks. Everybody tries to solve issues Frontend Developers deal with, but in the process it's making the number of choices you make to build your Frontend Application almost unlimited.

You want to make sure the Digital Experiences your organization offers to its clients, are built upon a sustainable foundation of compatible frameworks, tools and concepts that are well maintained and can be arranged as one integrated, compelling Internal Frontend Development Platform.

If you want to speed up your Frontend Development, it's crucial that you limit the available options within your organization. You want to make sure the Digital Experiences your organization offers to its clients, are built upon a sustainable foundation of compatible frameworks, tools and concepts that are well maintained and can be arranged as one integrated, compelling Internal Frontend Development Platform.

In practice, you see many organizations starting their Frontend Platform activities by facilitating Frontend build pipelines. Frontend Continuous Integration pipelines are different from a pipeline for a Java-based microservice. You need different tools, different build agents and you have an entirely different way of running End to End tests, requiring client-side infrastructure to execute.

Deployments for apps using Client Side Rendering are usually relatively straightforward - the target is a simple nginx webserver or something similar. But what if you use Server Side Rendering or any of the 'in-between' rendering options? How do you leverage your company's infrastructure for building, testing and deploying a Frontend Application? These questions quickly draw Frontend Developers into areas they're less familiar with, or where they can't oversee the consequences of their choices beyond their own team. And that's where friction starts.

In some organizations you see Platform teams stepping up to help here. Together with for example a Frontend Chapter Lead they will be setting up some basic infrastructure to get Frontend applications from development to production.

And usually, that's where it stops...

But there are many other Frontend-specific frictions to be solved and there is much cognitive load to be reduced. Depending on where your Frontend Developers lose the most time, you can integrate many elements of a Frontend Platform into your Internal Development Platform.

What can a Frontend Platform do?

Depending on your specific situation, a Frontend Platform can offer a myriad of things. Let's consider the following areas.

Pipelines and Test Infrastructure

As mentioned, Pipelines are usually the starting point for many Frontend Platform initiatives. Setting up how Frontend code needs to be built, split and bundled, what is to be rendered where, when and how are non-trivial choices. Besides that, Pipelines are your gateways to production code, and this is the point where quality-, compliance- and security gates need to be implemented. By centralizing how Frontend Pipelines are defined, you don't only take away a lot of cognitive load from your Frontend Developers, you also gain control over how you bring your code to production. 

Closely related to how you build your code in the pipeline, obviously is how to get it tested. Providing your Frontend developers with a standardized way to perform End-to-End testing, either against mocked backends or against a staging environment, is a huge time saver. Not only do you want to be able to automate spinning up a test environment to run your end-to-end tests in CI against, your Developers' local Development Experience also greatly benefits from the ability to quickly run some automated or manual checks in a standardized way across your organization.

Design System

More and more organizations these days have their own Design System: a complete set of UI components and CSS classes/helpers to make sure their branding is consistently used throughout their Digital Experiences. Some completely build their own set of components from the ground up, others leverage Open Source libraries and only define their own styling on top of it. However you set it up, you need to make sure that all Frontends use this design system consistently.

Over time, companies change their Designs - usually more than once. Consider a merger or simply a renewed branding after some years of having the same colors or logo. Not only that, you also see seasonal changes in design. Think of Black Friday, Christmas, or 'Summer Collection' vs 'Winter Collection'. It happens more often than you think - or it happens less than your Marketing department would like to see.

If you have a consistent way of working with your Design System throughout all of your Digital Experiences, these changes can be made centrally and rolled out in lockstep so at any given point in time, your customers have one consistent experience - no breaks in Design in a Customer Journey. But if the implementation of your design is fragmented, and allows CSS overrides (to name one example), or has multiple implementations for every different framework that is used in your organization, simply changing the background color throughout all of your Frontend code can be a nightmare to implement or result in a horrible User Experience.

Centralized Lifecycle Management of Curated Dependencies

A Frontend Platform offers a curated set of Frameworks, Libraries and Tools for Frontend Developers to use, and makes sure these dependencies are always up to date through Centralized Lifecycle Management.

You don't want some old React App, or AngularJS SPA to be lying around somewhere, while others are on the latest Vue. Instead you want to choose 1 framework for building your Frontend Applications. The same goes for more specialized libraries: Graphs, Maps, Date/Time handling, etcetera. Choosing one single way of doing this is not always possible, but at least reduce the number of options to a minimum and make sure these are kept up to date.

One of the most annoying, recurring tasks Developers deal with, is keeping their dependencies up to date. In Frontend Development, Dependency Hell is a real thing. The NPM ecosystem is both a blessing and a curse in that sense. If you update one library, you may be triggering a host of other dependencies to be updated as well. And each of these updates may trigger a need to make changes in your code.

Keep in mind that the most popular Framework for Enterprise Frontend Development -Angular- has a cadence to release two major version updates per year! That is two times breaking changes that need to be propagated in your codebase, tested for any regressions and released. Think of all of the lost hours to upgrade just this single Framework in order to keep up-to-date.

A Frontend Platform can take most of this pain away from your product teams. More than 80% of the dependency update effort can be automated by a Frontend Platform team, only to leave verification of the proposed changes to the product teams. That's a huge win! And it allows the Product teams to focus on adding value instead.

Custom Core Libraries

Core Libraries are the Frontend equivalent of how you expose your underlying infrastructure on your Internal Development Platform. 

Besides your domain-specific code that your Product teams build, there's usually a need to centralize infrastructural functionality into Core Libraries. A common example of this, that everybody understands, is Logging. You don't want every product team to build their own Client-side Logging service that talks to their Log server of choice, where everybody formats their log messages in their own way, using their own identifier to track what happened. These are typical things you want to have standardized throughout your entire organization in order to have full end-to-end traceability.

If you want live updates to be delivered to your Frontend application, you don't want every product team to set up their own way of handling WebSockets or other form of Server Push, but rather use a central service that is robust and secure, works with scaleable infrastructure on the server and uses central logging. The client-side library to handle Server Push, where Product features can easily hook into, can be built and maintained centrally by a Platform team.

If you happen to be leveraging a Hybrid Mobile App, you may want to have a standard way of falling back to Web technology for functions you have built in Native technology and exposed on a Native bridge. Or a standard way of informing a user that a certain function is not available in the browser. Thus you may want to encapsulate this functionality into a Core Library that handles Native functions in a standardized way.

Depending on your setup, infrastructure and organization, you probably have specific items you want to offer to your product teams, in order to provide standardized, secure and compliant functionality that speeds up their development.

Architecture guidelines

Too often, Frontend Architecture happens in relatively small siloes. If team autonomy is your goal, then keeping things in your own silo may seem like a good idea. But we all know plans can change, reorganizations happen, ownership of code can get moved to another team, and people may move from one team to another.

In Enterprise environments, you usually have Enterprise Architects and Solution Architects or some similar roles that make sure the entire IT landscape of an organization is a consistent whole. You want to be able to rearrange the landscape, replace parts and combine things into new and innovative ways. With a modern, cloud based Platform, these people usually reason about (groups of) microservices and Platform capabilities, and APIs to stitch it all together.

Because of the lack of involvement of these Architects in Frontend Development, this helicopter-view on Frontend is usually not there. If you look at all of the Frontends, and as an Architect you would know and understand how eventually these Frontend Features are delivered as one experience to the end-user and therefore need to be integrated at some point as a more or less monolithic, single-threaded application on unknown hardware, you would understand that it makes sense to define exactly how a single team's Frontend should be built, in order to fit into the Enterprise Frontend system and to have a generic way to expose new capabilities for Product teams to consume.

Your mileage may vary, but setting some Architectural guidelines is unavoidable, or you'll lose your ability to move fast as an organization.

Boilerplate code

Every Frontend Framework these days has its own way of providing a quick start for projects: scripts that generate some boilerplate code to get you started on the right foot, implementing best practices.

But for your organization specifically, you may have different needs for every project to start, every component or service to create, or whatever it is you are building. You have your own ideal, curated set of libraries you want people to use on which you perform Lifecycle Management. You have your own Architectural guidelines. You may need to register new applications in your Software Catalog or something similar that you need to automate when setting up a new project.

In other words, in order to get your developers quick start the right way, you want to offer them your own boilerplate code that adheres to your standards. This speeds up development, reduces their cognitive load and can greatly enhance the Developer Experience (DX)

Observability

As mentioned in the introduction of Frontend Platform Engineering above, one of the great challenges of Frontend Development is not knowing anything about the runtime environment your code will eventually be executed in. In your Standardized Logging, you'll likely want to automatically add data about the user's environment to better analyse the cause of logged errors. Besides this, it also allows you to make data-driven decisions on what Browser functionality you should support.

Monitoring Application health is another thing where a Client-side application differs greatly from a server-side application. You can't monitor the CPU and memory usage, or the number of concurrent connections. Or, sure you can monitor this for your Webserver, but monitoring this for all clients that run your Frontend application is not desirable or helpful.

This requires a different way of looking at observability. Logging, Monitoring and Alerting is something that typical Platform Engineers that work on Server and Infrastructure Platform, think of in an entirely different way. 

If you're a SaaS company, or a bank, or an insurance company, and you have a regulatory or contractual requirement of a certain availability percentage, how do you detect your authenticated, secure environment actually provides a user interface that is available and functional, instead of a white screen because of some uncaught Javascript exception?

A Frontend Platform will offer the right level of observability for Frontend applications. Not depending on how each product team has implemented it, but available to everyone in a standardized way.

That's a lot of effort. Where do I start?

Building a Frontend Platform is not an effort to be taken lightly if you want to do it right. The great thing about it is that -in most cases- you can take small steps and iterate quickly on what does and doesn't work. Whatever it is that causes your Frontend Developers the most stress, is usually the best place to start. 

Is it keeping your dependencies up to date? Maybe start with centralized lifecycle management on a few important dependencies by having the migration done in a scripted way by the Platform team. Are your pipelines slow? Focus on creating a fast, standardized pipeline. It can be any of the above mentioned areas. What matters most, is that it should bring real, and immediate value to the teams joining your Platform.

It is however vital that your organization treats this as a topic that you need to assign permanent budget for. Building a Frontend Platform isn't a one-off. It isn't a side-job for Product teams. If you don't allocate permanent resources for this, you are set up for failure.

Also, don't try to start building one thing that works for your entire organization at once. Find the most Frontend-heavy area in your software development organization and see what they run into and start experimenting with a few teams. If it works for them, you can productize and scale the effort. More on that in later articles...

Conclusion

The growing complexity and cognitive load placed on Frontend Developers require a dedicated and strategic solution. While general Platform Engineering addresses broad DevOps challenges, a specialized Frontend Platform is essential for tackling the unique frictions inherent in Frontend Development.

From managing a fragmented ecosystem and complex build pipelines to ensuring design consistency and handling dependency updates. By creating a compelling internal product that offers curated frameworks, libraries and tools, a design system, centralized dependency management, and clear architectural guardrails, organizations can abstract away this complexity.

Treating the Frontend Platform as a permanent, evolving product is not merely a technical upgrade; it is a vital investment in Developer productivity, experience, and the long-term stability and velocity of your organization's Digital Experiences.

Notes
1. Yes, you can spin up Web Workers, or use Service Workers, but let's not get into that