DEV Community

Cover image for What would your tech stack of choice be for a new web dev project?
Ben Halpern
Ben Halpern

Posted on

What would your tech stack of choice be for a new web dev project?

Let's say you are hired to create a web app for a company that describes itself as "Etsy for dogs" (whatever that means).

You'll be the only developer on the project for a while so you get to make all your own choices, but if the project succeeds, it will need to live on indefinitely.

What is your tech stack of choice?

Top comments (131)

Collapse
 
briandoesdev profile image
Brian Heidrich

Frontend: Svelte + Tailwind
Backend/Auth: NHost (Hasura/Postgres)

Collapse
 
giokhar profile image
Giorgi Kharshiladze

TailwindCSS + Next JS (with Typescript) + Prisma (with Postresql) - very simple setup, easy to deploy, nice dev experience. You could go with custom node js server alongside with nextjs if you want to, but for the most small/mid size projects NextJS builtin API routes feature should be good enough.

Collapse
 
_firelinks profile image
Mike Dabydeen

I have been using the same with Supabase (PostgreSQL). Easiest stack to work with and reason about

Collapse
 
ochsec profile image
Chris Ochsenreither

Database: DynamoDB
API: AWS Gateway API w/ Lambdas (any language)
Auth: AWS IAM
Frontend: NextJS on Vercel
CSS: Ask my web designer

All of this will scale automatically, requires no dedicated servers and is served from edge locations.

Collapse
 
devfranpr profile image
DevFranPR

Love the "Ask my web designer" part :')

Collapse
 
menottiricardo profile image
menottiRicardo

Can you give a little more detail on the Api? I've wanted to try that combo but I'm not sure about the cold start

Collapse
 
ochsec profile image
Chris Ochsenreither • Edited

Cold starts can be long for interpreted languages like Python, Node.js and Ruby. Here's a comparison of 20 lambda executions from cold start where a user is created:

Create User

Payload:

{
    "email_address": "jonathon.doe@hotmail.com",
    "first_name": "Jonathon",
    "last_name": "Doe",
    "password": "vaFR6z2D8xstaao4EyvP"
}
Enter fullscreen mode Exit fullscreen mode
Metric Duration (ms) Duration (ms) Memory Used (MB) Memory Used (MB)
Trial Node.js 14.x Python 3.7 Node.js 14.x Python 3.7
1 753 203 80 69
2 408 17 82 69
3 9 35 82 69
4 39 30 82 69
5 22 34 82 69
6 18 28 82 60
7 21 36 82 69
8 8 35 82 69
9 28 43 82 69
10 10 31 82 70
11 9 21 82 70
12 7 38 82 70
13 23 36 82 70
14 8 33 82 70
15 8 21 82 70
16 17 43 82 70
17 22 27 82 70
18 22 43 82 70
19 8 68 82 70
20 8 12 82 70
Sum 148 834 1638 1391
Average 72.4 41.7 81.9 70
Median 17.5 34.5 82 70
Thread Thread
 
menottiricardo profile image
menottiRicardo

thanks a lot for that info, are you using Express or Nest for Nodejs?

Thread Thread
 
ochsec profile image
Chris Ochsenreither • Edited

I'm not using a framework for these functions. API Gateway provides the url REST endpoints and those endpoints are linked to event handler functions. The functions are stand-alone and just import the packages required within the function.

Collapse
 
bobbyiliev profile image
Bobby Iliev

The TALL stack ๐Ÿ™Œ

Collapse
 
tnylea profile image
Tony Lea

I second that! It's essentially the Rails/Hotwire version for PHP, Larave/Livewire. In fact Livewire was created before Hotwire.

The TALL stack makes building reactive apps so simple and fun ๐Ÿ˜Š

Collapse
 
peerreynders profile image
peerreynders • Edited

FYI: PETAL Stack in Elixir

First, the base foundation of Elixir + Phoenix + LiveView is powerful. It has been the inspiration for other projects like Laravel LiveWire and Rails Hotwire.

2018-09-07

Rails Hotwire was introduced 2020-06-24 as NEW MAGIC.

Meanwhile tallstack.dev was public 4 months before PETAL.

Sometimes chain reactions are just inevitable.

Collapse
 
ben profile image
Ben Halpern

TL;DR?

Collapse
 
bobbyiliev profile image
Bobby Iliev

Tailwind, Alpine.js, Laravel, and Livewire. A full-stack development solution, built by Laravel community members.

Thread Thread
 
posandu profile image
Posandu

Yay finally PHP is becoming a thing

Collapse
 
devfranpr profile image
DevFranPR

Wow I didn't know this was a thing. Now I'm interested.

Collapse
 
djnitehawk profile image
Dฤต ฮฮนฮ“ฮžฮ—ฮ›ฯˆฮš

I wouldn't dream of doing it any other way than following:
Frontend: Svelte
Css: Tailwind
REST Api: FastEndpoints (.Net 6)
Data Access: MongoDB.Entities
Architecture: Vertical Slices with REPR pattern for endpoints.

Collapse
 
wbuckley15 profile image
Warren Buckley • Edited

Huh, I had never heard of Fast Endpoints until recently (Nick Chapsas did a video about it). Need to write a little toy project to try it out.

Collapse
 
watermelol profile image
Watermelol

Frontend: Vuejs + Tailwind
Backend: Django with Restful Framework, MySQL

Collapse
 
danielkun profile image
Daniel Albuschat

Definitely FastAPI (Python) backend and Svelte with TypeScript frontend. Blazingly fast. โšก

Put in PostgreSQL as the DB, which can be SQL, MongoDB and Redis at the same time. It's just so overpowered. ๐Ÿ’ช

Collapse
 
ivan_jrmc profile image
Ivan Jeremic

I'm confused, how is it mongo.

Collapse
 
danielkun profile image
Daniel Albuschat • Edited

Very good question ๐Ÿ˜Š
Postgres has native JSON support and allows you to access json fields (even unlimited nested ones) in SQL statements. This gives you the schemaless flexibility of MongoDB if you for example build a simple table with "key varchar" and "data json" fields. But at the same time you can build very complex queries, write DB-procedures, triggers and all the other goodies of powerful RDBMs.

Collapse
 
webbureaucrat profile image
webbureaucrat

It's not a perfect analogy, but Postgres is object-relational. You can have columns that are typed as objects instead of just regular built-in types, so you can get some of the benefits of object storage without fully committing to the document db model.

Collapse
 
sherrydays profile image
Sherry Day

Tempted to go with Rails/Hotwire. Seems sort of tough to sprinkle in, but if I get to start from scratch I feel like I could be productive committing to that approach.

Collapse
 
dinerdas profile image
Diner Das

I feel similarly.

Collapse
 
isaacdlyman profile image
Isaac Lyman • Edited

My go-to is Vue 3 + Typescript + SCSS on the front end, Node + Express + Postgres on the back end, and Heroku. I can have a webapp up and running in no time at all with this stack. For me it's all about familiarity and speed-to-value. If you're more comfortable with something else, use that.

Collapse
 
hunghvu profile image
Hung Vu

It really depends on what the requirements are. My one-choice-fit-many solution is:

  • Front end: React - TS, Material UI
  • Back end: NestJS - TS, with TypeORM
  • Database: PostgreSQL

Going for an exotic solution will be hard to maintain in the long term (hiring talents, etc.)

For cloud deployment, Google Cloud. As Google Workspace is widely used by organizations, even small one, it will be easier to integrate.

  • Front end + Back end: App Engine or Compute Engine
  • Database: Cloud SQL
  • SSO Auth: Google Cloud Identity (essentially Firebase, but with more compliances)
  • Infrastructure as Code: Terraform

I'm actually writing about the stack above if anyone is interested in. hungvu.tech

Collapse
 
brunoprietog profile image
Bruno Prieto

Rails + Hotwire

Collapse
 
jesterxl profile image
Jesse Warden • Edited

The REGAL stack: ReScript Elm GraphQL Amplify & AppSync, Lambda

UI: Elm + TailwindCSS + Amplify to host + AWS CodeDeploy wired up to repo
API: ReScript + GraphQL + AppSync to host + Lambda to satisfy GraphQL calls

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

If the front end isn't based on web components, your just setting yourself up for trouble

Collapse
 
shaglock profile image
Ilya Shaplyko

Why?

Collapse
 
bennypowers profile image
Benny Powers ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡จ๐Ÿ‡ฆ

Loading performance
Vendor lock in
Future proofing
Incremental adoption
Developer experience

Collapse
 
assadbintahir profile image
Asad Ullah • Edited

Quite an open ended question without telling:

  • Budget
  • Estimated Traffic for the system
  • Product Timelines (time to market etc.)

Tech stack primarily depends on these metrics and when the choice is made without considering these, the end result is:

  • Personal preferences causing increased tech debt
  • Performance issues when system scales
  • If the product is a hit, a mess for the engineers who will be on board in future to deal with technical debt.
Collapse
 
nibelino profile image
Matteo

Depends on the requirements

Collapse
 
guledali profile image
guledali • Edited

Good answer, requirements first and secondly always choose the easiest path and less reinventing the wheel.

For example rather than building your own ecommerce framework and application just use the shopify template and ready-to-use solutions. Focus on actually solving the problem and delivering to your customers is the key.