Developer Evangelist @ Square. I have a love/hate relationship with JavaScript. When I am not programming/gaming/reading, I know way more than I should about shipping and payments now.
A frontend is an I/O (input/output) layer intended to provide functionality that will process the interactions from users. You can have an application that solely lives on that front-end and never needs to communicate with a central system.
Fairly often though, you're wanting to take those inputs from these different frontends and do something with them. That's where you have NodeJS (or whatever backend you want) come in. If you want to store things in a database to be accessed later, your backend would facilitate this. If you want to communicate with over services, you would likely need to use a backend to do this (since you generally shouldn't store secure keys/tokens on untrusted systems).
So far this is a fairly non-specific explanation that probably doesn't sufficiently answer what you would concretely need a backend for, but unfortunately the question itself is very open-ended. To a similar extent that a question like, what exactly do I need a frontend for? might be.
There is a somewhat decent explanation on Quora over at here.
Hopefully this helps someone a little bit in understanding what a backend is :)
Student from Germany who fell in love with coding and the tech industry after pivoting from a traditional career in banking. Currently pursuing a Bachelor's in CompSci.
So, if I understood your correctly, I basically need a Backend for two cases:
I need to store the data in a central place and therefore have to use some backend that connects a database to my frontend.
I have to use more than just one technology or service and therefore need a backend that connects their functionality with my frontend?
Speaking of Frontend, I always thought that every interface that is used by humans is a frontend - e.g. my React WebApp, a Flutter mobile app or even some GUI written with C++.
Your points are pretty spot-on - another would be to alleviate the computational load on the client. Like you say in your post:
a lot of logic already works in the Frontend
This is true, but it requires shipping a bunch of JavaScript over the wire, and making your users' computers do the heavy lifting on their end. You can reduce bandwidth by cutting down the amount of javascript you're transmitting and reduce the computational needs of your client-side frontend by offloading a lot of that logic to your backend. This will let your application work for people with lower resource requirements, and potentially reduce your client-side attack surface.
As far as what a "frontend" is, I agree with your list. All of those are frontends for a user to interact with your application.
Developer Evangelist @ Square. I have a love/hate relationship with JavaScript. When I am not programming/gaming/reading, I know way more than I should about shipping and payments now.
Totally agree with Ben here. That's why I had tried to narrow my definition of a frontend to I/O since its really just the layer for interacting with humans.
Offloading computation from the client is a really great point, and is the exact reason something like SSR (server side rendering) exists, since not all clients might have the computational power to be performant enough to match expectations.
Student from Germany who fell in love with coding and the tech industry after pivoting from a traditional career in banking. Currently pursuing a Bachelor's in CompSci.
Let the server lift the heavy weight of complex logic seems like a nice solution! In school we tinkered around with PHP for serverside rendered HTML forms (for calculating Body Mass Index and stuff like that) and I never got the point of it since you're able to do the same stuff in the frontend with JS.
I think, slowly I'm getting the bigger picture behind all that! 😊
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A frontend is an I/O (input/output) layer intended to provide functionality that will process the interactions from users. You can have an application that solely lives on that front-end and never needs to communicate with a central system.
Fairly often though, you're wanting to take those inputs from these different frontends and do something with them. That's where you have NodeJS (or whatever backend you want) come in. If you want to store things in a database to be accessed later, your backend would facilitate this. If you want to communicate with over services, you would likely need to use a backend to do this (since you generally shouldn't store secure keys/tokens on untrusted systems).
So far this is a fairly non-specific explanation that probably doesn't sufficiently answer what you would concretely need a backend for, but unfortunately the question itself is very open-ended. To a similar extent that a question like, what exactly do I need a frontend for? might be.
There is a somewhat decent explanation on Quora over at here.
Hopefully this helps someone a little bit in understanding what a backend is :)
So, if I understood your correctly, I basically need a Backend for two cases:
Speaking of Frontend, I always thought that every interface that is used by humans is a frontend - e.g. my React WebApp, a Flutter mobile app or even some GUI written with C++.
Your points are pretty spot-on - another would be to alleviate the computational load on the client. Like you say in your post:
This is true, but it requires shipping a bunch of JavaScript over the wire, and making your users' computers do the heavy lifting on their end. You can reduce bandwidth by cutting down the amount of javascript you're transmitting and reduce the computational needs of your client-side frontend by offloading a lot of that logic to your backend. This will let your application work for people with lower resource requirements, and potentially reduce your client-side attack surface.
As far as what a "frontend" is, I agree with your list. All of those are frontends for a user to interact with your application.
Totally agree with Ben here. That's why I had tried to narrow my definition of a frontend to I/O since its really just the layer for interacting with humans.
Offloading computation from the client is a really great point, and is the exact reason something like SSR (server side rendering) exists, since not all clients might have the computational power to be performant enough to match expectations.
Thanks a lot @deciduously and @mootrichard !
Let the server lift the heavy weight of complex logic seems like a nice solution! In school we tinkered around with PHP for serverside rendered HTML forms (for calculating Body Mass Index and stuff like that) and I never got the point of it since you're able to do the same stuff in the frontend with JS.
I think, slowly I'm getting the bigger picture behind all that! 😊