I've been developing apps for over a decade and created so many projects, including side projects and commercial products. Every time I create a new project, I ask myself the same question: which tech stack should I use.
I am an "underdog" person, going with the non-popular framework every time. Never use the same stack twice. But let me tell you this, it comes with a price.
It is super fun and exciting to learn new technologies, but the thing is that you never become an expert. You always start from scratch and learning to do your first steps. Getting to know the eco-system and community of these new tools takes time. It comes with so much overhead.
Going with the underdog means that there is not much tooling or knowledge available and you will have to answer your questions, the hard way!
Don't get me wrong, there is so much potential in choosing the underdog. I've been using Nodejs ever since its early days when Ruby on Rails was the only thing developers talked about. Eventually, it turned out to be brilliant. When everyone just started to get into it, I had a year or so of practical experience. But I also made some wrong choices with Polymer, for example. I put my bet on web components and Polymer, and a few years later, we are still not there, and no one talks about Polymer anymore.
Maybe it's me getting older, but I've decided I need to settle down. Fewer adventures equal to more things done. There is nothing wrong with following the community's path. On the contrary, it takes a greater man. I think part of "leveling-up" as a developer is to choose the "not-so-cool" stack just because you can get the work done and be complete with this decision.
And here is what you expected to get from this post:
Front-end
Front-end is where I can never find my balance - always going from one stack to another. As I mentioned, I went hard on web components and Polymer and moved on to Vue, due to lack of support and community. I've been working with Vue for two years while keeping my eyes on React. Recently I decided to move on to React. For the simple reason, there is so much knowledge about React, and the tooling and eco-system available is not something Vue can compete with. There are many examples of platforms that choose to embrace React and leave the Vue community empty-handed. Although the Vue community is not small, it's still a few steps beyond. Maybe it's because Vue is much younger. And honestly, I love Vue. It's super easy to get on board and build performant apps.
So here is my front-end list:
- React - for all I mentioned above.
- Nextjs - De-facto standard for server-side rendering (SSR) React apps.
- Styled components - I had a hard time settling on this one because Tailwind seems so attractive, but again Styled components community is much more significant.
- Vercel - Again the standard for deploying Nextjs apps (for an obvious reason 😉)
Back-end
Compared to front-end, I'm very steady on my back-end stack for a while now and feeling very complete with it.
- Node - This is by far the most prominent community out there with so much knowledge
- Typescript - After years of using Javascript, it's super hard to maintain a project without types. Typescript is my way to go.
- Fastify - Ok, I admit, you got me here. Fastify is an underdog compared to Express, but it's just fantastic, and it has everything I need.
- Apollo Server - I've been using GraphQL for over a year and recently started to get hardcore. Just like I will prefer Typescript over Javascript. GraphQL is a typed way to implement your API and get so much flexibility for your front-end apps. Apollo is the most popular framework to implement a GraphQL server and client.
- PostgreSQL - You can brag about your NoSQL database all you want, but most of us simply don't need it. Going with the old school SQL is probably the best choice for most use-cases. Super easy to use, it is battle-tested, and many services offer managed servers. I feel very confident about the decision here, and it never failed me down for years now.
- Kubernetes - For the DevOps among you, this decision might be controversial, but honestly, it's the best platform out there. I'm using Kubernetes since its beta days and even contributed some code. It has an active community and, by far, the biggest one for DevOps tooling. This platform can simply do anything in terms of deployment. If you have a complex architecture for your back-end, this is the way to go, at least for me. With the rise of managed Kubernetes clusters, it is now much easier to get on board.
Here you go, this is my tech stack in a nutshell, pretty happy about it now. Hopefully, I will serve me well.
I would be happy to take any question here or on Twitter.
Daily delivers the best programming news every new tab. We will rank hundreds of qualified sources for you so that you can hack the future.
Latest comments (40)
Thanks for the article. You don’t use typescript in react, on the front end, only on the back end?
What state management in React have you settled on?
Thanks
I use Typescript for everything! I can't build typeless apps anymore 😂
Haven't settled on state management yet. Roaming between context API, apollo graphql, and other alternatives. Any ideas?
David, you are totally right. I couldn't say it better. I wasn't aiming to declare this is my stack and it's simply the best. I wanted to share my long experience of chasing one stack to another until I decided I've had enough and I need to "settle down". I thought other developers might benefit from this experience and can relate. I wanted to create discussion around the topic just like the one we're having and get other devs opinions.
I tried to use "I" and not "You" in the article to highlight that this is my personal experience and not a "golden rule" for anyone else. I guess I didn't make it clear enough. There is a use case for every technology!
@shaijut yeah, the Tech Empower benchmarks is certainly a place to start if we're talking about near raw performance. You've got a lot of options if you're I/O rather than CPU-bound. I don't typically look at those benchmarks until someone points them out, because obviously there's more to technology choices than absolute raw performance -- there's ease of adaptability going into it from where you are and the aforementioned things that I mentioned originally.
I will note that I've never done .NET and I've heard a lot about .NET Core and it's phenomenal for people in that ecosystem.
And you also can't look purely at languages, especially higher level ones like Ruby on their own without also considering the runtime. Ruby can run on the JVM with Rubinius and JRuby, but both are on the JVM offering concurrency, but I've never tried it. The JVM has a plethora of offerings, but the ones I'm familiar with are Scala with Akka (actor-based) and Clojure (LISP) and (CSP/communicating sequential process).
Typically when we're I/O bound, concurrency is something we often reach for and every platform offers their own concurrency model and primitives/facilities to do it with varying degrees of difficulty. Async programming can be very very hard (i.e. debugging data races). I'm looking at Node and Go here.
I would also consider what sort of end-to-end service you're creating/making -- is it web-based? Is it confined to a single machine where you want non-blocking I/O like a CLI? But you did mention cut cost on a cloud provider, like Azure. I can't give you a definitive answer, because the type of I/O you're doing also matters. Right? Are you going over the network? Are you talking about the communication being I/O bound within a VPC (virtual private cloud) where you're doing RPC? Perhaps the bottle-neck (vary rarely) could be the way you're marshaling data, and maybe a switch to binary encoding away from JSON may help with MessagePack, etc.
Thanks, Suppose I want to make ecommerce website and host in cloud. Which web framework is best in terms if performance and can cut cloud cost.
Curious as to what you perceive to be the thing that would run up costs the most... In e-comm which is a broad term (I've worked in e-comm), most things are just I/O-bound, in my experience, though, but this is NOT a recommendation, I've only been able to compare from going to Ruby (on Rails) to Elixir (Erlang VM). We could serve the same # of requests that we had typically auto-scaled to ~8 machines during peak (high traffic) down to a single machine/host. Your mileage may vary depending on the technologies that you end up selecting. This matters little if you don't build anything at all -- I'd consider it a pre-mature optimization. It's never about pure performance early on, that should only happen when you're at scale and the bottlenecks become glaring, then do they become tackled. It is impossible to solve and design for every use case and what your early consumers do on an e-comm site may be very different from what they do when your site has evolved. Look at Amazon -- it used to just be an online bookstore with no AWS, no platform for individual sellers, etc.
What do you think about callbag and redux-saga for side effect handling?
I don't have experience with those, unfortunately.
Pity that you've said goodbye to Vue, I have a lot of sympathy for Vue and if it would have arrived first, ahead of React, then it would probably have won the battle. But since your strategy is "choose the winner with the largest market share and the largest community" then React is the obvious choice. React is becoming dominant, it's really "winner takes all".
I also think it's pitty because Vue is a great library! I agree that Facebook is pushing it hard so it's very dominant
Quite interesting post, I did learn about a few new things I did not consider when selecting my stack. I have been developing apps with Node.js and express for a while but always have a hard time deciding on the database and a suitable ORM I have used Sequelize in the past but it does fail at some complex querying tasks. I would love to hear your advice on this matter. 😁
Thank you! 🙏
I'm using Typeorm and I'm super happy with it. I can manage to run pretty complex queries
Is there a reason you chose Fastify over Next.js API routes?
You are totally right. For small scale project next API is more than enough. My project consists of several frontends so I need a central GraphQL API to serve them all
Totally agree.
You need to trust on your guts as well. But after being so adventures and always choosing the non go with the flow stack. I want to rest a bit.
I think Tomasz makes a fair point. Your choice is based on a local maxima — the Node community. I think, Ido, you hinted earlier in your post that you’ve invested in Node earlier on, but the part that will probably make some cringe is declaring that it was absolutely right. That will help the selection bias of those already using JS, but is a door-closer for many to challenge their beliefs. I’ve worked with Rails heavily, NodeJS (a bit) and many other languages and platforms. There’s a reason why Jose Valim, left the Rails community to create the Elixir language, and TJ Holowaychuk, the most prolific Node package contributor and creator of Express left Node for Golang. Everything that you’re using, to me, is very heavy handed. It can be done with Erlang or Elixir with the Phoenix Framework and Postgres — service discovery comes free, self-healing and automatic restarts is free, observability is free. K8s is non-trivial. It’s getting better, but doing it because you know how to do it is overhead because if you’re working in a solo project, you just want to get to writing business logic and not all the “yak-shaving”.
I don’t mean to say the above as a my stack vs your stack duel. It is non-trivial to learn an entirely new language and/or platform as you’ve stated along with all the overhead of learning the community and running into walls without immediate answers. All I’m saying is to not declare anything as best. There are trade-offs associated with every technology choice, and each person needs to weigh them against what they know, what they’re optimizing for (learning or delivering), community (access to help), and performance and cost (concurrency)
Nice 😄,
I agree
use the best tool for the Job. I am interested in performance and cost, Do you know any server side programming language which is perform-ant fast and uses less memory for heavy I/O operations ? Basically I want to cut the cloud cost inAzure. Any benchmarks forRuby, Go , Java or C#?The developers' community. I know it's very abstract but usually, you can quantize it but number of articles, tools, and the size of the eco-system.
I am building an app with almost the exact same stack, but with hasura instead of nodejs
I try to follow the community voice as a rule of thumb. Of course, there are exceptions for everything.