The vast majority of things a frontend engineers need to do can be done without knowing anything about the backend other than the API. If you work on different parts of the frontend for long enough though, you'll probably run into something that does require some backend knowledge. Here's the short list of topics that a frontend engineer should know about the backend.
The backend has finite resources and can only handle a certain rate of requests. In general, you should not care — the frontend should do what it needs to do to create a great user experience and the backend can optimize and scale. Still, network requests to the backend are not free, and they are not all equally expensive (in terms of resources used).
How do you measure how expensive a call is? A rule of thumb is that writes are more expensive than reads, so the more data is changed, the more expensive it is. An example of when this would be prohibitive: let's say you're implementing Google docs. You want the user to never lose their work if they exit, so you save often. Can you save on every single character insertion and deletion though?
Your backend servers would probably not be able to handle it, or the cost of infrastructure to handle it would be unnecessarily high. Throttling to only save after the user stops typing can achieve 99% of the intended effect without the huge cost of the extra 1%.
Let's say you want to poll your backend for changes. You want the most up-to-date version of a doc, so how often should you make a request? Reads are much cheaper than writes, so you can do it more than writes, but there's still a limit.
The limit depends on many factors, like max number of active clients at any given time, backend infrastructure, and budget. If you think a change you're making might approach the limit, talk to the backend team. Otherwise, you might end up DDOSing your own company.
You should expect and prepare for every backend request to fail at some point for some users. It's an inevitability that the backend will go down at some point, or for specific endpoints to fail while the rest still work. You should distinguish which calls in your app are critical where a failure constitutes showing an app-wide error screen with a message to try again later, and which calls can be handled with graceful experience degradation (e.g., grey out the button for that feature with a hover error message saying it's currently unavailable).
The backend and frontend should use the appropriate HTTP status codes (to an extent). Hopefully your backend doesn't treat every error as a 400, but some will for simplicity. The frontend should know every status the backend plans to return. Don't parse error messages to detect a sign-in failed, a 401 is more consistent.
Don't retry the exact same request if you're given a 400 because it probably won't work again, but a 500 might indicate the server is just rebooting and a retry would succeed.
Other properties of HTTP worth knowing:
If some business logic for a feature you're building can be done on both frontend and backend, where should you encode it? In general, you should do it on the backend. Reasons:
As a security protocol, if a request to the backend comes from a different domain, it will be rejected due to being a "cross origin request". This is called the "Same Origin Policy". This trips people up in development, because ports count as part of the domain, and people are usually running an NPM/Yarn server for their frontend and the backend on another port, thus making every request a cross origin request.
To prevent this, the server gives a one-time token for every session, so that the attempt will fail due to not having the token. This is called a CSRF token. Attach it to headers of authorized requests.
Every request goes through multiple caches on the way to the backend. If you visit a website for the first time, wait for it to load, and then reload the page, the web app loads faster than the first time because your browser's cached assets like favoritewebsite.com/static/script.js. What if you want to make a change to script.js? You change the filename.
Let's say you switch script.js to script.js?v=2 in what index.html references. The cached script.js becomes irrelevant, since there will never be another request to it (unless index.html is cached!
Assets are usually very infrequently changed though, and it's worth leaving them out of automated cache-busting for performance reasons, and just manually updating them when needed.
There isn't too much a frontend engineer needs to know about the backend to be effective. You want to be T-shaped -- specialization in one vertical with some broad knowledge on a variety of things. You never know how topics from the backend might come to benefit your skills as a frontend engineer. Want to learn more about the connection between frontend and backend? Make some diagrams at https://terrastruct.com -- the only way to be certain you understand something is to explain it to others yourself.
Previously published at https://terrastruct.com/blog/what-frontend-engineers-should-know-about-backend/