Thanks for the question Justin, it turned out to be a good reason to spend some time reflecting on and structuring my experiences. In the end it has become a bit of a long read, but I hope its helpful - at least it was to me 😁 .
Hmm. A bit on the fence about FaunaDB t.b.h., I was initially sold on the free-tier which doesn't have the "don't use this for production"-label you will find at e.g. MongoDB Atlas.
My advice is don't pick FaunaDB if you are not planning on learning FQL. It's essential to properly use Fauna for everything but the simplest queries.
I wanted to avoid FQL at all cost (unclear about TypeScript support; spend time learning a vendor-locked piece of tech; still niche platform; lack of rich set of tooling), which I presumed I could by going with their GraphQL layer.
Sure, it allows simple inserts, queries and deletes merely from writing a schema. But Fauna is a NoSQL DB by nature, so managing relations between tables is up to you. So I found myself writing solutions which hit the DB multiple times. E.g. inserting a row would first to read and get the ID of the related row in the other table, then this new value and the related ID would be inserted.
FaunaDB does have "Functions", which would run on their infra and do more complex logic in one operation, but 1) it requires writing FQL, which I tried to avoid and 2) I don't want to have another place outside my main code base with logic I need to maintain and update.
So to FaunaDB or not to FaunaDB 🤷♂️ , maybe if I want a NoSQL DB I never want to look at again and fully embrace learning and using FQL. Otherwise, I will pick a managed DB, such as MongoDB Atlas or Heroku's PostgreSQL addon. Then later I can decide if I want to host and scale it myself, pick a different provider of managed DBs to scale it, or stay with the current one.
NextJS is cool, it's a bit like Gatsby, but simpler.* I am delighted with how easy and clean it was to implement authentication with NextAuth.js, so this would already be enough of a reason to pick NextJS again.
The server sided functionality of NextJS seems more tailored towards small functions, but instead I create one GraphQL endpoint which contains all these individual small functions in one schema.
I didn't burn myself too badly with FaunaDB, because the use-case was very well served by a NoSQL DB. So maybe I would choose them for a new project if I am certain that this is again the case.
My other longshot back then was Nexus.js with the Prisma plugin. It generates the GraphQL and DB schema from code, including DB migrations. That I am a lot more optimistic about, until now it worked out pretty well, although it's still under active development.
E.g. I used it here in combination with NextJS:
https://github.com/addono/fridgetory
If I would have to pick something now for a new project where others need to be easily onboarded, then I would go for NextJS with Prisma. Back then Prisma v2 was still in beta, hence I explored a different option, but it's GA now. NextJS has server side rendered props, so that's an easy place to use the Prisma client.
Nexus has quite a steep learning curve. But if I can afford the additional complexity, then I would use Nexus to create the GraphQL endpoint and use that in my NextJS app.
My next longshots for new tech are the "fullstack JAMStack" platforms, e.g. https://github.com/redwoodjs/redwood. For now I'm waiting for TypeScript support to land before taking it for a spin.
*Although some things, like SEO, are more easily solved in Gatsby as there are some very powerful plugins.
