End the Tyranny of a Limited Backend

A few years ago, I chatted with an old friend who was an engineering leader at a growing company, and he told me a story that I’ve thought about many times since. At the time, his company’s website was not converting enough visitors into registered users, and the business depended on that conversion rate.

His story went something like this:

The head of marketing comes to us and says: “Right now, users have to give their email address, create a password, and verify their address by clicking on a link in their email before they get access to the logged-in experience. We want to eliminate as many steps as possible, so once we get just an email address, let’s bring them right in.”

On hearing this, the engineers protested immediately. “We can’t do that,” they said. “Password and email verification are required fields in the database. The backend’s entire notion of a logged-in user is based on the requirement that they’ve created a user account with a password and verified their email address.” 

After a pause, my friend asked the team: “So, what should we do?”

“We should tell marketing we can’t do this,” the engineers said. “The backend doesn’t support it.”

My friend replied, “That is exactly the wrong answer.” 

And he was right. The lesson my friend imparted to his team that day is critical for every product-driven engineering org to internalize: The backend’s purpose is to power the user experience, not limit it. 

Party in the front, business in the back

Your platform’s backend is the place where it stores and structures data, where the business logic lives and the algorithms run. The frontend is the customer or user experience, the place where human beings interact with the software. 

Modern platforms separate the backend and frontend into two distinct parts, and this separation is healthy. Backend concerns, technologies, and architecture are usually very different from the frontend, and they can be abstracted away, maintained, and upgraded separately. As such, the backend and frontend usually have different engineering teams with different skills working on them, with the understanding the two sides must work together at defined integration points. 

But both sides are not equal.

When it comes to powering great customer experience, it’s not the frontend’s job to work around what the backend can’t do. It’s the backend’s job to serve the user needs on the frontend — every time.

However, too often, we see our clients try to work around their platform backend’s limitations and accept them as a foregone conclusion. Many times, the backend runs on a legacy architecture that became entrenched over the years, with maintenance and support teams just making sure it’s up and running but not evolving. 

Often we see product teams actively avoid digging into the backend for all sorts of reasons — political, budget, engineering skill set. Legacy backend systems especially become a monument to a past time, set in choices and architecture and by people who have long gone. Success is just that it’s running at all because there’s no budget or team assigned to owning, upgrading, or replacing it.

So the frontend team accepts what works and what doesn’t as a hard limit, and by doing that, they let the backend dictate what’s possible. This approach hamstrings any product innovation effort and leads to mediocre results.

Customer experience drives the whole stack

Required fields in the database should never determine visitor conversion flow. A slow or anemic API, scattered microservices, or a legacy server configuration shouldn’t be the reason why a product or app’s experience is subpar or works a certain way. Serving current user (and business) needs is the job of every layer of the stack — not just the frontend. 

In a healthy engineering organization, innovation and modernization on the frontend drive backend evolution to keep pace with user needs. When you’re creating new possibilities in the user experience, the backend must support them.

One of my favorite examples of this is when a user experience challenge pushed Facebook to invent a faster, more efficient kind of API:

Back in 2011, the smartphone revolution was in full swing. That’s when Facebook’s engineering team faced a problem: Mobile phone data connections had high latency and low bandwidth, which resulted in a slow user experience.

To render the Facebook News Feed, for example, a mobile device would need to make several requests for different kinds of data to the servers, like: “Get me all the latest stories for this user’s feed. Okay, now, for each of those, get the comments associated with them. Now for each comment, get me all the replies and the name and photo of the person who posted them.”

All these different requests took several seconds of load time, which meant impatient users spent less time on Facebook. To solve this problem, Facebook engineers set out to define a way to request all the data needed to render a screen in one shot. The result was a new query language and specification called GraphQL.

Today, GraphQL powers apps and platforms across the web because it’s faster and more efficient, and it enables quicker and easier changes on the frontend.

Put another way, great platforms evolve frontend-first. When you think about redesigning or modernizing a user experience, know that you’re not just putting a new coat of paint on the walls. Sometimes you have to move a wall or two or add on a room. So be ready: Truly modernizing your customer experience will drive change all the way down the technical stack, front to back.

Gina Trapani (she/her) is CEO at Postlight. Send her a note at gina.trapani@postlight.com or follow her on Twitter.