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.
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.
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.
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.
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.