loading...
Cover image for What's your go-to stack these days?

What's your go-to stack these days?

ben profile image Ben Halpern ・1 min read

Maybe certain projects need a specialty tool in your toolbelt— but for your typical work, if you were to start a new project today, what would you reach for in order to deliver on time and on budget?

Discussion

markdown guide
 
 

probably also worth mentioning, that Rust bindgen will generate ts typings so its perfect for some blazing wasm code if you so wish.

 

Any library recommendations?

I read Actix was good, but now has maintainer problems.

 

It did have maintainer issues in the past, but has a new maintainer. You can also try Rocket which is about on par, but I dont know if its as fast.

 

What's your Rust library/framework set look like?

 

So on the Rust side.

Actix Web although I tried Rocket which was also great, I wanted to use http2 on what is reportedly the fastest web server around. the reason being the stack I am developing is ESModule based so I am trying to move away from a bundler and get as many small requests as I can. the experience feels like 2005 but with Typescript powers, Its liberating!

For the front end, it has to be XState and lit-hml / lit-element. so enjoyable.

The intro to this project can be found here. Rust has been decided after this post was created. I am working hard on a full shop to showdev, its going really well and probably will be done next month.

This sounds really interesting!

This is really cool, I've been chewing at rust for web development, but I'm wondering how/where you can host a rust web server?

I'm likely to spin up a AWS lightsail or something small to install rust. I think that'll do for early days.

Lambda also has a Rust runtime.

🔬 On my list of stuff to tinker with! 🔬

 

Results of StackOverFlow's survey on most loved languages in 2020 might agree with you :)

 

9 out of 10 DEV devs might agree with me haha 😂

 

I am intrigued what you love about that combo?

 

At first it was because I wanted to try all the new hotness, but this is all quite old now so I guess I liked what both languages did for their respective areas. I like rusts no nonsense approach in that it's pretty hard to write bad code and it's pretty hard to write code from a beginners stand point, you really have to keep trying and failing and being repeatedly beaten over the head from the compiler until you end up with idomatic rust. On the other hand we have typescript, this is as flexible as you want, obviously I aspire to write strongly typed strict JavaScript but I tend to get a little lapse in my discipline over on this side, I get that freedom of prototyping speed that I don't in rust and I guess that's a nice pairing, now if I where a 10x I know this combination would lead to some incredibly resilient software.

That's fascinating. What do you mean by "now if I where a 10x I know this..."?

I believe that at the end of the century the use of words and general educated opinion will have altered so much that one will be able to speak of machines thinking without expecting to be contradicted.

Alan Turing

What a quote! Because it's true, I'm a lazy developer, I like my computer to help me to code at every stage. A 10x developer is a joke about the mythical inhuman skills of a developer that is superior to all other developers. I suppose I'm saying, if I weren't the human behind the machine this stack would meet the perfect criteria for excellent software, Microsoft seem to agree with me, for their software is being reengineered in rust, and the invented typescript and this new language which we don't know a lot about yet other than it's likely typescript like but will be used in the same space as rust, zig, d and other c alternatives.

 

I'm a big fan of what folks have dubbed the GoLD stack:

  • Go, the language
  • Lambda, your compute power
  • DynamoDB, a database that scales really well

Who doesn't love a little bit of serverless :D

 

It almost feels like they purposely picked Lambda and DynamoDB for working with Go, just so the stack would sound that well xddd

 

Lol yeah

Step one is always have a kick-ass name! :D

Hahah, I'm currently working on a MERN stack, I'm thinking to switch out React to Vue just so I could be the mighty VENoM dev xddd

 

I don't, I guess ;) We used lambda since quite early days but in almost every case we regretted it in the end. It always turned out that Kubernetes with some application processing (eg. Sidekiq) scales better, performs better and we have better insight into what's going on if something goes wrong.

 

Hahah yes, definitely there are draw backs when it comes to serverless, I think it's all about the project at the end of the day.

Your final point is the most important to me, transparency is actually key for when (not if) something goes wrong :)

 

What's your experience with Dynamo DB? As far as I've heard it it's great for record based transactions, but tricky for aggregate analytics work. (Disclaimer: I've barely even read the docs :p)

 

Dynamo DB is great nowadays....a year ago was the worst thing I could have used ....I've never written so much code for such a small project (extremely high traffic) to handle just throttling strategies. Then one day we turned on "on demand" and never cared for that service ever again

 

I have never used it personally for analytics, but I have heard using it in tandem with Amazon Athena is great for that kind of stuff!

I like DynamoDB a lot, though I have heard it's not great if you have a data set which is growing rapidly.

I have used Athena with an S3 data store. That worked well for that particular job :)

 

This is my current go-to stack:

  • TypeScript
  • React/Next.js
  • Urql/Apollo (GraphQL client)
  • PostgreSQL (Database)
  • Nexus (GraphQL framework)
  • Prisma (Database client)

Full disclosure I'm working on an internal app for Prisma, but it's sooo nice to have VS Code write half of my code for me thanks to type-safety and intellisense. Types defined in the database schema flow all the way to React components on the frontend. 💯💯💯

Wrote an intro to this stack last week :D

 

It really depends what I am doing, but for quick prototyping (which is a common thing I do):

  • VSCode
  • Python/JavaScript
  • NodeJS (if running JS)
  • Firefox (if needed)
 

Generally Laravel on the back end, with React on the front end.

I'd prefer to use Postgres rather than MySQL or MariaDB, but it tends not to be possible because the PHP community is very MySQL-focused. I also tend to use Redis as my cache and queue backend.

 

I have been really interested in getting deeper into Laravel. I heard that it meshes really well with Vue (which I already know) so it intrigued me more. I am also about to learn React. Have you tried using Laravel with both Vue and React and if so, what is your reasoning for your preference being React?

 

The default front-end toolset for Laravel uses Vue, so it's quicker to get working with Vue in Laravel than any other front end framework.

I have tried Vue a couple of times, and the issues I have with it are as follows:

  • Vue has a lot of special syntax for templating, while React is basically just Javascript and HTML with a handful of minor changes to attribute names so they don't conflict with Javascript reserved words, making it easier to remember
  • I've always had a strong affinity for Javascript, and React embraces the functional nature of Javascript to a much greater extent than Vue, particularly since the advent of the hooks API. A component is effectively just a Javascript function that returns HTML.
  • React is conceptually simpler. There's no two-way binding - instead you just pass props down from one component to another (or using context to share data with multiple components within a tree), making it fairly straightforward to understand what's going on
  • It feels more natural to make your components more granular in React than in Vue, and thus they are potentially easier to maintain
  • Vue feels less philosophically consistent than React to me. As noted above, React has an emphasis on functional programming, as opposed to OOP, and sticks pretty rigorously to it (they notably removed mixins because they caused certain problems, and encouraged the use of higher order components in their stead), while Vue is more forgiving.

I will concede that React is harder for front-end developers who don't necessarily know Javascript all that well to pick up, though.

Wow, awesome reply. Thank you for taking the time to respond :)

 

I just want to add that Laravel comes with its webpack-based build tool: laravel.com/docs/7.x/mix

The default installation is configured for Vue, but you can change it to React easily: laravel.com/docs/7.x/frontend#usin...

As it's really just webpack, you can even use Svelte with relatively simple setup. Basically you can bring any major UI/frontend stack that you are most comfortable with to use with Laravel.

Mix can also be used outside the context of Laravel. I use it on a legacy Zend 1 project I maintain where I've been using React for new front-end work.

The only thing that required more work is versioning - I had to roll my own solution for that.

 

Laravel and Vue are awesome, plus both come with some of the best docs around.. So it's a win-win if you need to look-up smth ;)

Very true, the Vue documentation is really thorough and I have noticed the same with my experience with Laravel so far :) Always a huge plus when getting into something new!

 

If the application is very frontend focused with a simple backend model I would go with Serverless technologies first, as it would dramatically speed up time to market:

  • React or Svelte with
  • AWS amplify or
  • Firebase

If I need to build something with a complex backend I would go with a Typescript Node backend and pull out other technologies like Rust or F# for things that need more perf.

 

ReasonReact is covering all my frontend needs.
For backend I'm running Go and slowly transitioning to Rust.

 

Google Docs, Markdown, and VSCode.

(sorry, I'm a blogger by trade 🙃)

 

Over engineering something isn't something to brag about, your stack is perfect for blogging.

 
 

If I were aiming to deliver a project on time, I'd choose what I know: Ruby + Rails + Postgres + Vanilla JS (I don't know much about Front-end development >.<).

If I was wanting to try something new then it would be: Elixir + Phoenix + Go + Postgres/Mongo + VueJS.

 

Python, FastAPI, Typescript, React, and PostgreSQL

Something like this: github.com/Buuntu/fastapi-react

 

thanks , I was looking to use fastapi for my new project . You assemble all what I need in one place.

 

I'm pretty-well bought into Kotlin at this point across the whole stack. I love using Ktor for server-side apps, I'm primarily an Android dev where Kotlin has its greatest usage right now, and the fact that I can write Kotlin instead of JS just makes me giddy. Especially using this all together with MPP, sharing data models and logic is just wonderful and such a pleasant development experience.

 

I'm in the midst of learning Kotlin. I introduced it at work, and it's pretty much just a way for me to get some functional programming in our Java 6 EE-targeted application.

Do you have (or know of) any open-source examples with Kotlin across the whole stack? My "learning" part is writing an application which, for now, uses Angular on the front end.

And, for data access, do you use Exposed, Hibernate/JPA, roll your own, or something else?

 
 

React for the front-end, with Typescript. I can't say I have a go to technology for the back-end. But Java Spring Boot was fun, Loopback 4 was okay. I'll probably choose a Node.js base technology for the back.

VsCode for the editor, Chrome for the browser. And these days it's mostly RATM for the music.

 

try Strapi (for nodejs)... I used Spring Boot for a time, but I think java is so bored. Loopback 4 have a good model also, but Strapi has a visual model editor... and, when you change some model, all rest api and graphql api are updated automatically.

 

true, strapi is helping a lot with front-end focused developer like me 😊 cut down development time quite significantly

 

Python with django if its a large monolith app.

Go or Node for all other project and apps.

Vue on the frontend in almost all cases (unless its just static html, but even than vue can be embedded easily if something a little more exotic is required).

I make us of the entire jetbrains suite of dev tools (big fan).

 

For the work I'm getting paid to do, from bottom to top:

  • Microchip firmware (MPLab X),
  • VxWorks (Wind River)
  • ASP.Net MVC
  • Signal R
  • Vue

Our products are heavily regulated hardware, and supported for the foreseeable. There isn't really a "quickly knock up a prototype in docker" situation.

If I could chose, I would switch out the Microsoft stack for Django on Linux, as I find that easier to work with, but it's not too bad.

 

My go-to stack is to not have a go-to stack, but choose the the tools fitting the job. Of course, choices are somehow limited. Trying to write it down:

  • For mostly-CRUD but dynamic web app: Rails + Vue + PostgreSQL
  • For general-purpose dynamic web app: Phoenix + Vue + PostgreSQL
  • For mostly static thingy probably Gridsome + API with something lightweight, such as Hanami::API maybe. Or better, my own API framework built on top of dry-rb and Hanami
 
 

I've put the following in categories in ranked order for what's most familiar, safe, and known to me down to what I'd like to use and learn and isn't "just hype" to me.

Front-end Web:

  1. JS, jQuery, & Sass
  2. TS, React
  3. Svelte

App:

  1. native
  2. React Native

Backend Service (My current "shop" is very Java-heavy):

  1. Java+Spring
  2. Scala+Play
  3. Go

Event-handling:

  1. Python
  2. Go

DB:

  1. DynamoDB
  2. RDS (only if I have to)

So putting it all together, my most likely, realistic stack I'd build today would be:

  • Front end: React & React Native
  • Service: Java & Scala (for tight deadline) or Go (if I could learn on the job)
  • DB: DynamoDB

As far as other tools, theres are "givens" for me: git, JetBrains IDEs, VS Code, AWS (Fargate, S3, SNS, SQS, Athena, Data Lake, etc.)

 

We're a two person shop developing mobile products with the goal of doing big things on a small budget. Ideally we get where we're going without the need to raise capital too early.

With this in mind we choose open source, community driven tools that provide high developer leverage.

  • apps
    • React Native via Expo written in Typescript
  • backend data
    • postgrSQL database + Hasura GraphQL.
  • backend business logic
    • Node + Express
  • hosting
    • Heroku with the move to AWS when a project gains traction.
 

Python with FastAPI for the backend, PostgreSQL as a database. For frontend I'd go with Next.js or Nuxt.js to leverage the out of the box SSR functionalities.

Glue all together with Docker Compose adding logging, analytics, a CI/CD environment, and you have a working environment for many small to medium scenarios.

 

Hello is fastapi production ready? I take a look and I love it.
I use Django but it miss lot of stuff like pagination.

 

FastAPI is quite battle-tested judging from its website, but is a very lightweight framework compared to Django. You'll have to implement much of the utilities by yourself.

 

I've been super into:

  • ASP.Net Core
  • React
  • Cosmos DB (Azure's DocumentDB)
  • Azure App Service Hosting/Scaling
  • SignalR for realtime work
  • Azure Storage

Everything Azure just works perfectly, and I appreciate I get over $150.00 per month for personal projects to learn all this cool stuff 😎

 

Something I'm still figuring out an acronym for, but let's go with something broad: RNS (React Native Serverless). Quick, flexible, scalable, without dev team fragmenting, minimizing vendor lock-in as much as possible/convenient, and in line with my aversion to needlessly complicating things.

By React Native, I mean as a unified codebase for mobile, web, and desktop (the latter two thanks to React Native Web and the last thanks to Electron at least until there's a viable out of tree RN solution for Linux). By serverless I mean multi-cloud FaaS, DBaaS, and usually Firebase Auth.

 

Right now it is pretty much a .NET Core back end with a Vue frontend.

Though I did just start a personal project that uses Node on the back end and Vue on the frontend. Mostly because I wanted to get better at Node.

I do plan on taking a look at other backend solutions soon. Just to get some more ideas, but right now I really love .NET Core.

 

For serverless things, websites, prototypes, web apps, time sensitive stuff:

  • Next.js (react)
  • typescript
  • jest
  • tachyons (sometimes tailwind if I have a tougher design)
  • faunadb
  • jest

For web apps, monoliths, things that need extensive databases and models, more security and control, or apps I won't be maintaining often:

  • Ruby
  • Roda
  • Sequel ORM
  • tachyons still
  • stimulus or vanilla or preact depending upon frontend complexity
  • MiniTest
  • Postgres

API Only:

  • Ruby / Roda (if I'm working with sql databases)
  • Node + typescript (if I'm working with NoSql ie Fauna or Mongo)
  • Go (still not super comfortable with it but getting there to replace node and typescript)

In general I'm most comfortable with Javascript, however the build processes and configuration issues can be a nightmare. Working with sequel based databases with Ruby is leaps and bounds ahead of Javascript so I stick to that but have moved away from rails in favor of Roda and the Sequel ORM these days.

I enjoy the security of typescript especially when working with lots of external data sources. It can make your head spin trying to remember the data structures of a headless CMS, plus a database, plus a myriad of other services so typescript helps there. However, I find that typescript / javascript apps are best if you are working on them every day. If you build something then come back a few months later you may spend the next day debugging the build (babel, webpack, typescript...), the ecosystem in JS is really what gets me down.

Recently I'm getting more into Go for back end work for first class types support and a nice simple language with amazing speed. That being said the front end tooling and templating stuff that Go offers is a little lackluster so if working on a monolith I'd say Go may not be the best pick and is more of an amazing API language.

 

In Android I'd go with writing the app in Kotlin, using Dagger Hilt for Dependency Injection and using Jetpack + Material Components for building the UI.

For cross-platform CLI stuff, Rust and its huge crate ecosystem is my new love.

 

Lately, backend has been go+fiber with mongodb or mariadb & react on the front end.

I am a lot happier with go vs node vs python.

On my list of things to tinker with are nextjs and rust on the backend.

 

Almost for any project I've been using Quasar Framework for frontend development (apps, websites, etc).

For hosting and authentication usually I'll go with Firebase.

If I need a more intense backend, I start with Mojolicious. For database, it depends on the usecase... Or PostgreSQL or SQLite.

If I need a server, usually go with a Ubuntu VPS on DigitalOcean with the latest LTS version.

 

In regards to web development, although I work with ASP.NET MVC at my daytime job, if it was a personal project or freelancing stuff, I would go with Node, MySQL, Express and EJS pages. I work quite fast with it and fits me like a glove.

 

Rails/Minitest/Postgres/Redis/StimulusJS/TailwindCSS/Heroku.

 

Gridsome or Nuxt, Apollo for bigger apps with complex GQL APIs.

I usually prefer to remain Serverless with lambdas but if I'm handling a back end as well, it'll definitely be node until Deno is production ready. MySQL for my DB needs.

 

Sapper/Svelte for front end and "micro back end"! Otherwise it's a lot of Nuxt and Express for larger projects, since Sapper is still very much in beta still. But Sapper is SO much more productive for me than Nuxt, which is even more productive for me than React...

For CMS and/or data storage, I've either been using Airtable or Fauna for small projects

 

May be a little dated but still quite reliable:
Node+Express with TypeScript, process managed by PM2 in cluster mode.
PostgresSQL
VueJS for the frontend

Can always look to the future to have the node parts switched out for Deno.

 

Golang for APIs, utility scripts and command line tools.

Symfony for more "monolith" projects. (also Interested in Nest.js on this category).

Frontend: Vue/Nuxt/Tailwind.

Static sites / landing pages: Gridsome/Hugo.

Datasores: Postgres, FaunaDB.

Cache: Redis

CI: Github Actions / Giltab

Hosting & Infrastructure: DigitalOcean, Google Cloud Run and Netlify.

Domains / DNS: Namechep and Cloudflare.

Cloud Storage: Google cloud Storage.

Headless CMS: Strapi or Directus

I think I can build almost anything with this ;)

 

For small and quick setups, POCs I use

  • NodeJS + Express (backend)
  • RxJS + vanilla JS (frontend)
  • Parcel

Sometimes I throw in Typescript as well when I have good planning in advance. 😅
I started it out as an one time thing, but immediately fell in love with the simplicity and elegance with which you can do things in RxJS.
Been thinking of giving RxJS a try on the backend also.

 

I GROK websites

GraphQL
React
Okta (ok, so I needed auth and wanted to make the acronym work)
Kotlin (with Spring)

I didn't include any databases in the acronym, as I kinda treat them like managed services now anyway.

I created a basic skeleton on github, but I actually named it "KROG" because I didn't see "GROK" at the time :P

 

git for content, postgrest for api/db, sinuous for html/signaling/frontend, immer for immutability on frontend, goober for css primitives, esbuild for stinking fast builds, typescript to think, firebase for easy cloud stuff without think like good auth, users, and file storage.

 

Recently, I've found myself using a couple of Google Cloud Functions to complement the actual backend. For small and simple projects I usually stick to Node. For greater projects, however, I prefer Go.

In the frontend, I use React for web apps and Svelte or Sapper for websites.

 

My extremely original setup 🙄

  • React on the frontend, usually with a custom Webpack config (might move to Parcel)
  • Sass for styling
  • Node (Express) on the backend
  • PostgreSQL or MongoDB for storing data when necessary
 

Nostly next.js , handles both backend and frontend code.
Knex.js for Query building and postgres for DB.

That’s the base stack right now.

Once I’m done with test cases for routex, I’ll start using it for the api’s and knex and react/preact for the frontend side of things.

 

For econometrics, data analytics:
R with the Rstudio ide
Python with jupyterlab

For Web services:
Vscode
Nodejs / express / mongo (just baby steps)
Django ( i am not even born yet)
No frontend framework yet. 😔

 

Personal projects Rust/Postgres/RabbitMq
Work Lambdas in .net core, SQS and Aurora serverless

 

Im really jamming this stack right now, Vue , Netlify (for serverless functions & hosting) firebase (for DB & Auth).

pun intended

 

My to-go tools:

  • React
  • .net core web API
  • mongodb
  • SQL server db
 

dotnet core + Vue with TypeScript.

 

Node js + Typescript + Prisma + React + GraphQL

 

Python/Flask for the backend, plain ol' HTML (with progressive enhancement only) for the frontend. Scaling horizontally like it's 1999.

 

Asp.net Core with Razor pages and ms sql database. Some libraries to deal with Excel files.

 

For simple JAM stack projects:
Gatsby + Netlify (hosting, identity, functions) + Airtable.

For light-weight full-stack projects:
MEAN (MongoDB + Express + Angular + Node) stack.

For more robust full-stack projects/microservices:
Angular + SpringBoot + Relational DB (MySQL / PostgreSQL) + Docker.

 

Python Monolith (Preferred): Django + VueJS (NuxtJS)
Python Microservice: Flask / FastAPI + VueJS (NuxtJS) + Kubernetes

 

Where is the love for Angular :(

I usually use: Angular for front + Node or Go for back.

 

Everyone runs for the newest thing as soon as it hits the shelf.