The Backend Skills That Made Me a Better Frontend Developer

"Full stack" is usually described as knowing both sides. In practice, the value isn't the second skill set — it's that you stop making decisions on one side that are expensive on the other, because you can see the whole cost.

Four specific things changed how I write frontend code.

1. Understanding the N+1 query

The frontend asks for a list of projects. Each row shows the owner's name. The backend fetches 50 projects, then runs one query per project to get its owner. 51 queries for one screen.

Before I'd written any backend code, this was invisible to me. The endpoint was just slow, and slow endpoints were somebody else's problem. Now I recognise the shape from the frontend side — a list where each row shows data from a related entity is an N+1 waiting to happen, and I ask about it during design instead of filing a performance ticket in month three.

It also changed what I ask for. "Give me the owner name on the project object" instead of "give me owner IDs and I'll fetch them" — which is the same N+1, moved to the client where it's worse.

2. Knowing what an index does

I once built a filter panel with eight filters, any combination allowed, over a table with two million rows. It was elegant. It was also unindexable — every combination is a different query plan, and you can't index for all of them.

Knowing this changes the design conversation. Now I'd ask which filters people actually combine, index those paths, and make the rare combinations explicitly slower with a clear loading state rather than pretending everything is equally cheap. That's a *product* decision, and it can only be made by someone who knows both the query cost and the user need.

3. Caching layers and where truth lives

A frontend cache, a CDN, an application cache, and the database all hold a version of the same data, and they disagree. Once you've debugged "the user updated their name and it changed in three places but not the fourth," you design differently.

• You invalidate deliberately rather than hoping a TTL covers it.
• You know which data can be stale for a minute and which absolutely cannot, and you set staleTime per query accordingly instead of globally.
• You stop hand-patching client caches on mutation and start invalidating, because the server may have computed fields you can't reproduce.

4. Authorisation is not a frontend concern

Hiding the delete button for non-admins is a UX affordance. It is not security. The endpoint has to check, every time, regardless of what the UI shows.

Obvious when stated. But before I'd built an API, my mental model of a permission was "which components render" — and that model produces apps where the button is hidden and the endpoint is wide open to anyone who opens the network tab.

The corollary that matters day to day: never send data to the client that the user isn't allowed to see, even if you don't render it. A filtered-out record in a JSON response is a data breach with extra steps.

What full stack doesn't mean

It doesn't mean equally expert at both. I'm a frontend developer who is competent on the backend — I can design a schema, write the API, and reason about query performance, and I'd want a specialist for database tuning at scale or a serious infrastructure design.

It also doesn't mean one person should build everything. The advantage is in the conversation: being able to say "that endpoint shape will cost us three round trips, can we denormalise the response?" and have it be a two-minute discussion rather than two sprints of ticket ping-pong.

If you want to pick it up

Not a course. Build one small thing end to end, with a real database — not an ORM you never look behind. Postgres, a schema you designed, queries you wrote. Then deploy it and watch it be slow.

The slowness is the lesson. Everything I've listed here I learned from something being slow or wrong in a way I didn't expect, and none of it would have stuck from reading about it.