02 — Frontend Basics for the Backend Dev — Enough to Collaborate, Not to Specialize

When the backend roadmap insisted I know HTML, CSS, and JavaScript, my instinct was "my stack starts at the port." Writing it down fixed that misunderstanding: the goal isn't to become a frontend specialist, it's to know enough of the trio to design APIs that serve real screens, and to debug across the seam where my responses become someone else's pixels. [1]

The framing that helped is ownership boundaries. The frontend owns rendering; I own the data that gets rendered. But the boundary is a conversation, not a wall. If I design a response shape that forces the frontend into ugly workarounds — fields they don't need, data split across endpoints, types that drift — I've made their job harder and my own API worse. Knowing what they do with what I send is what lets me send the right thing.

HTML: the structure my data eventually becomes

HTML is the markup language that gives a page its structure — elements defined by tags, organizing text, images, and interactive controls into a tree the browser can render [2]. I don't write much HTML as a backend dev, but two things about it matter for how I shape responses.

First, the browser ultimately renders HTML, and HTML is a tree. If my API returns nested data (a post with its comments), the nesting I send tends to become the nesting the frontend renders. A clean hierarchical response maps to a clean DOM; a flattened response with IDs-to-resolve forces them into extra requests.

Second, forms still exist. When a frontend submits a form, the browser can send it as application/x-www-form-urlencoded or multipart/form-data — not JSON. My backend has to accept those content types, not just JSON, or I break the simplest submission path the platform gives them for free.

CSS: presentation, and why it rarely changes my API

CSS describes presentation — layout, color, typography, the visual aspects of the page [3]. This is the layer that least affects what I do. My API returns data; what the frontend does with it visually is their concern.

The one place CSS brushes against backend work is responsive data needs. A desktop layout might show a table with ten columns; the mobile layout shows a card with two. If those come from one entity, I'm back to the over-/under-fetching tension — and the answer (field selection, or multiple endpoints, or GraphQL) is an API design decision, not a CSS one. Knowing the layouts exist is enough; I don't need to write the CSS.

JavaScript: the client that calls me

JavaScript is where the frontend meets my backend most directly [4]. It's the language that runs in the browser, issues fetch() calls to my endpoints, and processes the JSON I return. From my side, the things that matter:

• fetch() is the call. The browser's native API for HTTP requests. When the frontend's JS calls my endpoint, this is almost always what's underneath. It means they can send headers, bodies, and credentials — and they can fail on CORS, which is my problem to configure, not theirs.
• They consume JSON. The de facto contract is that I return JSON and they parse it. Returning HTML from an API endpoint (unless it's explicitly a server-rendered route) breaks their client.
• They run async. Their calls are promises; my latency is their loading state. A slow endpoint isn't just slow — it's a spinner on a screen someone is staring at.

// the call I am answering, from their side
const res = await fetch("/api/posts/42");
const post = await res.json();

Three lines, and every one of them is a constraint on me: the URL has to resolve, the response has to be JSON, and the time between request and response is a UX they're measuring.

The seam: where my responses become their pixels

The reason the roadmap lists these at all is the seam. Every API I write is consumed by code running in one of these three layers — usually JavaScript calling fetch, rendering into HTML, styled by CSS. The shapes I choose either fit that pipeline or fight it.

The practical questions I now ask before shipping an endpoint:

• Does this response shape match what a screen renders, or does it force the frontend to transform/discard half of it?
• Have I grouped related data so the frontend gets it in one round trip, or split it so they have to chain calls?
• Is the content type what their client expects (application/json for JS callers, form types for native forms)?
• Have I set CORS headers so the browser lets their JS read my response?

That last one — CORS — is the clearest example of why a backend dev needs to know the frontend exists. CORS is a browser security mechanism; the error shows up in their console, but the fix is a header on my response. If I don't know browsers enforce same-origin policy, I'll blame their code for a problem mine causes.

How I use this

I don't write production HTML/CSS, and my JavaScript stays on the server. But I read the frontend's code when designing an endpoint, and I run their fetch calls in the browser console to see what they actually receive. The habit is to treat the API as a contract between two halves of one product, not a thing I ship in isolation. When a screen looks wrong, the first question is whether the data I sent was right — and that's a question I can only answer if I know roughly what they do with it.

References

[1] Cloudinary, "What Is Front-End Development?," 2024. [Online]. Available: https://cloudinary.com/guides/front-end-development/front-end-development-the-complete-guide

[2] freeCodeCamp, "Responsive Web Design Certification — Co-Learn HTML & CSS," 2022. [Online]. Available: https://www.freecodecamp.org/learn/2022/responsive-web-design/

[3] Mozilla, "What is CSS?," MDN Web Docs. [Online]. Available: https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Styling_basics/What_is_CSS

[4] "The Modern JavaScript Tutorial," javascript.info. [Online]. Available: https://javascript.info/