Ask HN: Is my software stack choice sound?

For new projects, both at work or on the side, I like to imagine I have a “new stuff budget.” That forces me to spend it wisely.

If I over-spend my new stuff budget, I take on debt, much like tech debt, that I’ll have to pay down later. I’ll make slower progress because I’m trying to learn too many things at once, and I’ll have to go back and fix suboptimal tradeoffs where I didn’t have enough experience to make the right tradeoff at the time.

Conversely, if I don’t spend the new stuff budget at all, then I won’t learn anything new and might miss out on a tool that would have made the problem easier.

For side projects where the whole point is learning, sometimes I’ll spend my new stuff budget by e.g. learning a new frontend framework first, writing the backend in something I know. Then once I’m familiar with everything and have built back up the new stuff budget, I’ll go back and reimplement the backend in the new language I wanted to use, leaving the rest of the stack unchanged.

I don't know anything about mobile development and not a lot about frontend.

I'd do the backend with Django and Postgresql. You can't go wrong with Postgresql, it's an industrial strength database. Nothing wrong with MariaDB (or Mysql for that matter), either, I just prefer Postgres.

Writing your backend in Django will allow you to get the basic functionality working in an afternoon. Don't worry too much about getting all fancy with the user models at least to begin with, or any "clever" stuff. Don't worry about doing it at Google scale until you're half way towards Google traffic.

You can use generic views in Django to rough out a web UI for it, then make it as fancy as you like with Flutter.

GraphQL forms a strongly and deliberately typed interface between a client and server, without frontend and backend teams having to collaborate on the shape of the endpoints (should such and such endpoint gain new options? should it be split into a separate endpoint? should the old one be deprecated, and if so, do clients still rely on it?).

Instead, they need only agree on the shape of the data available, and the frontend queries it however it needs to be queried while the backend resolves the nested calls with no additional effort* from those writing the backend.

Also, some clients come with additional affordances for hard problems, like pagination.

* okay, fine, you have to wrap your data resolution in Dataloaders, but that's not particularly challenging

You can set up design documents that implement access control logic. These are written in JavaScript.

https://docs.couchdb.org/en/3.2.0/ddocs/ddocs.html (note the design document for the users database)

This isn't the right type of solution for all data - but there's a lot of situations where people have a bug lump of data that they're trying to expose... list of all current flights, or classes, or ongoing games.

It can be quite useful for a lot of use cases. One size never fits all.

Give serious thought about using React Native over Flutter: 1) You can use JavaScript/TypeScript instead of learning another bespoke language (Dart). 2) With React Native you have the option of deploying OTA updates, this allows you to deploy fixes and basic updates without going through the app store review process.