I started my new project Fullstack Frontend to help frontend devs to go fullstack without in-depth knowledge of backend development.
My opinion is...
For further actions, you may consider blocking this person and/or reporting abuse
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. 🙃
The question should be reversed - why do we need frontend, as backend is always needed in real estate applications.