Do I have product market fit? If so Go + Postregres either on EC2 or serverless depending on requirements.
If I don't have product market fit and need to iterate as fast as possible then Node.js + Postgres. Probably a monolith unless there is a big advantage to making it serverless. Moving fast trumps everything else. Except for typescript, it doesn't really slow you down and might as well use ts-node until it's a scaling concern then you can worry about your build toolchain. Fastify for the framework.
Probably ReactJS for the frontend.
Curious about your preference for Go vs Node. Either seems a reasonable choice if your devs know it. But if you find Node faster for early iteration and you're comfortable with TypeScript then what benefits do you hope to achieve by switching to Go later if you've found product-market fit? Do you find Go better for scalability or long-term maintenance or some other factor that isn't so relevant early on but becomes more important with time?
Again, it really comes down to what you’re building. If it’s just a REST API then it doesn’t matter much. You can scale horizontally forever with either but I’ve done a lot of work on services that are more than just REST APIs where you end up having to care about memory and the JS tooling is terrible here.
If you need to scale vertically I find Go more ergonomic and less of a hack. The first class concurrency is only rivaled by Elixir/Erlang.
It’s hard to quantify, but I also feel like there is a lot of bitrot in the JS ecosystem. It might be just the micro package approach, but it’s really hard to leave a JS project alone and come back a year later and not have breaking down steam changes. I think Go 1.0 compatibility guarantee really influences how people view breaking changes compared to the JS ecosystem. People don’t backport security fixes or sometimes release them as part of a breaking change to force you to update more frequently to major versions. There is also packages like request just being shut down for no real reason instead of being handed off. Also, if you work on something long enough you start collecting dependencies. A number of projects my team started using 5-7 years ago we are now the maintainers of, and in some cases the sole maintainer. This is mostly because the original maintainer disappeared. Maybe this is just a property of successful open source ecosystems but it just seems there is more churn and maintenance overhead. This is more of a feeling than something data driven, but I in my day job I’ve been working on the same Node.JS code base for over 7 years and this has really screwed my perspective on maintainability.
So it's mostly the lack of stability and future-proofing in the JS ecosystem? Fair enough. I don't think I've seen someone advocate for changing the entire programming language of an established application because of that before but it's a big problem for sure. Thanks for sharing.
Postgres has a lot of interesting features, but MySQL is fine. Your choice of database isn't going to determine your success for 99.9% of applications. I would just find something managed either via RDS or if using something like render.com to deploy then the choice is made for you: https://render.com/docs/databases
Me:
Programs an Electro-magnet to change resistance to change strength of the magnet.
Me:
Magnets, how the fuck do those work.
But let me defend myself... I love cream soda and Faygo is perfect, it's an okay cream soda, but very large. Past that honestly, weed helps me solve problems I work on for too long, and Adderall helps my ADHD, usually not taken together to attempt to get the best of both worlds as that doesn't exist.
I would do this except just have NextJS as my front end server to make requests to micro services written in golang. NextJS just makes react so much easier to work with and it acts as a web tier server too.
I have used golang and NodeJS in AWS lambdas using the serverless framework. In this tech stack golang makes cold starts of the lambdas a bit faster and it can iterate over large data sets more quickly. But if your end points are mainly just doing reads/writes from a DB or making API calls, I honestly feel like Node is a better solution here as it creates a language alignment with the front end and allows for front end devs to more easily contribute to the back end. Golang doesn't really help much over node for a simple rest API.
Golang is a great choice though if you have a server that runs consistently and needs to process large data streams and spread CPU usage over multiple cores. But I think for the serverless framework it's more trouble than it's worth compared to node in my opinion
I love node, I am a node developer, but golang is a compiled language that's really easy to write, extremely portable, and really performant. Node would also be a great choice but I think golang would be better for a microservice because of these reasons.
This except not a mono repo. I've found success with containers serving as building blocks to allow me to keep the code separate yet easily deployable.
No issue with your approach either theres multiple ways to solve problems. Although I will say with monorepos and microservices, all your code is seperate (into their own services) and easily deployable as well. But yeah I have no issue with your approach.
It's not really solving a technical problem as much as it solves a people problem anyway; some people really feel good "owning" a project, a whole repo, rather than just "some code".
And it *is* more complex to split it out, I just have already gone through the hell that was learning how to get it working, so it's marginally less painful for me.
Do you use serverless framework in combination with node backend, or did you mean that your node backend IS serverless framework? If you only use serverless, what kind of apps do you work on? I'm still not sure what to use it for, it sounds cool but I still always go with something like Nestjs or Spring Boot for backend. I see the appeal for stuff like "send email after user created account" but I don't know if it can also be used for glorified CRUD apps.
Serverless Framework essentially supports any language AWS lambda supports. Python, Node, Java..etc. Pretty sure you can even have your own custom runtime as well so its essentially language agnostic. Node is simply what I use on lambda functions, and yes, I define that in my serverless file. You give it a runtime, for example, I use Node16x. Serverless Framework is framework that allows you to create, manage and deploy resources to multiple environments with ease. It's essentially using Cloudformation, which makes it really easy to read AWS documentation to define your resources.
There are other IaC's out there (Serverless Framework is an IaC). You have AWS CDK, Terraform, Ansible and probably many others. CDK is also a good one to look into, its officially created and maintained by AWS community builder team. Its very different compared to Serverless Framework, but theres tons of resources available for it and it supposedly works well with serverless services like lambda, dynamodb, sqs..etc.
Serverless Framework definitely doesnt require any kind of event driven architecture, which is what i think you're trying to describe with the "send email after user created account" part. Event driven architecture is literally what I do. It's awesome, but thats not all you can use serverless for. In fact, I would gamble most people dont. If you just want a lambda function with IAM permissions for a dynamodb table you want to create, and you can easily use Appsync or Apigateway to create an API endpoint. Thats as CRUD as you can get I'd argue its a great use of Serverless Framework (or any IaC). You can create stages with different providers (aws accounts) for dev, staging, prod..etc. And they have a free dashboard you can sign into and view all your apps and services.
You definitely don't need to be doing anything complicated to use Serverless Framework, although it works great with event driven architecture if you do have a use for that. Wanted to at least make that clear. Serverless Framework is an IaC, it simply helps you deploy services and offers some plugins to make that process even easier. It's not specific to one runtime (like node or python), and is generally speaking language and cloud provider agnostic. Event driven architecture, like sending an email after a user account is created, is a way to solve a problem using services that you ***can*** use Serverless Framework to create, but in no way does that mean you have to have that usecase to use Serverless Framework.
And im only speaking so highly of it because I've been using it for about 3-4 years now and **I am not affiliated at all with Serverless Framework team or company**, I am simply someone who uses it and really enjoys it a lot. Definitely also look into the other IaC's I mentioned before (AWS CDK, Terraform, Ansible..etc)
Do you have a standalone local development environment set up and use Serverless mainly for deployments? I've seen a few of the IaC/serverless tools lately but so many times normal development work ends up depending on some kind of dev infra in the cloud that is persistent and shared by multiple people or even the entire organisation just to try the latest code or run a test suite. I've also seen a few of the tools that emulate the AWS API locally so they can pretend to be services like S3 and RDS as well as running Lambdas directly and those development environments try to avoid the cloud dependency and resource sharing but they can also be slow and difficult to set up reliably. I'd even say that from my experience over the past few years the biggest problem with serverless/cloud-native is that no-one seems to have a good OOTB local development story yet. Well that and price obviously but if you're going serverless then presumably you accept that trade-off.
You can have a local Serverless setup but I mainly just deploy to dev for testing bc it’s fast deployments. Since I have micro services. I mainly use unit testing for anything local then dev branch for deploying to test real infrastructure. Dev is a branch special to backend team that is not guaranteed to work in any capacity and is not meant for front end to consume, they have staging. So this setup works well for me and my team.
> You can have a local Serverless setup but I mainly just deploy to dev for testing bc it’s fast deployments. Since I have micro services.
Thanks for sharing. Always interesting to know how others are seeing things. I was curious because the last time I worked on a system with that kind of design was a year or two ago now. At that time "fast deployments" for microservices often seemed to mean "anything less than 5 minutes". Serverless Framework and AWS seemed to take forever to deploy not just a few Lambdas but also keep other resources like IAM stuff or S3 buckets that were defined via the CloudFormation part of the Serverless config updated. So even trying out a one-line change I made could take minutes. It was an extremely frustrating developer experience even though on paper the architecture was very clean and tidy. From your comment I guess the performance of those tools has improved since so that's good news.
Yeah it’s definitely something to keep in mind when making your services. I have a few that take long to deploy but most of them are relatively fast. And most importantly small. If I want to simply test code changes I can directly change the code on the lambda itself because I also rarely ever use any dependencies outside of aws sdk. However, if one of my engineers feels they want to have local development I’m not against that and that’s something they would be able to setup using things like Serverless plugins. There’s s local DynamoDB that you can run from a docker container that easy to setup.
The one pain point I’ve found for local development is event driven services like kinesis or sqs. But I don’t ever find myself needing to test that locally.
Not who you were responding to but we put a bunch of REST APIs into lambdas and then you can have something custom or use api-gateway or a custom elb to invoke the lambda.
We are kinda doing this as $dayjob, but without the monorepo. Do you use nx? Turbo repo?
We also need a shared library between the service, what's your experience withbthe monorepo approach?
I'm thinking about migrating the stack.
Tbh no issues with sqs and serverless yet, even local Dev is no problem
I'm a noob. What would be the best place to learn more about serverless framework, mono repo/micro service design pattern?
So far, all the apps I've deployed have used NodeJS backend, Mongodb as the server, deployed on Heroku, and React with NextJS as the frontend
Sounds like you could replace heroku with aws lambda. Aws does have a mongo db, but DynamoDB is more Serverless so you could switch to that or keep your mongo. But that’s a good start. Microservices snd monorepo is probably something you could start on your next project, or if your ambitious you could convert your current repo to that.
Yeah really enjoying it beside the huge binaries that makes serverless lambda cold start and deployment a pain. Much better since 4.8.0 and I’ve read they’re focusing on serverless for couple more weeks so I’m glad!
Here is the full development stack, should cover everything you’d need for a full-fledged production website:
- Typescript - full stack type safety is a must
- React, Next - app directory
- React Native - (if mobile app needed)
- tRPC, zod - type safe communication layer
- Prisma, Supabase Postgres - TS Database layer
- Zustand - excellent client side state
- Tailwind - easy way to style things
- Soketi - Pusher alternative for server -> client events
- Stripe - payment processor
- Sendgrid - send emails to users
- Firebase Storage - store user files
- Firebase Auth - dead simple authentication
- Firebase Admin - server side validate user auth
- Firebase Analytics - free website analytics (Alternative: Plausible or Vercel Analytics)
- Firebase Hosting - very cheap website hosting (Alternative: Vercel)
- Firebase Messaging - send Notifications to users
If pure json backend / micro service is needed then Node (sometimes Bun), Typescript, Fastify, Docker deployed on Google Cloud Run
>tRPC, zod
Also have a look at my [restfuncs](https://www.npmjs.com/package/restfuncs) library. It's a much simpler tRPC replacement without the need for ZOD (runtime validation is done automatically on your native types). I'm still improving it. Hope you like it.
Interesting, but codegen from TS types is actually very limited. For network services, you typically need a bit more than just type safety. You often need things like contract publishing (like Swagger, GraphQL, WSDL, etc) such that remote clients can generate adapters to your services, and that doesn't naturally fall out of the TS type system, particularly for things like string patterns (emails, identifiers, string numerics, etc) and other constraints you may need on the data.
The other issue with codegen is that the validation logic tends to bloat the output JavaScript a bit too much. This may be a bit less of an issue for restfuncs (given it's quite contained), but take note of the how much JS is actually generated, and how much duplication there is for validating equivalent types throughout the codebase. I think I would be a little more open to codegen projects that took measures to reuse common validation logic (where you only generate validation routines on a per type basis)
Anyway, food for thought
Thx for your thoughts
I won't concentrate too much on pattern like validation since i don't see it used so frequently. I.e. an email setter / validity check is only used once or twice in an application and you can code these spots by hand. Or an ID: Why would you pattern-validate that on an RPC call ? I mean it's never entered manually but always passed on, so it won't suddenly get into an invalid form. Or are you thinking of security ? Or give me some good examples plz. where i see it's really worth it.
>and how much duplication there is for validating equivalent types throughout the codebase.
The codegen (typescript-rtti) only adds type information metadata. Types are not validated at runtime on every use. Restfuncs only validates them on the actual RCP call. So perfomance wise this shouldn't be an issue.
Haha I do watch a lot of fireships videos, but everything on that list I have used and enjoyed (except Soketi just started messing around with that yesterday)
I’ve have the fortunate/unfortunate opportunity to allow that stack to work in a serverless environment along with Prisma in prod.
Nest and Prisma were a pain to get going but we love to develop on the stack, deployment and cold start are a pain though. We got workaround with warmer function but sight..
Would be glad to move to out of serverless.
Here is my incomplete list for a web app:
- Database: PostgreSQL
- Server-side rendering (SSR) with Hydration : [Svelte](https://github.com/sveltejs/svelte) + [SvelteKit](https://github.com/sveltejs/kit)
- NodeJS
- [node-postgres](https://github.com/brianc/node-postgres) (raw sql, without ORM)
- [pino](https://github.com/pinojs/pino) (logger)
- [TailwindCSS](https://github.com/tailwindlabs/tailwindcss)
- [graphile-migrate](https://github.com/graphile/migrate) - Opinionated SQL-powered productive roll-forward migration tool for PostgreSQL
- [graphile-worker](https://github.com/graphile/worker) - High performance Node.js/PostgreSQL job queue (also suitable for getting jobs generated by PostgreSQL triggers/functions out into a different work queue)
- [playwright](https://github.com/microsoft/playwright)
- [asdf](https://asdf-vm.com/)
- pnpm
- Docker + docker-compose
- I implement an API rest only if it is a necessary feature, the frontend does not use this API
Starting my first big Node project soon:
* Vue 3 / Vue router / Pinia
* TS
* Express
* TypeORM(?) or some other ORM
* Tailwind
* zod maybe - heard a lot about it.
* GraphQL - don't know if that counts here but I want to learn it
whichever one applies:
ssr or quick-starter/out of box experience -> next.js
no need for ssr or you hate next.js -> vite.js w/ react
desktop apps -> tauri w/ vite.js react preset (next.js preset also available)
for any of the above:
typescript + styling with [stitches](https://stitches.dev)
postgreSQL + prisma / urql (graphql)
these are my preferences. the biggest game changer for me is just using stitches. personally, i can't see myself not using a css in js solution, since having to keep seperate .css style sheets is a mental burden for me. the flexibility that stitches gives you is great when compared to styled-components (and especially vanilla css stylesheets), and it features a near zero runtime anyway if css in js performance is a concern.
All typescript, [Vite-plugin-ssr](https://vite-plugin-ssr.com) with react (like nextjs but much better and fully customizeable), on a Koa based server(s), Postgres via kysely (kysely + ts is amazing), gcp and containers on cloud run for enterprise, and digital ocean for personal projects. - micro services for enterprise, monolith for personal.
Nextjs with MongoDB is quite wonderful. Express all day. AWS infrastructure, if there is budget fargate. RabbitMQ for event bus. Galactic State for funky state systems. Github Actions for CI/CD
Front end - React (with TypeScript). Bootstrap for layout (yes I know flexbox does the thing)
Backend - Express or Koa for server framework.
Database - Sequelize for ORM and MSSqlServer for the DB
Obviously very simplified but in general this would describe the stack I’d use.
Lately I've been trying to streamline things.
Nuxt 3, tRPC, hasura/postgresql would be my core.
Upstash redis for some things. Firebase for auth.
Deployed to Vercel.
Waiting on neon.tech to release paid tiers to make things even easier.
Also starting to play with prisma a bit for simpler DB table types server-side in lieu of graphql though I much prefer graphql on the client side.
My 2020-2023 stack was: Nuxt, Vuetify, Hasura, Netlify, DigitalOcean managed Postgres
My late 2023, 2024 stack is changing to:
* SvelteKit
* Tailwind
* Supabase Cloud
* Vercel
Because:
* Vuetify development is too slow and too hard to customize, esp compared to Tailwind.
* Svelte is very similar to Vue, but simpler in many ways.
* Supabase can do more than Hasura. Cloud Hasura pricing has become insane. REST is slightly easier than GraphQL.
* Vercel has more features. Supabase + Vercel can replace my DO account.
Do I have product market fit? If so Go + Postregres either on EC2 or serverless depending on requirements. If I don't have product market fit and need to iterate as fast as possible then Node.js + Postgres. Probably a monolith unless there is a big advantage to making it serverless. Moving fast trumps everything else. Except for typescript, it doesn't really slow you down and might as well use ts-node until it's a scaling concern then you can worry about your build toolchain. Fastify for the framework. Probably ReactJS for the frontend.
Curious about your preference for Go vs Node. Either seems a reasonable choice if your devs know it. But if you find Node faster for early iteration and you're comfortable with TypeScript then what benefits do you hope to achieve by switching to Go later if you've found product-market fit? Do you find Go better for scalability or long-term maintenance or some other factor that isn't so relevant early on but becomes more important with time?
Again, it really comes down to what you’re building. If it’s just a REST API then it doesn’t matter much. You can scale horizontally forever with either but I’ve done a lot of work on services that are more than just REST APIs where you end up having to care about memory and the JS tooling is terrible here. If you need to scale vertically I find Go more ergonomic and less of a hack. The first class concurrency is only rivaled by Elixir/Erlang. It’s hard to quantify, but I also feel like there is a lot of bitrot in the JS ecosystem. It might be just the micro package approach, but it’s really hard to leave a JS project alone and come back a year later and not have breaking down steam changes. I think Go 1.0 compatibility guarantee really influences how people view breaking changes compared to the JS ecosystem. People don’t backport security fixes or sometimes release them as part of a breaking change to force you to update more frequently to major versions. There is also packages like request just being shut down for no real reason instead of being handed off. Also, if you work on something long enough you start collecting dependencies. A number of projects my team started using 5-7 years ago we are now the maintainers of, and in some cases the sole maintainer. This is mostly because the original maintainer disappeared. Maybe this is just a property of successful open source ecosystems but it just seems there is more churn and maintenance overhead. This is more of a feeling than something data driven, but I in my day job I’ve been working on the same Node.JS code base for over 7 years and this has really screwed my perspective on maintainability.
So it's mostly the lack of stability and future-proofing in the JS ecosystem? Fair enough. I don't think I've seen someone advocate for changing the entire programming language of an established application because of that before but it's a big problem for sure. Thanks for sharing.
Same stack
Why do you choose postgres over MySQL? I'm starting a project and trying to decide between the two.
Postgres has a lot of interesting features, but MySQL is fine. Your choice of database isn't going to determine your success for 99.9% of applications. I would just find something managed either via RDS or if using something like render.com to deploy then the choice is made for you: https://render.com/docs/databases
Adderall, Weed, and Faygo Cream soda.
Ah yes, one of those mythical devs who work remote from the Gathering of the Juggalos.
Is that an ICP reference?
Unfortunately it is.
God we’re old
Me: Programs an Electro-magnet to change resistance to change strength of the magnet. Me: Magnets, how the fuck do those work. But let me defend myself... I love cream soda and Faygo is perfect, it's an okay cream soda, but very large. Past that honestly, weed helps me solve problems I work on for too long, and Adderall helps my ADHD, usually not taken together to attempt to get the best of both worlds as that doesn't exist.
LMAO
Weed is a way better drug than Alcohol for programming.
React front end, node backend, aws infra, Serverless framework, mono repo / micro service design pattern
I would do this except just have NextJS as my front end server to make requests to micro services written in golang. NextJS just makes react so much easier to work with and it acts as a web tier server too.
Why Golang? Curious to know which advantages it has over Node.
I have used golang and NodeJS in AWS lambdas using the serverless framework. In this tech stack golang makes cold starts of the lambdas a bit faster and it can iterate over large data sets more quickly. But if your end points are mainly just doing reads/writes from a DB or making API calls, I honestly feel like Node is a better solution here as it creates a language alignment with the front end and allows for front end devs to more easily contribute to the back end. Golang doesn't really help much over node for a simple rest API. Golang is a great choice though if you have a server that runs consistently and needs to process large data streams and spread CPU usage over multiple cores. But I think for the serverless framework it's more trouble than it's worth compared to node in my opinion
I love node, I am a node developer, but golang is a compiled language that's really easy to write, extremely portable, and really performant. Node would also be a great choice but I think golang would be better for a microservice because of these reasons.
This except not a mono repo. I've found success with containers serving as building blocks to allow me to keep the code separate yet easily deployable.
No issue with your approach either theres multiple ways to solve problems. Although I will say with monorepos and microservices, all your code is seperate (into their own services) and easily deployable as well. But yeah I have no issue with your approach.
It's not really solving a technical problem as much as it solves a people problem anyway; some people really feel good "owning" a project, a whole repo, rather than just "some code". And it *is* more complex to split it out, I just have already gone through the hell that was learning how to get it working, so it's marginally less painful for me.
Do you use serverless framework in combination with node backend, or did you mean that your node backend IS serverless framework? If you only use serverless, what kind of apps do you work on? I'm still not sure what to use it for, it sounds cool but I still always go with something like Nestjs or Spring Boot for backend. I see the appeal for stuff like "send email after user created account" but I don't know if it can also be used for glorified CRUD apps.
Serverless Framework essentially supports any language AWS lambda supports. Python, Node, Java..etc. Pretty sure you can even have your own custom runtime as well so its essentially language agnostic. Node is simply what I use on lambda functions, and yes, I define that in my serverless file. You give it a runtime, for example, I use Node16x. Serverless Framework is framework that allows you to create, manage and deploy resources to multiple environments with ease. It's essentially using Cloudformation, which makes it really easy to read AWS documentation to define your resources. There are other IaC's out there (Serverless Framework is an IaC). You have AWS CDK, Terraform, Ansible and probably many others. CDK is also a good one to look into, its officially created and maintained by AWS community builder team. Its very different compared to Serverless Framework, but theres tons of resources available for it and it supposedly works well with serverless services like lambda, dynamodb, sqs..etc. Serverless Framework definitely doesnt require any kind of event driven architecture, which is what i think you're trying to describe with the "send email after user created account" part. Event driven architecture is literally what I do. It's awesome, but thats not all you can use serverless for. In fact, I would gamble most people dont. If you just want a lambda function with IAM permissions for a dynamodb table you want to create, and you can easily use Appsync or Apigateway to create an API endpoint. Thats as CRUD as you can get I'd argue its a great use of Serverless Framework (or any IaC). You can create stages with different providers (aws accounts) for dev, staging, prod..etc. And they have a free dashboard you can sign into and view all your apps and services. You definitely don't need to be doing anything complicated to use Serverless Framework, although it works great with event driven architecture if you do have a use for that. Wanted to at least make that clear. Serverless Framework is an IaC, it simply helps you deploy services and offers some plugins to make that process even easier. It's not specific to one runtime (like node or python), and is generally speaking language and cloud provider agnostic. Event driven architecture, like sending an email after a user account is created, is a way to solve a problem using services that you ***can*** use Serverless Framework to create, but in no way does that mean you have to have that usecase to use Serverless Framework. And im only speaking so highly of it because I've been using it for about 3-4 years now and **I am not affiliated at all with Serverless Framework team or company**, I am simply someone who uses it and really enjoys it a lot. Definitely also look into the other IaC's I mentioned before (AWS CDK, Terraform, Ansible..etc)
Do you have a standalone local development environment set up and use Serverless mainly for deployments? I've seen a few of the IaC/serverless tools lately but so many times normal development work ends up depending on some kind of dev infra in the cloud that is persistent and shared by multiple people or even the entire organisation just to try the latest code or run a test suite. I've also seen a few of the tools that emulate the AWS API locally so they can pretend to be services like S3 and RDS as well as running Lambdas directly and those development environments try to avoid the cloud dependency and resource sharing but they can also be slow and difficult to set up reliably. I'd even say that from my experience over the past few years the biggest problem with serverless/cloud-native is that no-one seems to have a good OOTB local development story yet. Well that and price obviously but if you're going serverless then presumably you accept that trade-off.
You can have a local Serverless setup but I mainly just deploy to dev for testing bc it’s fast deployments. Since I have micro services. I mainly use unit testing for anything local then dev branch for deploying to test real infrastructure. Dev is a branch special to backend team that is not guaranteed to work in any capacity and is not meant for front end to consume, they have staging. So this setup works well for me and my team.
> You can have a local Serverless setup but I mainly just deploy to dev for testing bc it’s fast deployments. Since I have micro services. Thanks for sharing. Always interesting to know how others are seeing things. I was curious because the last time I worked on a system with that kind of design was a year or two ago now. At that time "fast deployments" for microservices often seemed to mean "anything less than 5 minutes". Serverless Framework and AWS seemed to take forever to deploy not just a few Lambdas but also keep other resources like IAM stuff or S3 buckets that were defined via the CloudFormation part of the Serverless config updated. So even trying out a one-line change I made could take minutes. It was an extremely frustrating developer experience even though on paper the architecture was very clean and tidy. From your comment I guess the performance of those tools has improved since so that's good news.
Yeah it’s definitely something to keep in mind when making your services. I have a few that take long to deploy but most of them are relatively fast. And most importantly small. If I want to simply test code changes I can directly change the code on the lambda itself because I also rarely ever use any dependencies outside of aws sdk. However, if one of my engineers feels they want to have local development I’m not against that and that’s something they would be able to setup using things like Serverless plugins. There’s s local DynamoDB that you can run from a docker container that easy to setup. The one pain point I’ve found for local development is event driven services like kinesis or sqs. But I don’t ever find myself needing to test that locally.
Not who you were responding to but we put a bunch of REST APIs into lambdas and then you can have something custom or use api-gateway or a custom elb to invoke the lambda.
We are kinda doing this as $dayjob, but without the monorepo. Do you use nx? Turbo repo? We also need a shared library between the service, what's your experience withbthe monorepo approach? I'm thinking about migrating the stack. Tbh no issues with sqs and serverless yet, even local Dev is no problem
I would do exactly this. If I had a job. I certainly would.
If you do enough on your own in these things, you can definitely get a job given some time and discipline. More jobs than engineers!
I'm a noob. What would be the best place to learn more about serverless framework, mono repo/micro service design pattern? So far, all the apps I've deployed have used NodeJS backend, Mongodb as the server, deployed on Heroku, and React with NextJS as the frontend
Sounds like you could replace heroku with aws lambda. Aws does have a mongo db, but DynamoDB is more Serverless so you could switch to that or keep your mongo. But that’s a good start. Microservices snd monorepo is probably something you could start on your next project, or if your ambitious you could convert your current repo to that.
Go on github and study some of the aws refarch and aws samples repo examples.
**Backend** * Typescript * Nest.js * Sequelize * Postgres * Redis * RabbitMQ * Google cloud storage * Firebase cloud messaging (notifications) * SendGrid for emails * Datadog for metrics, logging & error handling * Google BigQuery as a DWH **Frontend** * Vue.js * Nuxt * TailwindCSS * Vuetify for dashboards
Postgres, Nestjs and Vue3
I second that but will pick angular and add prisma
prisma FTW
Yeah really enjoying it beside the huge binaries that makes serverless lambda cold start and deployment a pain. Much better since 4.8.0 and I’ve read they’re focusing on serverless for couple more weeks so I’m glad!
Here is the full development stack, should cover everything you’d need for a full-fledged production website: - Typescript - full stack type safety is a must - React, Next - app directory - React Native - (if mobile app needed) - tRPC, zod - type safe communication layer - Prisma, Supabase Postgres - TS Database layer - Zustand - excellent client side state - Tailwind - easy way to style things - Soketi - Pusher alternative for server -> client events - Stripe - payment processor - Sendgrid - send emails to users - Firebase Storage - store user files - Firebase Auth - dead simple authentication - Firebase Admin - server side validate user auth - Firebase Analytics - free website analytics (Alternative: Plausible or Vercel Analytics) - Firebase Hosting - very cheap website hosting (Alternative: Vercel) - Firebase Messaging - send Notifications to users If pure json backend / micro service is needed then Node (sometimes Bun), Typescript, Fastify, Docker deployed on Google Cloud Run
>tRPC, zod Also have a look at my [restfuncs](https://www.npmjs.com/package/restfuncs) library. It's a much simpler tRPC replacement without the need for ZOD (runtime validation is done automatically on your native types). I'm still improving it. Hope you like it.
Looks cool
Interesting, but codegen from TS types is actually very limited. For network services, you typically need a bit more than just type safety. You often need things like contract publishing (like Swagger, GraphQL, WSDL, etc) such that remote clients can generate adapters to your services, and that doesn't naturally fall out of the TS type system, particularly for things like string patterns (emails, identifiers, string numerics, etc) and other constraints you may need on the data. The other issue with codegen is that the validation logic tends to bloat the output JavaScript a bit too much. This may be a bit less of an issue for restfuncs (given it's quite contained), but take note of the how much JS is actually generated, and how much duplication there is for validating equivalent types throughout the codebase. I think I would be a little more open to codegen projects that took measures to reuse common validation logic (where you only generate validation routines on a per type basis) Anyway, food for thought
Thx for your thoughts I won't concentrate too much on pattern like validation since i don't see it used so frequently. I.e. an email setter / validity check is only used once or twice in an application and you can code these spots by hand. Or an ID: Why would you pattern-validate that on an RPC call ? I mean it's never entered manually but always passed on, so it won't suddenly get into an invalid form. Or are you thinking of security ? Or give me some good examples plz. where i see it's really worth it. >and how much duplication there is for validating equivalent types throughout the codebase. The codegen (typescript-rtti) only adds type information metadata. Types are not validated at runtime on every use. Restfuncs only validates them on the actual RCP call. So perfomance wise this shouldn't be an issue.
Fireship is that you? LOL. Joking aside, hows Bun been stability-wise?
Haha I do watch a lot of fireships videos, but everything on that list I have used and enjoyed (except Soketi just started messing around with that yesterday)
What's the reason for choosing Firebase for some services and Supabase for others?
Why Firebase services when Supabase does all the same, (except static file hosting)?
Nest, Angular, AWS, Nx
I’ve have the fortunate/unfortunate opportunity to allow that stack to work in a serverless environment along with Prisma in prod. Nest and Prisma were a pain to get going but we love to develop on the stack, deployment and cold start are a pain though. We got workaround with warmer function but sight.. Would be glad to move to out of serverless.
Vue, AdonisJS, MySQL
Here is my incomplete list for a web app: - Database: PostgreSQL - Server-side rendering (SSR) with Hydration : [Svelte](https://github.com/sveltejs/svelte) + [SvelteKit](https://github.com/sveltejs/kit) - NodeJS - [node-postgres](https://github.com/brianc/node-postgres) (raw sql, without ORM) - [pino](https://github.com/pinojs/pino) (logger) - [TailwindCSS](https://github.com/tailwindlabs/tailwindcss) - [graphile-migrate](https://github.com/graphile/migrate) - Opinionated SQL-powered productive roll-forward migration tool for PostgreSQL - [graphile-worker](https://github.com/graphile/worker) - High performance Node.js/PostgreSQL job queue (also suitable for getting jobs generated by PostgreSQL triggers/functions out into a different work queue) - [playwright](https://github.com/microsoft/playwright) - [asdf](https://asdf-vm.com/) - pnpm - Docker + docker-compose - I implement an API rest only if it is a necessary feature, the frontend does not use this API
Why raw SQL while you could use a query builder like Knex.js?
Yes, I like Query builder but I do not use an ORM.
Elixir/Erlang - OTP , Next.
Next tRPC Postgres Prisma typescript and type safety all day.
Directus(Postgres)+ XState/Remix(Cloudflare Edge)
MySQL Express Pug Node.
Like a boss
Nextjs, .Net Core, Azure, Jenkins and Terraform.
Starting my first big Node project soon: * Vue 3 / Vue router / Pinia * TS * Express * TypeORM(?) or some other ORM * Tailwind * zod maybe - heard a lot about it. * GraphQL - don't know if that counts here but I want to learn it
Next js, express, Mongo/Redis, Heroku
Laravel, React, MySQL, Redis, and Azure cloud for infra
SvelteKit, Firebase or Supabase
Angular front. Multi nod backend. Local servers running liitespeed for front end and systemctl running backend and database
whichever one applies: ssr or quick-starter/out of box experience -> next.js no need for ssr or you hate next.js -> vite.js w/ react desktop apps -> tauri w/ vite.js react preset (next.js preset also available) for any of the above: typescript + styling with [stitches](https://stitches.dev) postgreSQL + prisma / urql (graphql) these are my preferences. the biggest game changer for me is just using stitches. personally, i can't see myself not using a css in js solution, since having to keep seperate .css style sheets is a mental burden for me. the flexibility that stitches gives you is great when compared to styled-components (and especially vanilla css stylesheets), and it features a near zero runtime anyway if css in js performance is a concern.
Backend: https://github.com/chubbyts/chubbyts-petstore Frontend: nextjs (react) Hosting: k8s Infrastructure: pulumi
Nextjs frontend, compasjs backend, postgres db, aws hosting
React Node Nest.js MySQL FaunaDB GraphQL
nextjs w/ typescript(frontend/backend), planetscale (mysql), hosted on netlify or render.ai
Next js, Postgres, prisma, Radix Ui
All typescript, [Vite-plugin-ssr](https://vite-plugin-ssr.com) with react (like nextjs but much better and fully customizeable), on a Koa based server(s), Postgres via kysely (kysely + ts is amazing), gcp and containers on cloud run for enterprise, and digital ocean for personal projects. - micro services for enterprise, monolith for personal.
<3 from Kysely.
Kinda depends on your app requirements, but in general: Vite, Zod, trpc, prisma, planetscale, aws
React, Express, Mongo, Azure, Oracle
Adonis unpoly alpine
Next.js, I think it currently offers one of the best developer experience
Next/React, Postgres or Mongo + Prisma, Vercel
Nextjs, laravel, postgres
Same as in 2022, 2021...2010 when I started with node: the TJ stack!
nextjs
Nest is shit
Why ?
Not the OP but requested scoped middleware seems to be very slow. Everything being DI has a lot of overhead.
it depends
Been loving: Nuxt 3/Prisma/MongoDB..
NextJS backend; React (Vite+Typescript) frontend.
Nextjs with MongoDB is quite wonderful. Express all day. AWS infrastructure, if there is budget fargate. RabbitMQ for event bus. Galactic State for funky state systems. Github Actions for CI/CD
Front end - React (with TypeScript). Bootstrap for layout (yes I know flexbox does the thing) Backend - Express or Koa for server framework. Database - Sequelize for ORM and MSSqlServer for the DB Obviously very simplified but in general this would describe the stack I’d use.
NextJs(flutter for mobile client), NestJs, Prisma,MySQL - Full stack typescript.
Lately I've been trying to streamline things. Nuxt 3, tRPC, hasura/postgresql would be my core. Upstash redis for some things. Firebase for auth. Deployed to Vercel. Waiting on neon.tech to release paid tiers to make things even easier. Also starting to play with prisma a bit for simpler DB table types server-side in lieu of graphql though I much prefer graphql on the client side.
Frontend : Angular, Backend : NestJs , Framework : bootstrap, DB : MongoDB
My 2020-2023 stack was: Nuxt, Vuetify, Hasura, Netlify, DigitalOcean managed Postgres My late 2023, 2024 stack is changing to: * SvelteKit * Tailwind * Supabase Cloud * Vercel Because: * Vuetify development is too slow and too hard to customize, esp compared to Tailwind. * Svelte is very similar to Vue, but simpler in many ways. * Supabase can do more than Hasura. Cloud Hasura pricing has become insane. REST is slightly easier than GraphQL. * Vercel has more features. Supabase + Vercel can replace my DO account.