This is an anonymous post sent in by a member who does not want their name disclosed. Please be thoughtful with your responses, as these are usually tough posts to write. Email sloan@dev.to if you'd like to leave an anonymous comment or if you want to ask your own anonymous question.
I'm brand new to development and am trying to understand the difference between front-end and back-end development.
I think I kinda understand that front-end is what the user sees and back-end is how the information is retrieved, but I imagine there's a bit more to it than that. I would really appreciate hearing others' thoughts and explanations on this.
Analogies and examples would be very welcomed! Thank you all very much. 🙏
Latest comments (36)
Hi there! I made an analogy for myself around the full stack.
In frontend, there are 3 main languages you'll work with HTML, CSS & JavaScript. I see HTML as the structure of the house (you want 2 bedrooms, one living room, a kitchen etc.). CSS is how your house is designed (the color of your walls, which room is the biggest one, where to place your plants around your furniture), while JavaScript provides the functionality of the house (how your doors should open, how your lights should work etc.).
In your house, you also need electricity, water, TV cable etc so your house will have better functionality (although it can be a good place for you to sleep in just as it is). I see this as the backend.
Hope this helped a bit. Good luck!
This is an awesome explanation! Really appreciate ya sharing.
Thank you, Michael!
Frontend basically is the stuff sent to the user and typically involves a user interface and some sort of method to securely communicate to the backend. The backend is basically where the data is stored, payments are processed, and anything that the users would not be able to see.
Front-end writing interface, facing the user. Back-end writing logic to ensure the normal operation of the system
Simple explanation here:
Frontend: The website
Backend: The database and servers
I think you nailed it. That's exactly what front-end and back-end are.
At least as traditionally defined.
But I think modern software development should force us to rethink things. For example, what about tooling? What should we call the development of Gradle or Turborepo? DX is super important, but the tools that make it happen don't neatly fall into the front-end vs back-end dichotomy.
So one way to look at this is Product v Platform. What if Product was everything that users pay for while Platform is everything that allows you to build and scale?
Anyway, just food for thought, but I think you are totally right.
There are many good answers here.
But I want to chime in with something that I think is getting overlooked.
It's important to point out that frontend and backend are terms that grew up around the web and programming for the web. They aren't great terms for someone starting out, unless that someone intends to only program web applications like Google Docs or Spotify-in-the-browser.
(Which is what many of us do, and that's totally fine. It's just a distinction that should be mentioned.)
There is a lot of other programming. Code is running inside your microwave, your car, your smartphone, your television, etc. And also inside your computer: such as the browser itself.
Usually, none of these things fall under the "frontend" or "backend" programming labels. Instead, you will hear labels like "mobile," "OS," "desktop," "embedded," etc. "Frontend" and "backend" relate only to stuff that happens after you type a URL in a browser and press enter (at least, the way most people use these terms.)
If you are starting out and want to think about any programming outside of things that you can point a web browser at and interact with, then forget about "frontend" and "backend" programming for now. Just focus on learning a good language and the rest will follow.
On the other hand, if what you do want to do is create something like Facebook or the site you're looking at right now, then they're good terms to know and you can focus on one or the other. In that case, think of frontend as the programming related to anything that happens within the browser. And think of backend as everything else. It could be data access, a long-running process like generating a file to download, some kind of communication with the outside world like sending someone an email or text, placing an order, or many other things. These are usually performed by "web services" which are also accessible via the web, but just not in the browser-renderable formats.
HIH
As most have already said your fronted is a user interface which I'd call a client. A client can be a browser, a mobile app, a desktop application.
A client has a backend which provides services used by the clients.
To simplify. Development is a car.
Frintend is car body, tires, glass, bumper etc. outer parts.
Backend is engine, transmission, gas system, inner parts you can't see.
Coder Coderexplains it pretty well for the visual learners: youtube.com/watch?v=kQeAY_13XgYFront-end developers build applications primarily used by humans.
Back-end developers build applications primarily used by IT systems (computers, other applications e.g. front-ends, etc.).
Is a GraphQL query front end or back end?
The query is crafted by the user but the resolver is designed by the API team
But in the end, the GraphQL API is still consumed by another IT system, not a human.
GraphQL is just another way of accessing the backend, just like REST, SOAP, exchanging raw byte data, etc.
It doesn't change the overall structure of the backend as a system.
that was kind of the question. Would you expect a FE developer to be able to form a GraphQL query to get the data that they need or would you expect the BE Developer to tell them what the query needs to look like.
Why would this be of any relevance for my idea of backend and frontend developers?
It literally does not matter if the frontend dev writes GQL queries theirself or get them by a backend dev.
Ideally, the frontend dev should be familiar with the interfacing technology used - whether it's GQL, REST, or something else. It's their job to gather the data provided by the backend.
I think it is critical as to where the line is drawn between FE and BE which is why I asked the question. Would you expect your FE developer to be able to structure a complex query to fetch the required data efficiently, or would you expect the BE Dev to develop the data Map that the FE then renders
For a concrete example.... Although I was doing both BE and FE on this project I had data that was in 4 dimensions: style, size, colour, location. Do I take the computational hit and create nested JSON of all attributes which makes presentation easier (equivalent to a noSQL document model) and if so so I so size in colour or colour in size, or just use object keys and dynamically map the data from the arrays using their keys (more like a RDBMS model) the latter is more flexible but requires run time overhead. The former is probably more responsive but with a larger time to first interaction and only optimised for one access pattern.
Personally I would only expect a Senior Dev to be able to make that call and in reality it is more likely to fall to the BE dev to structure the data as required for consumption by the FE. Not saying that is right, just practical reality. And if that is the case should the multi -level JSON object be created at the database or API level where there is likely to be more processing power and the ability to cache the model.
to demonstrate i'll say, Imagine a Mobile Phone.
What you see is the Frontend, and what is inside the cover that runs the phone is the Backend.
In a javaScript stack:
Frontend is built with: Html and Css and
Backend is built with: Node.js
I've explained the difference with the help of the human body here. Lots of memes but quite accurate actually :) It explains microservices and testing as well.
In restaurant terms:
Frontend: the chef, waiting staff and front of house
Backend: the people who built the restaurant, plumbed in the gas and electric
Absolutely disagree.
Waiter is the http transport. They take a request (order) and return a result (food). They have no say in how the result is achieved
The chef is the web server. They take the request and pull together whatever resources are required to achieve the result. The chef is very definitely back end.
You can think of the maitre'd as a load balancer; they make sure that no one connection (waiter) is overloaded and limit the number of diners so that the chef is not burnt out by too many requests (DDoS)
What you described as back end is actually infrastructure and architecture. They are important but not necessarily relavent to this discussion
Im glad that atleast the idea served some inspiration and you whisked up another analogy
Well this is a new kind of disagreement 👨🍳👩🍳 - I have kids, didn't sleep well last night and I think I wrote this at 4am...
You think of it how you like thats alright by me. I can barely read your reply anyway 🥴🛌
Here is my personal definition.
Front end: Whatever runs on your browser engine, which means, locally. Be it a user interface, or internal computing. It's not necessary for users to see a component on screen to be considered as front end.
Back end: Whatever runs on the server, located elsewhere on the globe that can be connected via a specific network protocol.
front-end and back-end development are still very broad terms, even within each category there are multiple domains that can be very different from each other.
But let's say in terms of feeling, I think the biggest difference is that front-end in general produces a lot more code and you get instant gratification (like a artist painting a picture) vs backend is more logical and computational oriented (like a mathematician). Obviously, front-end logics can be complicated, but I think in general you spend more time trying to visualize things comparing to backend.