A large missing for myself and probably others is an accurate mental model of how frontend and backend systems interplay with each other. As a result, a lot of mental "soup" comes into play when it comes time to get your React/Vue/Angular talking to a backend system. This becomes especially problematic when you layer something as complex as an OAuth Auth Code Grant or other Auth systems on top of that.
So how can one think of frontend and backend systems communicating accurately while cutting out jargon and confusion?
Let's borrow from Richard Feynman, a theoretical physicist whose genius lied not only in his discoveries in the various fields of physics, but in his ability to explain deeply technical concepts to everyday people. He developed a technique where someone explains something to themselves in simple terms to discover gaps in their knowledge; an "Explain Like I'm Five", if you will.
Before reading ahead, pause and try your best to explain how a frontend and backend system communicate to yourself as if you are five years old. Don't use jargon (a five year old doesn't know what an API is), and keep this grounded in daily examples a five year old uses (mom's smartphone, a toy train, playing outside).
//
What did you come up with? Here's what I said:
When your mom comes to pick you up from school, first she has to get in her car. When she gets in her car, she does a couple of things: she opens the door, puts the key in the starter, turns on the engine, and then cranks up the radio to her favorite tunes! All of that is like how a frontend and backend work together. If your mom is a website's 'frontend', she is making her car, the websites 'backend' do things for her so that she can move on to the next stage of her journey for picking you up. For example, she tells the car to turn 'on' by putting her key in the ignition and turning it. She tells the radio to turn 'on' by pushing the on button and turning it up. In the same way, a website's frontend tells the backend what it wants, and the backend responds by giving the frontend what it wants. If the car didn't turn on, then it would be broken, right? The same can be said about the website frontend and backend - if the request from the frontend isn't fulfilled, something is probably wrong with the backend. Or if your mom tried to turn on her car with a banana instead of a key, that would be like the frontend of a website being broken so that the backend doesn't understand what she wants from it.
How was that? A little wordy and bizarre, but it showed me a huge gap in my own understanding: the fact that the implementation of that front and back end system communicating to me, is still a little fuzzy. The magic that happens to make the car actually turn on when the key is turned to me, still seems like a black box. But at least now I know what to drill - that very same implementation. And from drilling that implementation, I can refine my mental model.
Top comments (2)
I don't remember where I saw it as it was really long ago, but the best comparison of front-end/backend is to a store.
As a customer you see shiny and light storefront, with all the things on the display. Storefront is the front-end. But every store has much more things hidden behind the personnel-only doors: a storage room, an office where they plan and manage things, a cleaning supply closet etc. Everything in the back is the back-end. Front and back-end communicate between themselves in the same way workers do in the store: front workers make a request to the back (e.g. scream from the top of their lungs). Back-end workers look for that thing that front wants for a bit and bring it to the front.
Thats fantastic. I especially appreciate the screaming at the top of their lungs. I'm going to think of that every time I write a fetch() request from now on :D