fzeindl

Thank you for you kind words. Let me know if you could use my system.

I haven't mentioned documentation yet, but this is certainly something important that I might include in a future revision.

I agree. I have written a blog article about this: https://fabianzeindl.com/posts/the-codequality-pyramid#testa...

This works for technology or products as well. The first thing I do when evaluating a framework is googling the phrase "technologyXY is terrible" and see what comes up.

- Next.js frontend/backend, edgedb on top of postgresql, Linode server behind cloudflare. No Kubernetes.

Or, if you want to be more classical:

- kotlin backend using dropwizard, jdbi ORM connecting to postgresql. No kubernetes.

Or, if you want "plug and play" as backend:

- next.js, supported by postgREST. No kubernetes.

Or, if you want something exotic:

- elixir/erlang/phoenix as frontend and backend, no kubernetes.

I think the future is probably

- some frontend, edgedb, no kubernetes

Slightly off-topic, but a great way of modifying ChatGPT-prompts is by letting it answer as a different age: https://fabianzeindl.com/posts/chatgpt-simulating-agegroups

Take 16gb at all costs. The time will come when you have to run some weird software stack in a VM taking up 4G. Additionally your IDE clocking in at 1-2GB and suddenly you find yourself at the limits. Saving here is not worth it.

> You will never switch databases, so abstracting away the DB for some hypothetical "I might want to switch DBs one day!" scenario is absurd.

You actually might switch databases at some point, but in my experience this always included overriding some of the ORM-queries with custom ones that the particular RDBMS needed for some reason.

So you have to write SQL after all when switching, might as well do it from the beginning.