So, I'm familiar with how to build a website using HTML, CSS and JS. I'm also quite confident using ReactJS to build webApps and even fetch data from some APIs.
However, I've never used nodeJS or similar technologies to build myself some kind of Backend. What exactly do I need it for? And what kind of code does a Backend typically contain, as a lot of logic already works in the Frontend?
Is it just sort of an API that connects my frontend to some database?
Top comments (8)
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! 😊
The other answers here are good. I thought I'd add a little bit of detail that you might find interesting.
Traditionally, the backend has been a single application that handles things like authentication/authorization, persistence (database), calculations that might not be appropriate or feasible on the client-side, etc. You mentioned a background in banking, so as an example, it would not be a good idea to have a client-side application be responsible for maintaining a customer's bank balance. It might display this balance, but the server would be responsible for handling transactions.
These days, you can do a lot with a so-called "serverless" architecture. Of course, there's still communication with a server, or multiple servers involved, so the name for this approach is questionable. But you don't have to host that code directly in a "monolithic" application. Instead you can use cloud-computing resources like AWS Lambda to perform specific functions that your client app needs.
If your application just needs to do a few things on a server, this "serverless" approach might be something to consider. It's also used as part of a microservice-based application architecture, when scalability (handling many users concurrently) is important. For example, Netflix uses this kind of architecture extensively. Your netflix app in the browser or on your phone doesn't just connect to a single application. Instead it connects to various services to handle small bits of functionality, and these services may, in turn, communicate with other services. That gives Netflix a lot of flexibility, although it also means coordinating all of these back-end services becomes much more complex.
Thanks @nestedsoftware ! I already thought of posting "Explain serverless like I'm five!", because the word itself is confusing as it's directly connected to servers...
So, to wrap it up, "serverless" means just using someone else's server instead of setting up your own?
Yes, that's right. One big part of this idea is that the cloud-based provider can dynamically scale (up or down) the resources allocated to your server-side code based on your needs.
Another part of it is that you may connect your client-side application to various different providers (or different services with the same provider) to do different things. For example, if your application needs to send email, you may use a cloud-based email provider to do that. If your application needs to handle logins/accounts, there are providers for that sort of thing using oauth. If you need to store data, you may add a cloud-based service to persist data. And so on - you can add different services as you need them in a loose coupling, rather than in a tighter integration typical of monolithic server-side applications.