I would use the built-in HTTPs libraries in either Node.js or Deno. Maybe with Express.js or Fastify if I think I need them, but for simple CRUD I think those layers are usually unnecessary until you have many endpoints. Usually it's not a big leap to migrate to those since they also use the built-in request and response objects. The language really doesn't matter, though. If it were Ruby or Python then I'd choose their respective HTTP modules in the standard lib. Receive JSON, respond with JSON. Done.
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.