Developers August 5, 2020

What would be your backend if you start developing from zero?

Jiří Kratochvíl @sedrickcz

I am planning to create a mid-size to large size web app and still thinking about what backend I should use. Right now I am mostly frontend dev, but I have large experience with Ruby and Rails.

Would you start developing a new backend with Rails now in 2020? Or would you use something like Django, Node.js with Express, or even go serverless with Firebase? Or something else?

For me is still Rails number one choice as I already know it and I can start immediately without learning other language/frameworks.

Also, my idea is to go with a swarm of microservices, so I can replace Rails later where I need something more scalable or more performant.

WDYT?

  1. 33

    If you know Rails, use Rails! Better to build as quickly as possible and refactor once you've validated your idea.

    Microservices come with significant drawbacks (configuration/infrastructure management, discovery/communication) and don't really have any advantages at small scales. Unless your app needs a very atypical architecture for some reason, I would build a monolith until you have absolutely no choice but to break it up.

    1. 4

      100% this. hard to argue with rails for most web apps :) if it’s an api then there’s a strong argument for serverless or something there but rails and the bonkers amount of gems available is hard to argue with for web apps!

    2. 3

      This is such a great comment. "If you know Rails, use Rails! Better to build as quickly as possible and refactor once you've validated your idea." was exactly my first thought.

    3. 2

      did you read https://m.signalvnoise.com/the-majestic-monolith/?

      I'd echo the sentiment, stay with what you know. It doesn't matter that much.

      1. 1

        I did not but that's a great article!

    4. 1

      This is the only answer, and the correct answer

  2. 7

    Also, my idea is to go with a swarm of microservices

    The golden rule is that the monolith comes first, then split in microservices when you have already figured out the data domains, absolutely need to and if it provides clear advantages. Having microservices from the get go is an over kill for a young business as it will require more effort put in development, devops, auxiliary tools (logging, monitoring).

    It's fine only if you want to expand your development/devops skills and learn new stuff. But that's only for personal projects because there is no stake and you can do it at your own pace, not for (hopefully eventually) revenue generating businesses.

    So yeah, monolith first, microservices later :) Gitlab is a monolithic application in Ruby on Rails, Facebook started as a monolithic PHP app, Instagram started as a monolithic Django app. Keep it simple, stupid.

    1. 2

      Github is a still mostly a Rails monolith, too.

  3. 4

    Definitely PHP using Laravel, then using Laravel Forge for easy hosting from any cloud provider with automatic deployments from your GitHub commits. Automatic and free SSL certificates included.

    1. 3

      Laravel + Forge + VueJs + Digital Ocean are a great combination. You can pretty much build any web application using these tools/frameworks.

    2. 1

      For me too.

      I love learning new stacks and building little pet-projects with new tech. But if it's a product I'm serious about, I'm using Laravel for a couple reasons:

      • It's what I'm most comfortable and efficient with
      • Great ecosystem from dev ops to front-end solutions
      • You can get a great stack running for pretty cheap
    3. 1

      I agree. Definitely Laravel if it was me.

      1. -1

        This comment has been voted down. Click to show.

    4. 0

      Or even Heroku for hosting. Stupidly simple deploys.

  4. 3

    Rails is still the best thing for building stuff out quickly, but if you want to pick up something new but still feels a bit similar, Elixir and Phoenix are really good. It's a lot like Rails but can handle high traffic a lot better. There's even a book for getting into it.

  5. 2

    I would use Django, but that's just because I know Python better than I know Ruby. Go with what you're comfortable with, in your case that would be Rails!

    1. 1

      Django too, I find it very mature, documentation is excellent and I love its batteries included philosophy. It has been my favorite backend technology since I started programming.

  6. 2

    So I have been able to make this decision myself recently, given that I'm developing Nodewood, and it's intended to be a boilerplate framework for SaaS businesses. Some key choices I've made that I think will really pay off:

    1. NodeJS on the back-end. Since you'll be using JavaScript on the front-end, being able to use JavaScript for the back-end means you can write common functionality (validation, models, libraries, etc) once, in one language, and share it between the two. This makes it quicker to write the original code and quicker and safer to maintain going forward. It also means less mental switching from JS to some other language when writing back-end code.
    2. Monolith, not microservices. As a new SaaS, one of your big strengths is the ability to move quickly. Microservices come with a big overhead, and code sharing between them means you have to manage internal libraries and versions and all that. A monolith with well-defined sharing policies makes it easier to develop, and easy to break up later, if you need to.
    3. MassiveJS + PostgreSQL. PostgreSQL is just such a good database. Every time I'm using something else, I keep wishing I had certain Postgres features that aren't available. And MassiveJS is my favourite data mapper. Instead of building ActiveRecord-style models that have to remain on the backend, MassiveJS returns objects that you can use to populate models via the constructor, which means you can load them from the DB or from API returns, which means (see #1) you can use your models and calculation code directly in the front-end.

    Obviously, this is going to be a very personal choice for everyone involved - if you know Rails best, then yeah, Rails makes a lot of sense. Being able to get your app out there ASAP to get feedback from your customers should probably be your biggest consideration, so keep that in mind when making your decisions.

  7. 2

    I was in the same position a while ago with the Under Cloud, where I had the choice of:

    1. sticking with Vue and Laravel;
    2. or switching to Vue and Node.

    In the end, I chose option 2, and while I've learned tons I do sometimes regret it, given how fragile JavaScript is at times, and that it's not possible for the frontend and backend to share the same code, at least not without a bit of lateral thinking.

    That said, Vue and Node do give open up possibilities that wouldn't be as feasible with PHP (at least as far as I'm aware), such as a mobile version from much the same code base.

  8. 2

    Making a rational decision is always tough. First, it really depends on whether you plan to work alone or not. Access to a talent pool in your niche/geographical location can be a decisive factor.

    I am a Django developer myself, because it suits my needs incredibly well, I am a Python guy and don't want to spend time learning something else.

    But, from a technical perspective, there's nothing wrong with Rails in 2020. There are many open projects popping up, such as the backend of dev.to, or discourse that just show you how far along you can go with Rails and that it is not at all a dead tech.

    Particularly, in my case, it took me a while to see the value of Docker, but I now consider it the biggest addition to my toolchain. So it may be that you can refresh your tools, but not the tech stack in 2020. And the trick part here is that it is a bit more ambiguous regarding what you 'should' use.

    And if you go to path of microservices, one of the things you have to remember is that they are independent, therefore you can have microservices in many different languages. In that case you can pick the tech that better suit that very specific job. Not exactly the same as a website, but I do have some 'micro'services in C because they are incredibly performant, while the bulk of my program is Python.

    Nothing wrong with starting monolithic and slowly offloading things to microservices.

  9. 2

    Whatever you know. Double down on marketing and validation even before you have a product....

  10. 2

    Both frontend and backend of OrgPad runs on Clojure(Script) and it is amazing. There is some learning barrier but then one is so much more effective than in anything else I have ever used. The key difference is emphasis on simplicity and just doing your business: after learning it, you spend very little time writing bullshit stuff the programming language wants from you but it has no value for your business. Getting instant feedback from your app via hot code reloading and REPL is life changing. Take a look at this amazing talk: https://www.youtube.com/watch?v=oytL881p-nQ.

    1. 1

      Demo looks beautiful, did you use a react-based binding?

      I have deep knowledge of clj(s) but lately I hesitate to start new projects on it, it's just too heavyweight if that's not my sole focus.

      1. 2

        The technologies and tools we are using in OrgPad are described here: https://orgpad.com/o/Cx0toaAblKpKUSZasDxsxK.

        I am not sure how much effort it is needed to start a new project in Clojure(Script). The setup to get frontend running is quite easy due to Reagent and Re-frame stack. Backend requires some knowledge since there are no big frameworks outside Luminus and Fulcro (which I have no experience with).

  11. 1

    Thank you all for an amazing suggestions and support. I decided to go with Rails as I know them really well and after those years I am still in love :D

  12. 1

    Whatever you know, as long as it fits your use case as everyone else says, but aside from that I'd use phoenix framework in elixir. Covers all the same use cases as rails and laravel, just as easy to use and a great dev experience, with high performance and realtime (websockets) being a first class feature. Liveview is a killer feature to me, and I have several production apps for clients built in it. Just a lovely way to develop web apps.

  13. 1

    Firebase. It makes a lot of stuff super easy. Authentication, hosting, serverless API deployments, password reset emails, roles and permissions, etc.

  14. 1

    I feel obligated to answer this. I’ve made a few mistakes and a few good decisions.

    My stack is modern. I’m using Prisma 2 and Node.

    Don’t worry about the language and scale too much. If you can get AWS credits, buy a fairly expensive server if you need and RDS. You can easily downscale if you’re wasting.

    Stick to solving the core problem. I’d keep things as lightweight as possible. Stick to serverless as much as you can.

    I’ve run into a bottleneck with Vercel. So I have one function that I rolled out using pure AWS lambda. Meaning I have to use aws-cli, zip the folder, then ship it to the lambda function instance.

    Other than this specific use case. I’ve been using Vercel serverless functions with ease and pleasure. They are a layer on top of lambda making it easy to manage and deploy. Start with this.

    Don’t spend all your mental time and energy on this. Please talk to users, you’ll probably ignore this as I would. I’d be so focused on getting an answer to this question id blow past this advice.

  15. 1

    Rails is still great. It sounds like you will be fine just using Rails.

    Only if you rather go serverless I would go with Firebase, Firstore and Coud Functions. It’s cheap and allows you to build a full stack app from your frontend codebase. I’m making a SaaS boilerplate for this stack with React: https://serverlesssaas.com/.

  16. 1

    Go with what you know, specially if you are going with a microservices architecture, at that point everything can be replaced, pick a tech for the inter communication like protobuf or json, and then move on.
    When done re-evaluate, find the places where you have data proving its not good enough for whatever reason (i.e. Performance), then work on replacing, restructuring, or whatever for that microservice.
    If you follow the idea that the best language is the one you already know, then you are set.

    <KeepCoding/>

  17. 1

    Next.js. I wish it was a thing when I started building our e-commerce application. It would have simplified so many things.

  18. 1

    Has anyone checked out https://www.8base.com/ for this? Could be an interesting different approach. Spend more time hacking on the front-end I would imagine.

  19. 1

    I had this conundrum a few years ago. I ended up learning node - I use node for everhthing now. It was worth learning and more and more stuff is moving to node - rails is not as common now.

    So my vote is node and Google Cloud Functions, it’s super easy to get up and running and you get scalability for free.

  20. 1

    Well there are few points we should mention here:

    • Start project with technologies you know well. This is because you will just work faster and finish your project sooner. Also, you would get more experience with those technologies.
    • Start project with technologies you like. For me this is very important, because I can get really bored with some technology I do not like, and sometimes I decide to not finish the project, especially if it my personal project (happened to me once). But I immediately switched to some other technology (I lost a huge amount of time...)
    • Microservices vs Monolith. If you don't have hundreds of thousands of users there is no point going with Microservices architecture. You will lose so much time in managing all the parts, configurations, servers and such. Well build monolith architecture app will serve millions of customers.
  21. 1

    Yep, as others advise, use what you know. And only go to microservices if your product evolution demands it, or you know that you will need such team & architectural segregation. (Unless you are building a Netflix size product this is unlikely at IH startup stage)

  22. 1

    If you really want to grow a business out of your product, then use Ruby on Rails as you are comfortable with it. Use all your existing knowledge to build it and launch it on the market.

    You should not choose non-familiar tech if learning it is not your first priority. I jump from one stack to another for every project and it takes a lot of time to finish one project. But my thought was always learning first and business second.

  23. 1

    Firebase is the easy to go call as most of the things are handled easily. It has Db, Sotrage, AUth and much more all at one place. To start small and just to test out things and if you dont want to spend much time developing everything from scratch then firebase is the best one to use.

    A lot of successful startups use Firebase - even dropbox, duolingo and many more. Do check

  24. 1

    Since I have a good grip on Java with Spring Boot, I would go with it.
    I would suggest you to go with whatever the language you have a command in.

  25. 1

    It would depend on the project, picking a framework or language and then deciding how to build is not good practice. Of course, you are limited by your skills but you should consider things such as database access, long-running tasks, messaging and what third party API's you might want to access and what languages do the SDK's come in. A good developer should always be looking at expanding their skillset.

    You say the project is going to be large scale so assuming that happens you need to consider the availability of developers - you may build an amazing Rails application but if you can't find enough developers to scale up then you will be in trouble and of course salaries need to be considered. I have worked on projects where we used Elastic Search which was great until we scaled up and realised the costs of renting and maintaining a cluster would bankrupt the company.

    If it were my decision and you were building a basic API I would use node/javascript. There are lots of frameworks that let you build distributed monolithic applications that can grow out to a microservices architecture. MoleculerJS is a good place to start looking, it might not be suitable but it will give you a good idea of what to look for. It's far better to spend some time now planning your back end in full rather than hit a bottleneck down the road. Certainly, don't get distracted by what is right way and wrong way either - just ship it, fix it and rebuild as the project fog disappears.

  26. 1

    I would go with what I'm comfortable the most unless you're itching to learn a new programming language and you got time to learn it on the go. If that's the case, Node / Golang might be good options for you depending on the nature of your backend.

  27. 1

    If you're building an MVP first, I'd 100% go with Firebase, Cloud Firestore to be specific. It gives you a lot of nice things out of the box (authentication, real-time listeners, easy data modeling) and you can do all data reads/writes from the frontend. The only learning curve is figuring out how to write security rules but that shouldn't take more than 1-2 days to learn thanks to their amazing learning resources.

  28. 1

    I am a humble fronted dev who do things by myself. In my opinion Jamstack is the route to take. I built automail.org with limited serverless knowledge. It took me around 1 week to build it and it has payment gateway, checkout stuff, newsletter forms etc. And I do not maintain any server. I just have very simple two serverless codes for mailing. :)

  29. 1

    If you've got experience with Rails, use it. Don't spend time on learning a new framework, just to improve your performance by a tiny tiny margin. The most important metric in development should be time-to-market and other development speed markers.

  30. 1

    Hi jiri , it all depends on what your stack is , unless you're going to hire someone else, i would highly suggest you use whatever technology you're comfortable with as well as doing a thorough research on the languages/framework scalability. In addition to that i would highly suggest you don't neglect the database aspect of your webapp , sql/no-sql
    and the cloud hosting services which offer most of the administrative support to manage them including azure , aws or even gcd.
    Personally im currently in the midst of developing my own mid/large web app using python - flask framework as the 'main' back-end. If you want to have a more thorough discussion feel free to message me

  31. 1

    "Would you start developing a new backend with Rails now in 2020?"
    why not?

    Rails? ohh yes! whichever language you're most comfortable with.
    In my case, I have been a backend java developer, so I am more comfortable with java springboot framework.
    Also, I want to ship fast so I don't want to spend time learning new language.

    I believe, as long as you are meeting needs/expectations of end users, its fine. :)

  32. 1

    Well, if you really have complete freedom, think about if you really need a web app. Web apps are a must for consumer casual applications, but, in many occasions, you may be better with a native app. It is crazy how, when you get out of the web, you realize how other environments are better in many aspects, the main one being using a full-feature programming language (compiled, strongly-typed...).

    I actually implemented my 'dream' technical stack for enterprise applications discarding the web architecture. If you wish to know more, feel free to have a look at the project Github page

  33. 1

    Node.js and Typescript is what we use. But in the end, I would go for whatever you can build the most solid and fastest.

  34. 1

    As others have said, if you are good at Rails, use Rails.

    Ruby (and Ruby on Rails) is not by any means outdated and it's used by many big companies for giant applications. It's a long run and tested software that continues being actively developed. It's true that you will not play with the new fancy technologies and features from other languages but you will develop much faster as you have already the knowledge. Also, it will be easier to find employees if you require them in the future as it's a widely used language and framework.

    Disclaimer: I'm a software engineer with more than 18 years of experience

  35. 1

    Core php and django.

  36. 1

    I would go with Laravel, It makes writing stuff easier. No setup and no boilerplate. You can start focusing on your business logic immediately.

  37. 1

    If this isn't just a fun side project, and you know and like rails, go with rails.

    It's still a perfectly viable choice in 2020 and is being used by tons of companies to create their backend. It has a huge community and it's easy to find help and gems for almost anything.

    The nice thing is that you can always build extra functionality down the line using some of those other technologies if you want to, like serverless functions to do some async processing, or split out a node microservice if you realise the monolith isn't suited to a particular task.

    As someone who loves all of the technologies you mentioned - try not to get sucked into the hype because something looks cool. If you hit a point where rails isn't a good fit for a particular problem, then it's time to look at other solutions, but until then you just can't go wrong with a default that you know and understand well.

    Simplicity and productivity are king. It's very rarely a good idea to deviate from something you know well unless you have a very good reason.

  38. 1

    Don't choose a backend solely to choose a backend. Every language has it's advantages.

    I decide which language/stack to choose based on what the application requires. If it requires high-performance low-level integrations, then Go. If it requires basic network level stuff, then Node. More often than not, it'll be a combination of many different stacks.

    Another consideration is what you are comfortable with. It's often more important to iterate faster than to choose to most efficient stack. You will NOT face scaling or performance issues until you have like a 1000 customers at least. Just pick what you like, and go from there.

  39. 1

    Always go with what you know. When you are turning an idea into reality, you want your thoughts and plans to be converted into working code as fast as possible.

    Learning new frameworks and languages is great for pushing yourself and learning what is out there, but you are really not going to be productive in any new language/framework until you have had months/years of practice in it. The last thing you need is to add development time to your project because you have to constantly search Google or StackOverflow for workarounds or techniques, or if you have to go back to the online manual to keep seeing how a simple 'for...' loop syntax should be.

    The stack I work with would easily be considered 'outdated' by most developers today, but it still works, and I can put out new features and updates at a fast rate, and it is stable and used by thousands of customers (with tens of thousands of their employees also using our SaaS) every day.

  40. 1

    I am absolutely in love with Golang and the Gorilla web toolkit. The language is so simple, elegant, and fast to compile.

  41. 1

    I've been using faunadb. It's like a db but on CDN distributed globally. Is blazing fast. Has native GraphQL support but I have been using their query language FQL which is really powerful.
    https://fauna.com/

  42. 1

    Hi Jiri,

    I'm unclear why AWS is not more popular on IH. I admit when Uclusion first started using it a couple of years ago it was pretty unrefined. At this point though I would think Lambdas in Node or Python, API Gateway, S3, etc. would be the obvious choice for all but the smallest projects.

    1. 3

      I think a reason it's not more popular here on IH is that it's pretty complicated to get starte. There's a steep learning curve, while the general consensus on IH is "build quickly with what you know and are familiar with"

    2. 1

      One reason is that it's very expensive! You can build comparatively cheaply on a VPS like DigitalOcean/Linode.

      Another is that it can be very complicated. I would be very happy with my life if I never had to try to wrap my head around IAM again 😬

      1. 2

        We have been using it in free tier for years. You need a LOT of traffic to break free tier.

        Sure there are complexities but if you try to build your own system you will end up with complexities also. On IAM there is no longer any configuration required. Maybe people tried using earlier AWS versions and got sick of it that way - I can see how that could happen.

  43. 1

    It depends on the details, but generally, I've had a pretty good experience with sanity.io

  44. 1

    Highly depends. If it's something that has to be built in a short period of time, I'd go for Python. Not Django however. The documentation is second to none but there are breaking changes in each release. I recently started a personal project which I want to get off the line as quickly as possible and I opted for falcon. It has incredible performance but it's a bit... Too low level and requires too much boilerplate code. A week into it, I realized I had unintentionally built a simplified framework on top of it and I plan on open sourcing it soon. Back to the topic, if I have enough time to plan ahead, go would be my first choice.

    1. 1

      Aaand let's reply to myself cause... Yeah... I open-sourced it https://github.com/axegon/Milvago

  45. 0

    There are lots of great answers from a tech perspective, so let me offer a marketing perspective:

    I don't know what your product does yet, but if it's aimed at a programmer audience, then there's value in building your technology in the same language as the largest segment of your intended market uses. That way, any engineering blog articles you write will naturally enter their zone of attention and also the first draft of example code in your docs etc. will better resonate with that audience. You'd be more locked in to that community.

    Here's a concrete example of what I mean:

    I've built v1 of my indie hacker screencasts business in Rails because I know it well. But in (purely marketing) ways I regret not choosing JavaScript/Typescript, since then the code examples I show will be immediately familiar to a 10x larger audience. There may be value for me in spending a week rewriting.

Recommended Posts