Backend and Frontend for Dummies

Backend and frontend — the mythical pair. It’s talked about all over, especially if you are looking at tech related news or jobs.

Here’s my take on the matter. I distinguish the two, and possibly even contribute some original thoughts. I try to avoid jargon as much as possible, because I know it often throws people off the track.

When we are using Facebook or reading mails through Gmail, we are engaging both frontend and backend technology.

Backend is the brains of an app — containing the rules of the game, data, and technical means of delivery. In Gmail, backend is about storage of our email messages, the data needed to store contacts; it’s about rules of validating you into the Gmail (allowing login). The backend keeps track of activity (“access logging”) so that both You and Google’s technical admins can make sure the service is safe from prying eyes. When you change a password, the change goes to the backend.

The role of a backend is to basically tell the frontend “what is going on — data-wise”. So backend, in that sense, is in charge of maintaining a sane status quo — recording meticulously the history of the system and user’s preferences. In multi-user systems such as social media sites, an important part is maintaining the relationships between possibly millions of users.

Frontend, on the other hand, looks at the user’s setup (mode of using the service, like browser flavor, display size, language needs, area of interest geographically — in some apps), and then the frontend renders the data into a view — and possibly includes cues such as sound. Finally the actual hardware (mobile phone or laptop) makes the graphics pixels and sounds that the frontend has commanded it to do.

Frontends nowadays are somewhat decoupled from the actual backend, so that even in case of a network outage, people are able to often use the app.

The way this orchestration between frontend and backend easily creeps into a spaghetti is why Facebook made React. They figured that the whole user interface entanglement with the backend started to resemble quantum physics in an eerie way. In real IT world, developers do have to understand what they’re doing. In quantum physics, there’s a saying that if you think you understand quantum physics, you don’t — so it’s okay not to understand quantum physics!

Back in the early history frontend was much more diligently just a lens into the backend data. Throughout time there’s been a huge leap forward in frontend. This comes however with the cost of added complexity. One could ironically say that in order to read an email nowadays, probably half a billion CPU cycles are spent on rotating the necessary cogs — whereas twenty years ago it was significantly less. Well, naturally. You didn’t have those billions of CPU cycles to spare! (Parkinson’s law on Wikipedia)

Frontend engineering in practise?

Modern frontend is about turning plans into actions:

• layouts
• splicing an app into Views
• the “nitty-gritty” hard work

The frontend nitty-gritty includes:

• making items that user can interact with (buttons, other widgets)
• making and tweaking animations (these help guide users “in and within”)
• taking appropriate action on items (writing JavaScript code)
• physically fitting data appropriately to view items
• often, aspects of I18N (internationalization)
• managing aspects of the app’s color scheme
• dark mode toggle!
• getting the whole visual outlook of the product aligned
• ensuring quality

Frontend mastery comes with practise. A lot of practise. In web development, you are facing CSS. Learning CSS well is a must-have first step. It’s like drafting with pencil and paper, but in the digital realm we are also talking about learning to do outlines (box), neat corners, soft corners, shading or filling areas with a color; fitting elements within available visible areas. It’s about centering — or aligning to Left, or Right. It’s about learning to stack, prevent overflows, distribute items evenly, and use special effects like Shadows, transparency and animations.

Frontend tech is pretty much developing all the time. Basically nothing has changed in the computer hardware level, except in a predictable way: graphics cards are faster to draw shapes, and there’s more pixels in the screen. End of news for the past 20 years. So how come frontend development is so complicated then? It’s due to the way abstractions, features and ways of actually getting to the pixel level in CSS happens.

What started out as possibly a small experiment style thing has blown into a full digital “library of Alexandria”: most everything you could even think of presenting on-screen is accompanied directly by desgnated CSS element — or, if not, you can craft your own tweaks to achieve the goal.

Having said that, probaly the most frenetic part is now in the past: web browsers have done great job in standardizing the range of supported CSS. Microsoft stopped competiting largely in the browser wars, by dropping development efforts of its Edge browser and

The legend has it that backend engineers could work without ever taking even a glance of the visual outlook of what comes out! All one would need is check that data is consistent, available, and it comes out of the API through requests.

Possibly true.

Backend engineers can set metrics to track, that basically do not have much to do with user experience. Reality? Maybe not so simple. Regards to backend engineering, there are actually three groups of important users:

• your team mates, working on the frontend
• co-developers of the backend
• the very ultimate end-users (using both frontend and backend)

Ultimate end-users will be the ones who deal with the whole product. Co-developers would like to share the vision and keep track of what you’re doing. Well, in all honesty, this is just basic software engineering best practises, regardless whether it’s frontend or backend.

Thirdly, the team mates working on frontend are in a bit different kind of relationship with you. Coupling the development of both frontend and backend properly, team-wise, in human terms, is a Good Thing to Do. Otherwise there’s going to be slips and out of synch stuff. The other party is possibly waiting (or worse: assuming) that a part becomes completed in the backend. Frontend can’t function without backend having the support baked in.

Take the car factory analog: the product rolls through the entire factory in a comfy fashion, while both frontend and backend stuff is being bolted into it. A finished product comes out of the pipeline.

That’s, by the way, also why CI (Continuous Integration) is sometimes called Continuous Delivery. They both mean essentially that the machinery can keep going, products come out, and there’s not many critical stops in the factory while all this is happening. It took a good twenty years of engineering culture experience in sofware that Continuous started happening.

Hope you enjoyed the tour! Let me know. I’m very eager to feedback. Thanks, J