I started my new project Fullstack Frontend to help frontend devs to go fullstack without in-depth knowledge of backend development.
My opinion is not that backend devs became obsolte, it's just that more and more backend things are now simpler and available for frontend devs. (Severless, hint, hint!)
But I think, I have to start from the beginning to motivate this idea.
So in this article, I will explain what led me to start the Fullstack Frontend project and why you, a frontend dev, might need a backend.
If you think I forgot something important or have a different opinion on some of these points, I'm eager to know! So comment away!
If you aren't interested in my motivation and just want to read about reasons you need a backend, you can skip the next part! :D
Tech Evolution
When I started doing Web development in 2006, my main job was to build simple homepages and online shops. Not everyone could do this, and I made good money with it.
Things changed.
Over the years, it got easier to build such software, even for non-technical folk. Frontend technology evolved into something available to people who would have needed a CS degree before.
This let the hourly rates for basic web development drop drastically, and devs had to find something else to do, which wasn't that easy and in demand.
Luckily, the wheels of time don't stand still, and other opportunities showed up. Mobile development was a new path to choose, and many desktop apps also were reimplemented as SaaS solutions. Things that were impossible or very hard for the average dev slid into the realm of possibility and demand for their skills were save.
Backend Evolution
Every part of the stack evolved in these years, also the backend.
Node.js, for example, enabled JavaScript devs to dive into the backend and build their own servers.
The Cloud also became significant. First, we had to buy servers and wait for weeks to get them. IT people had to be paid to put the servers into the racks.
Then we were able to rent them. Which cut the costs and time to a new system.
I can fondly remember the first time I used VMWare in 2001, a virtual server? That was crazy talk!
With that technology, cloud providers were able to supply us with new servers with just a few minute's notice. If you choose a managed server, they would even use their own IT staff to maintain it!
Infrastructure as Code came along, and the DevOps movement let the devs pour into IT like nobodies business.
Serverless
Now we have serverless. A term that describes managed cloud technology that can be paid on-demand and scales effortlessly.
I think this is the next significant shift. Some things will become easier for non-tech people to do, so no dev needed anymore.
The free capacity on the frontend and the simplification through serverless leads to some backend tasks moving to the frontend.
In the end, backend devs get more time to do other things. Building highly specialized platforms or maybe integrating more technology like AI or such.
Why Do You Need a Backend?
After all the talk, why do you need it, the backend? Can't we just build stand-alone frontends? After tall, the lower the latency, the happier the user!
Well, there are multiple reasons.
- Hosting
- Central Data Access
- Privacy & Security
- Integration
- Resource Constraints
- Cost Distribution
Hosting
The most obvious reason for a backend is hosting.
If you build a HTML based web app, you need some way to host it, so your users can access it in the end.
If you build a native app for a mobile or desktop system, you can get away without hosting. Back in the days such applications were distributed by DVD, CD, and even floppy disks, via real stores, haha.
Central Data Access
In today's world, many people use many devices. They have a desktop, laptop, tablet, smartphone, smartwatch, smartTV, game console, etc.
Even if they don't like the idea of social media or online communication with other people, at least they need a way to share information with themselves. Carrying USB sticks around isn't very convenient.
You need a way to facilitate that shareability, and a backend simplifies that process.
I think peer to peer tech will get much easier to handle too. As the devices get better performance and internet connections to get faster, p2p-tech will eat many backend use-cases for breakfast.
Privacy & Security
If information is shared over a network, it can help to have a backend in the middle that protects the user from each other.
Something that is tended to by a professional, so consumers don't have to learn much before using it.
It can also help to protect your company. If you have one place of entry, you can keep track of who enters. You can lock-down your essential assets, be it content or algorithms, so only people who paid for it can use it.
Integration
Often your systems aren't stand alone. You want to integrate some of the vast numbers of APIs on the internet. Problem is, if they don't allow CORS access, you can't access them directly from within a browser, so you need to route the access through some kind of backend.
In the wake of the JAMSTack, many API/SaaS providers provide CORS access, so you can use their services directly from the client, but it's still some way to go before this is the case for all offerings.
Social Media
Facebook, GitHub, LinkedIn, Twiter, etc. all these platforms can help to ease user onboarding for your app. If you integrate sharing capabilities, it even helps to spread the word about your app.
Payments
Payments are also an important part. Somehow the bank of your customer and your own bank have to find out that you get money. While cryptocurrencies are an exciting peer to peer way to solve this problem, most users don't use them yet, so some kind of backend has to be involved in the transaction.
Legacy Systems
Often a new app is simply just a new GUI for an old platform. With these legacy systems chances are high they don't allow for direct browser access, so you have to go through a custom backend to get the data in and out.
Resource Constraints
Most people around the world use smartphones to access the internet, and for most of them, a high end 1000€ iPhone Pro Plus Extra III isn't an option.
A smartphone can't store the entirety of Wikipedia or Netflix. It is also to slow to train highly sophisticated neuronal networks, and many can't run a machine learning model locally.
Doing peer to peer streaming with hundreds or thousands of viewers will also kill most internet connections.
If you want to deliver high tech services with enormous amounts of data or very high computing or I/O requirements, a backend that provides the resources to do so, is the only option.
Cost Distribution
Like with all of humanity's inventions, it's a race to the bottom when it comes to costs. You don't want to own a farm if you just need a bunch of potatoes a week.
A backend lets users distribute the costs of specific tasks between them. Everybody could do everything locally on their device and pay the costs of those tasks. Still, they could also do it once at a central backend and get the results from there.
Why Don't You Need a Backend?
While there are many reasons you need a backend, there are also reasons you don't need one.
Many tools and games work without an internet connection and the features that need a backend are only additions, but not central to their core purpose.
If you build software to use free of charge, it could be that you don't want to pay for a backend, so you implement the app in a way that it just has to be installed and never has to talk to the internet again.
Privacy and security is a huge point here too.
An app that doesn't talk over the network doesn't need extra mechanisms to protect its users. The safest computer is the one that doesn't have an internet connection, haha.
In the future, when peer to peer systems finally get ready for the masses, it could very well be that all use-cases I mentioned here are gone too and your app will talk with other "clients" over the network without a backend at all, "real" serverless so to say.
Anyway, what do you think about backends?
Top comments (32)
Serverless is just backend by a different name. It sounds like you’re promoting the “Javascript does everything” mentality, which is correct, but you’re spinning it into a weird “there is no backend” world. There’s still a backend anytime an app calls a service. I don’t get the point of this post.
This post is just about why you would need one, wether it's serverless, containers, or monolithic.
I should have split this into two posts, sorry.
Nice post, keep in mind there is almost always a backend when data is involve.The difference relies on WHO manages that back end. Serverless is just a vendor providing and managing the infrastructure.
It really depends on the product, company, and possible regulations.
If it's 'just' a restaurant website that has a bit dynamic content, and you can make reservations. I think it's much better not to build/host your 'own' backend, but just use services. If you have a payment platform, and it needs to be cost efficient and to apply to a lot of regulations, you need your 'own' backend, and you need to think hard about the services you use.
The "build or buy?" question would be the next step, I think.
But you made good points to that question!
Very insightful and fresh perspective! Back-End is changing fast now. Between cloudy/managed services, containers and kubernetes, and now serverless technologies the landscape has changed drastically...for the better! Great questions, answers, and I loved the style of the article. Followed!
Thank you!
Yes, there are many new ways to do backends, each fitting different (but sometimes overlapping) use-cases.
I'm excited to dig deeper 🤓
Thank you writing this article. However, I think I’d like to add something. While Serverless is a more cost effective way to execute code on demand, it in itself introduces a new of challenges, especially when connecting to traditional database systems. Quite a few companies have adopted the Serverless approach and are very successful at things, however, the traditional backend approach to building systems will remain for a long time.
Another point I want to make is that we will see many companies adopt the Serverless approach when they want to introduce an event driven approach somewhere in their already built tech stack. For example, a traditional monolithic Django app that submits data to an Azure Queue that triggers an Azure function or an Azure logic app to process that queue message and perform some action.
Overall, nice article and as I said it can start some very interesting discussions.
Yes.
I'm more of a serviceful serverless proponent and not a big fan of FaaS for APIs either.
You need a backend but there are a hell of a lot of good easy options.
Any recommendations? 🙃
Yes! Postgrest 🔥, Hasura, Sanity.io, plain Postgres with plain node with plain graphql (super powerful combo with endless power). Firebase is amazing for scaffolding a real set of users immediately with its build in auth and you can combine it with options above easily to get the best of both worlds.
lol, hidden power?
Yes doing things in super plain ways is hidden power because your ability to express a system goes unexpectedly way up. You say what you mean and that is good power.
Yes, you're right.
Loved your post. I think a lot about those same things when I think about front end vs backend, nice to hear that others do too.
Thanks!
I think, it's important to know why you need something, so I though, let's start with the question why you'd need a backend before you ask how it should look like.
Whilst what you say is pretty much reasonable on first pass, it is wrong on the second pass. Really sorry.
Yes, we could plug all kinds of APIs in and never worry about a database. We could just store data on a local file system performing regular backups. We could use a restful interface and point the data exchange where we wanted.
I could say exactly the same thing. I could argue I could build an event processing model in a database and a metadata generator and dynamically create the ui code and forget about front end developers. I wouldn't be that disrespectful because whilst there is some truth to it, I know that certain benefits are prevalent from the skill from a ui expert.
Ask any database developer the loops (not hoops) coders go through to avoid modelling data correctly and we conclude they are shirking responsibility.
I haven't begin to go into the many reasons why all developers should learn relational database development even if they ultimately don't specialise in it. Same as database developers should learn coding and some front end development.
I think your article is good but just a little naive. Still giving you a heart.
I don’t think it’s just relational databases either. Data modeling applies to NoSQL and is helpful in scaling. In fact, your data modeling strategy could encompass different data stores where it makes sense and denormalize the data (parts of you service need search? Perhaps Elastic. Parts need bulk writing? Consider Cassandra, I could go on and on). This kind of branches into system architecture, but it’s definitely a more senior skill to have and not necessarily front end dev. Serverless, Microservices, Moneliths are just tools in a tool box. Each one comes with its own problems. I wouldn’t say the OP is wrong, they’re just highlighting a tool they use and makes sense for their use case for their backend needs. Additionally, the OP admits backend is different than it was 10 years ago (containers, kubernetes, cloud adoption etc.)
Don't be sorry. I appreciate your honest thoughts, so thank you for your answer!
I'm totally with you here, I don't think backend development is obsolte, I just think that it's different from how it was 10 years ago.
Would say it like this. There is huge value in data. Set based access is powerful. It goes down to the point of storing a query outside of a compilable application versus having to rebuild a codebase. Yes, there are many smart ways around this but to discount database modelling seems incorrect.
My main concern is the risk of "throwing the baby out with bathwater."
Am certain this wasn't your intention and even if it was, no harm done. Just to blow your mind.
I believe that object oriented programming was started with plato and universals. Now we think that oop is outdated and yet we would not say this because the significance of understanding it is so emphatic to deny it is ridiculous. If we could even begin to imagine universals we would be ahead of almost everybody in today's world.
Deep, but anyway. Had to be said. 😊
I don't know if I understood all that you said 🙃
but at least I understood that data modeling is important and if frontend devs wanna do more fullstack stuff, they should definitly look into data modeling. 🤓
Thanks for the nice articles. Also, Interesting discussion about the importance of database (SQL / NoSQL). But when blockchain/DLT becomes more widely used, then probably the way we see the database would be different. There won't be any centralised database anymore. Everything is distributed on blockchain.
Furthermore, we probably won't need hosting server anymore to host our application, since everything is hosted on IPFS. If cryptocurrency becomes the main payment method, then we wouldn't need payment gateway anymore. The backend logics can go to frontend and/or go to smart contract sitting on blockchain.
The only reason we need backend server/app and SQL database in my opinion is just security/privacy. Security in term of authentication can probably still be done through crypto wallet / public key. But security in term of storing the private key, for that probably backend server and centralised database would still be needed.
Just my 2 cents.
love your post I have a question tho. If I want to integrate stripe into a website and I'm hosting my website with X hosting company. Can I just add the backend for the specific function I want to implement in this case accept payments. Or do I also need to create routes, middlewares, etc? Thank you so much for your time.
Depends on "what the users pay for"
If you sell static stuff (images/videos/music) or physical products it could very well be that one function could be enough.
If you have some kind of SaaS, you would mark users as "subscribers" in one backend function and then would have to check this flag in every route that needs to be protected.
This was really help you!!
I recently deployed my own website - so most of the front end is done. I’ve been researching and trying to learn all I can about backend systems. I was wondering if you (or anyone that reads this) has any advice / recommendations on working with backend servers. I’m currently trying to implement an active contactForm sheet for my website. Where people can input their information and once they click submit I'll get an email and they'll get a verification that it went through. Any advice, or recommendation on how to proceed would be appreciated - many thanks in advance🔥
I'd recommend looking into AWS Amplify, Netlify, or Google Firebase.
hi.. i'm totally new this area.. i had some R and SAS programming knowledge but not js or html.. i have questionsssss regarding what i am planning to do, to create a simplified "randomized" maths practice platform with "model".. but the first question will be.. do i need a backend to store those "models"?? or i could just put in at the front end?? i can let you know more info if you don't understand what am i saying..
The first question is, can this model be implemented with JavaScript? If yes? Then you can put it on the frontend.
The next question is, do you have any reason to "hide" the model from your customers? For example, the model is your unique selling point and you want to keep competitors from stealing it. Then you have to put your model on the backend.
Also, performance could be a limiting factor. If you want smartphone users use your model, but it's too big or too performance hungry, then you would have to run it on a big backend system.
Insightful post with a lot of good points! Looking forward to the rest of the series (:
Glad you like it. 🙃