Ask HN: What would you use to build a mostly CRUD back end today?
43 comments
For every type of projects I'm involved, I choose Go as the backend and put maximum of business rules there to help me manage changes. Go standard library is sufficient and robust for many (all) cases I faced : http handlers, templates, concurrency...
If a web frontend is needed, I'll take svelte (not svelte kit) to code independente components that talk to the backend. I'll code there only interface logic (no control, no calculation, etc...)
If a web frontend is needed, I'll take svelte (not svelte kit) to code independente components that talk to the backend. I'll code there only interface logic (no control, no calculation, etc...)
I made a few apps in Go with mostly just standard library (I used the Chi router). The first API was fun but I never felt as productive as I did with Django.
If I do a Go project now I usually try to push the team to consider more libraries and frameworks to take care of the repetitive tasks.
If I do a Go project now I usually try to push the team to consider more libraries and frameworks to take care of the repetitive tasks.
It's just that Go and their libraries are never going to be as expressive as something like Python and Django. I really appreciate the language for its simplicity, I love getting a single binary, the ecosystem is nice and it's great to be able to read the stdlib code and code from other libraries easily. However, if I have to be frank, I'm much more productive and have a better time with something like Django.
Either ruby/rails for tried and tested, or crystal/amber if you don't need much from the wider rails ecosystem for some typing goodness.
I work with Rails, and it is still pretty relevant.
I would not recommend Crystal since it's essentially a syntactically Ruby rip-off, riding the performance/concurrency wave, and false-flagging Erlang.
I would not recommend Crystal since it's essentially a syntactically Ruby rip-off, riding the performance/concurrency wave, and false-flagging Erlang.
I hadn't heard of crystal before, looks interesting might give it a try this weekend.
I'm mostly doing that.
Django + Unpoly + Postgres
Development as fast as it can be. :D
https://alexandremjacques.com/django-plus-unpoly/
Django + Unpoly + Postgres
Development as fast as it can be. :D
https://alexandremjacques.com/django-plus-unpoly/
Go for backend. Yes it’s a bit more tedious. But in return you get deadass simple builds and pretty amazing performance. Also tbh it’s not that tedious to write SQL and tests. I’ve almost always run into issues with ORMs when things get complex.
Use Postgres and embedded db for cache. With SSD and Nvme you can leverage the embedded db for crazy performance. These days you can get a lot of storage space. Swap file and 5gb of space for the db as cache and you’re speeding. Save money and the network call, don’t need Redis.
React or svelte for UI. Don’t use next or any of that bloat. Use vite and lazy loading. If you need SSR don’t use SPA tech, maybe sveltekit would be good. I use sveltekit and react mostly.
For anything else like using sdk I use node if it’s not available for Go.
Use Postgres and embedded db for cache. With SSD and Nvme you can leverage the embedded db for crazy performance. These days you can get a lot of storage space. Swap file and 5gb of space for the db as cache and you’re speeding. Save money and the network call, don’t need Redis.
React or svelte for UI. Don’t use next or any of that bloat. Use vite and lazy loading. If you need SSR don’t use SPA tech, maybe sveltekit would be good. I use sveltekit and react mostly.
For anything else like using sdk I use node if it’s not available for Go.
Go has also been my go to choice for backend for many years, but these days I feel it’s almost like malpractice not to use Typescript. The advantages in productivity & code robustness were just too great. With libraries like zod & trpc, Nextjs api routes/RSC, I don’t see how Go can compete for simple CRUD apps or quick prototyping.
I personally very much prefer Typescript as a language to Go; my biggest gripe with it is the ecosystem is far more complex, vast (in the bad way, when you have 1000 options for everything and nothing completely stablished), fast moving and breaking. You have to cope with things like transpilers, etc.
I know this is improving, libraries like React have been #1 for a good while, but even then, they introduce breaking changes constantly.
I know this is improving, libraries like React have been #1 for a good while, but even then, they introduce breaking changes constantly.
Performance. Especially any real time systems or websocket stuff. TS is awesome and I love Zod, but for a little extra effort I get massive performance boost and lower costs.
I have been in love with Loopback.io since v2 even though it was a bit of a rollercoaster.. Loopback v4 is a beautiful library. Its been around longer than nestjs but that's the easiest thing to compare it too. I recently have been creating lb4 servers that interface nextjs and react native clients. Initially, I identify my entities and use cases that I want to build. I then use the lb4 cli to auto generate models, relations, controllers, datasources, interceptors (add logic on methods/classes). I can start testing them with the OpenAPI explorer. With the openapi-typescript-codegen library I can generate services from my lb4 OpenAPI spec that I can use on the client side. From there, you can really query data easily with the loopback filter (which can be used on the client too). I initially started doing this with angular1/2+ but its been pleasant using many clients. Even though I have been leveraging it for years in production, I am still learning and exploring. There are many other awesome things I can expand on or explain if you are interested!
https://loopback.io/doc/en/lb4/
https://github.com/ferdikoomen/openapi-typescript-codegen/tr...
https://loopback.io/doc/en/lb4/
https://github.com/ferdikoomen/openapi-typescript-codegen/tr...
- Stack:
- Application FE:
- Next JS (Hosted via Vercel)
- Hasura GraphQL for real-time messaging.
- Supabase for Auth and hosted Database.
- Application BE:
- PostgreSQL via asyncpg (no ORM)
- Uvicorn - hosted on AWS Lightsail.
- Redis - as a message queue.
- Hasura GraphqlQL for real-time messaging.
- Monitoring:
- Axiom https://axiom.co/vercel as it integrates with Vercel.
- Packaging:
- Docker & docker-composeI would pick Ruby on Rails as main framework. It can go a long away, has sane defaults when talking about security and can move fast with building features.
For CRUD is the perfect fit (for me).
For background processing job I would pick Sidekiq or GoodJob
And would add to it a library like Avo - a good admin that will remove for me the need to create my own backoffice dashboard.
If I would have more time to put aside for learning something new I would try Hanami 2: it is Ruby but it comes with a different code architecture for a web app.
For CRUD is the perfect fit (for me).
For background processing job I would pick Sidekiq or GoodJob
And would add to it a library like Avo - a good admin that will remove for me the need to create my own backoffice dashboard.
If I would have more time to put aside for learning something new I would try Hanami 2: it is Ruby but it comes with a different code architecture for a web app.
any tips to setup/deploy goodjob with nginx and passenger?
That doesn't really narrow it down very much. How many different entities, how complex are the filters, how frequent are the reads and writes?
When I was around 14 or something I started teaching myself relational databases with something called Paradox for DOS. For at least 15 years I went along with the assumption that real programmers use a relational database for just about everything.
When the NoSQL trend appeared and became wildly popular, it made me reconsider.
These days, if I can get away with using JSON files, then I just do that.
As far as the stack I usually use Node.js and JavaScript just because I have been doing it that way for so long. Recently some people specifically ask for Python.
Obviously, whether that will work depends on the project.
You often don't have a choice because the database is already built.
For many projects, there are multiple different approaches that would work fine.
I think for the future you will start to see languages that target web assembly becoming more and more popular for portability. Such as Rust and maybe some Rust competitor that has yet to become popular.
There will probably be some kind of popular web assembly runtime soon bundled with Postgres or something.
Or maybe someone will just build a Postgres extension that serves web pages running web assembly that can query Postgres.
When I was around 14 or something I started teaching myself relational databases with something called Paradox for DOS. For at least 15 years I went along with the assumption that real programmers use a relational database for just about everything.
When the NoSQL trend appeared and became wildly popular, it made me reconsider.
These days, if I can get away with using JSON files, then I just do that.
As far as the stack I usually use Node.js and JavaScript just because I have been doing it that way for so long. Recently some people specifically ask for Python.
Obviously, whether that will work depends on the project.
You often don't have a choice because the database is already built.
For many projects, there are multiple different approaches that would work fine.
I think for the future you will start to see languages that target web assembly becoming more and more popular for portability. Such as Rust and maybe some Rust competitor that has yet to become popular.
There will probably be some kind of popular web assembly runtime soon bundled with Postgres or something.
Or maybe someone will just build a Postgres extension that serves web pages running web assembly that can query Postgres.
Node and Express. It’s the most common for new projects at work, and i’ve been using it for over a decade at this point. It’s just so simple and easy and fast to get going.
I love this combo
- Stack:
- Application:
- Flask[0]
- Flask-Admin[1] (maybe for the initial prototype)
- SQLAlchemy --> PostgreSQL
- Gunicorn --> Nginx
- Celery[2] (long-running background jobs)
- Monitoring:
- Sentry[3]
- Analytics:
- PostHog[4]
- Packaging:
- Docker[5] & docker-compose
Now...
Would you do a breakdown/list of all the jobs you've done by sector/vertical and by function/role and by application functionality?
- [0]: https://flask.palletsprojects.com
- [1]: https://flask-admin.readthedocs.io/en/latest
- [2]: https://flask.palletsprojects.com/en/2.3.x/patterns/celery
- [3]: https://sentry.io
- [4]: https://posthog.com
- [5]: https://www.docker.com
I prefer not to go into too many details but most contracting I did was for medium sized companies to digitize some of their internal processes (that were previously running on Excel and email, i.e. people emailing excel files around).
In my experience cost is still a big factor. The budget for these projects is usually rather small because it is viewed solely as a cost and not an enabler. The number of users for these internal APIs is rather low and so it seems quite expensive per head.
In my experience cost is still a big factor. The budget for these projects is usually rather small because it is viewed solely as a cost and not an enabler. The number of users for these internal APIs is rather low and so it seems quite expensive per head.
Parse Server+Dashboard. Setup takes half an hour, including testing whether the DB is connected. Handles accounts. Easily links stuff in a table, e.g. if you have Company connected to a User and a Address, it manages the pointers for you, and it's really easy for FE to just get the details.
If Parse Server dies or implodes for some reason, it's still built on top of MongoDB, so the data still belongs to me and I can switch to something else. I also don't need to worry about horizontal scaling.
Tutorial on it for setting up on Heroku: https://smuzani.medium.com/setting-up-a-mobile-backend-serve...
It's a little old, but the stuff I built on top of Parse Server back then has been scaling up to a thousand users, and now we've just been adding things like pagination and giving heroku more money.
If Parse Server dies or implodes for some reason, it's still built on top of MongoDB, so the data still belongs to me and I can switch to something else. I also don't need to worry about horizontal scaling.
Tutorial on it for setting up on Heroku: https://smuzani.medium.com/setting-up-a-mobile-backend-serve...
It's a little old, but the stuff I built on top of Parse Server back then has been scaling up to a thousand users, and now we've just been adding things like pagination and giving heroku more money.
SST, you can have your backend logic and infrastructure all in Typescript. If you want to use a different runtime for your serverless functions, you can. you can also define your frontend in the same project and deploy the whole thing with one command.
For personal stuff this is great because you can run everything you need for next to nothing. For commercial stuff, it would depend on the use case. If you are going to be handling a bunch of requests or have to do a large amount of processing, you may want to go a different direction, as is the case with all serverless applications.
For personal stuff this is great because you can run everything you need for next to nothing. For commercial stuff, it would depend on the use case. If you are going to be handling a bunch of requests or have to do a large amount of processing, you may want to go a different direction, as is the case with all serverless applications.
Interesting, no one using .net ? Why ?
I think .net is just not as popular on HN. Lots of companies I talk to use .net in their stacks. Have never used it myself however.
There's literally dozens of us! :) I'm using .NET 6 with a React frontend and Linux-based AWS infra. Feels like the best of all the worlds.
I am using it and going to double down on .Net Core with Blazor.
Blazor server or WASM?
Blazor server but with the new .NET 8 release coming up, I am curious as now there will just be Blazor web app and you can choose both in same project.
Java + Spring Boot. Old school server-side rendered templates with Thymeleaf if the site is static, Vuejs frontend instead if something more dynamic is needed.
Alternatively, Flask/Jinja/Vuejs if I'm working in Python.
Alternatively, Flask/Jinja/Vuejs if I'm working in Python.
Spring Boot has given me a lot of frustration over the years (it is the framework I started with) too much magic but after a few years of using different tools and frameworks I find it hard to deny its productivity.
I wonder what things will look like in 10 years. My feeling is there is a lot of room for improvement still.
I wonder what things will look like in 10 years. My feeling is there is a lot of room for improvement still.
I think the experience is better with more well designed languages like Kotlin, which can reduce boilerplate and allow you to focus on the handler and controller logic instead of boilerplate.
Regarding magic... I think it is a matter of pulling away the curtain; once you know how the DI works, it becomes drastically easier to write code with it, since you can predict its behaviour. I have always had trouble when I don't know all the rules of a system.
Regarding magic... I think it is a matter of pulling away the curtain; once you know how the DI works, it becomes drastically easier to write code with it, since you can predict its behaviour. I have always had trouble when I don't know all the rules of a system.
I'm very much loving the next.js / Vercel experience, but I've been using typescript since near when it was released.
Agreed, all the best parts of express js (request/response, middleware, node) made easy and simple
Vanilla PHP with some DB.
Elixir/Phoenix is a great option. Oban for batch processing. Everything runs either in the Elixir VM (BEAM) or on PostgreSQL, no other servers to set up or manage.
Same for personal projects.
Sentry is great for monitoring. Prometheus/Grafana for operational insights. All are easy to integrate with Elixir.
Same for personal projects.
Sentry is great for monitoring. Prometheus/Grafana for operational insights. All are easy to integrate with Elixir.
Django.
- I know Python very well.
- I know Django quite well.
- Django is extremely mature.
- The Django REST Framework is quite mature.
Other stacks I've used: None, because I only started taking this kind of stuff seriously a year ago.
What else I'd recommend: Whatever you're most familiar with.
- I know Python very well.
- I know Django quite well.
- Django is extremely mature.
- The Django REST Framework is quite mature.
Other stacks I've used: None, because I only started taking this kind of stuff seriously a year ago.
What else I'd recommend: Whatever you're most familiar with.
I use mostly Symfony (PHP). Really powerful form component combined with Doctrine ORM makes it super good for fast CRUD development
Also it has ApiPlatform where you can just add new CRUD api using few annotations/attributes
Also it has ApiPlatform where you can just add new CRUD api using few annotations/attributes
If a UI is needed: sveltekit, Prisma, trpc
One app, no need for an API, typesafety baked in at the DB and API layer, client-side interactivity, and server side authentication is easy to work in.
One app, no need for an API, typesafety baked in at the DB and API layer, client-side interactivity, and server side authentication is easy to work in.
Backend only? I'd go with Go and use Gorm.
Fullstack including frontend, jobs, emails, I'd still pick the PHP+Laravel, with Livewire. It's incredibly powerful.
Fullstack including frontend, jobs, emails, I'd still pick the PHP+Laravel, with Livewire. It's incredibly powerful.
Rails, with resque is pretty great.
Elixir/Phoenix/Postgresql
I use C++ and Poco. Works great!
Clojurescript
In my experience a lot of the jobs I get are to build backends that are mostly CRUD operations with a few endpoints that present 'aggregated' or filtered views of that data. Most of these apps will also need some mechanism to do background processing.
What is your preferred stack to build such a backend today? What tools and frameworks do you like and what have you changed your mind on and don't like anymore (after using it)?
Does your choice of tools change depending on if it is a commercial venture or a personal project?
Curious to hear what everyone is using these days.