In that case, I recommend Flask [1] + SQLite [2] (you can swap out SQLite for Postgres if you start hitting scaling issues). Flask is a very cleanly-designed Python-based web framework that makes it simple to get started, yet is quite powerful. SQLite3 is a whole database in only a single file, which makes deployment and backups very easy.
[1] https://flask.palletsprojects.com/en/2.1.x/tutorial/
[2] https://flask.palletsprojects.com/en/2.1.x/patterns/sqlite3/
The way it's been explained to me, Rails packages (gems) are like prefab bathrooms and kitchens. Compared to e.g., Node.js packages which provide things like "sink" and "tap" and "door handle."
E.g., in Rails there's a popular auth package that includes password reset and recovery functionality:
https://github.com/heartcombo/devise
Always a pain to build, and not something these popular Node.js packages save you from doing over and over again:
EDIT: It sounds like I'm picking on those packages. I don't mean to, just want to highlight the difference in philosophy between the Node.js and Rails approaches.
These instructions from me are a few years old but cover the basics: https://www.mooreds.com/wordpress/archives/2971
- SaaS/no code/low code tools: Retool, Bubble, PowerBI
- Big MVC frameworks: Ruby on Rails, Django, .NET Core, Spring.
- A few tools together: Next with Prisma and SQLite, Node/Deno with SQLite/CouchDB, Flask + SQLite, Flask, Javalin + Kotlin + Exposed, FastAPI, PHP.
- The usual "use what you already know".
This pattern happens all the time when people are asking how to build web products, especially "easy and well understood" ones like simple CRUD apps. The other interesting part is that no one seems to have "hard evidence" or something like that to argue their recommendations. I wonder if it's due to a lack of hard data, or that tools don't make a huge difference, or another factor.
Just this week-end, a friend had an idea that he wanted to make a list of healthy products. I suggested Google Sheets as a starting 'database' and see where we move from there. He had some issues with inserting images to it though so I just created a sanity.io project. I think we were good to go in about 20 minutes with both a backend admin area and an API.
The next steps are to:
A - Build mobile app
B - Actually move the data from Sanity to a self hosted CDN
--
[1] I don't work for Sanity, but I'm also not a stranger to them.
Outside of that I’ve been having a lot of side project success with Chakra UI pro on the front end and Hasura on the backend
Other people just use spreadsheets for this type of stuff, depending on the application.
But I will say Flutter Web is rather ugly compared to React... React has had UI libraries for years which are way beyond anything flutter can do
You could just talk directly to the DB using the basic Node SQLite packages/libraries but I found using an ORM like Prisma greatly reduces boilerplate and makes things more robust.
TechStack: Backend : .Net Core Frontend : React, AntDesign
connect me email available in profile
If I suspect it's going to be bigger I have been sticking to Spring Boot + Kotlin which has been very productive but it has a lot of magic going on that it sounds like you were trying to avoid.
Subscribe for early access, and i can give you a demo.
Also, have contact info in my HN profile.
For storage, SQLite is almost certainly the way to go by default IMO. People underestimate the capabilities of SQLite. Chances are it not only does most if not everything you want in a performant way, but it also scales very well. I might also go with CouchDB if I feel like it fits, and because I just find so much to like about it.
If I need webpages to be rendered, I'd use the Svelte compiler on the backend to SSR the components into HTML. Doing it from scratch requires a bit of work but not overly-so; I've done it 3 or 4 times with my own personal projects. That way you can not only render HTML in a very straight-forward way but you can easily rehydrate on the frontend if you need component behavior to run in the browser.
The end result of this is that you have few to no dependencies other than the language runtime and you understand the app in and out. I've been downvoted in the past for suggesting this approach, but I stand by it. No, you don't need a framework unless a framework is called for. I prefer to start with the minimum to get the job done and then work up from there. This way I can do what I want and not run into a situation where some other developer's nebulous definition of what makes something "middleware" get in the way. Separating business logic from "plumbing" logic helps when it becomes necessary to transition to a(nother) framework.
Rails is great and all that, and I started my current career in Rails, but in many cases these frameworks are just too much. Even the scaled down ones like Flask, Sinatra, and Express.js can be more than is necessary. An understanding of web security is kind of a requirement, and it takes more work to do things like CSRF tokens (as an example), but in my opinion it's worth it to know those things intimately earlier than to rely solely on prebuilt libraries without understanding what they're doing for you.
Of course there are exceptions. Don't re-implement cryptographic routines from scratch because why and also because you will screw them up. If I can screw up CRC8 then you can screw up BCrypt.
Not sexy, but can produce what you want.
Or just PHP?