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.
Do you get nervous before starting a project with a new stack? 😖
I know I do. Actually, I get both excited and nervous. 😅
Trying to answer all the questions before I start...02:46 AM - 30 Jul 2020
0
3
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.
Top comments (40)
I am new to this stack, I have another question. Suppose you have a
APIand Client side App inJavaScriptwhich make requests toAPIto get some data.How can we securely store
APIkey or token in the client sideJavaScriptCode orReact App, because anyone can see theJScode in browser isn't ?Also how we can secure the API ? Because I heard that even if
CORSwill not allow other host to call my domain , we can hack it by usingCurland act as the same domain.Check out the video series from Auth0 on authentication. Depending on your use-case (which yours falls into) there are still many choices. Auth is hard and filled with a ton of pitfalls. There are arguments to be made with JWTs, but the tried and true here is to use cookies and ensure that it is http-only, but it’s best to not just let me tell you. It’s better if someone else asks you and you can explain why you made this choice out of many. Those videos are short and very understandable.
Thanks for sharing ☺️
Thanks, Curious If
Auth0filled with a ton of pitfalls then why should i check the videos ?Even with Auth0, you have many choices — like JWT or cookie-based sessions. Auth0 provides many “strategies”, but it’s best to know which works best with the right trade-offs. Like, do you understand why JWTs may be insecure? Did you know that if you have a separate client and API both served from the same domain makes the headaches of having an auth server almost moot? These are good things to know when making an auth choice that underpins access to your systems. The wrong choice is hard to find time to re-do when you’ve already got live users
I use cookies for authenticating the users.
You are 100% correct that it is not safe to use API keys in the browser.
Usually, if you want to use API keys, they must be issues every session and can last only for a few minutes.
Once you implement cookies or any system for authenticating the users, you don't need to be afraid of a 3rd-party calling your service.
Nice 😄, If possible , can your share a post on how you used cookies based implementation in high level using this stack, like frond end and back-end stack used and how you made request to the back-end
APIfrom front end using cookies ? Like were the cookies was generated in client side or server side and how it was used to authenticate theAPIetc.I will do my best!
I just us AWS Cognito with AWS API Gateway
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#?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.
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
I really, really agree with pretty much everything you wrote. I think you should definitely try NestJS, to bring a bit of convention into the mostly-unopinionated world of JS. Also agree with going Kubernetes, IMHO it's a great -if not the best- way to avoid vendor lock-in, which is something people should always keep in mind, given what history has taught us about cloud service providers' unexpected pricing shifts.
I did look at NestJS once but it felt overwhelming. Maybe I should give it another look now.
K8S is just perfect. People are so afraid of it but once you pass this, it's heaven.
I try to follow the community voice as a rule of thumb. Of course, there are exceptions for everything.
Can you break my stack Ido? I want to see what didi can't handle. Consider it an underdog challenge.
Not sure I understand. Please elaborate :)
Sorry I'm developing didi.land and I didn't want to plug this but I guess I have. It's a new way of working with the front end. I'm looking for adventures developers who might want to try it and report issues and break it.
I will take a look 🙌
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.
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
Using this stack how do you authentication and authorization of users, like using
Google, Githubetc ? Do you do it in server side usingNode?I'm using a cookies based solution with my own implementation.
It's pretty simple to implement. If you don't want to make this effort you can just use Firebase Auth.
I am building an app with almost the exact same stack, but with hasura instead of nodejs
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
Nice 😄, So in conclusion don't jump from here to there by looking at new shiny stack in the town. But instead Get your Job done using the battle tested tools in hand.
Yap, this is about it!
What do you think about callbag and redux-saga for side effect handling?
I don't have experience with those, unfortunately.
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?