It looks like a nice library. It might be good as a learning tool. I'm not sure what kind of use-case I would want it for, maybe a small game? It looks similar to how I've done smaller/demo/mock-up APIs for frontend apps. I like the simplicity.
I think if I was going to be deploying a real database (PostgreSQL), I'd want to do things with authorization and network configuration; at which point I'd be dealing with enough stuff around the user profile that I'd want my preferred query and mutation design (GraphQL + Relay).
If at any point you're going to be fetching data containing long lists, I'd also prefer to be working with GraphQL and Relay because the design is well thought-out for doing filtering, pagination, and caching.
Decoupling is good any time you want to allow different parts to change independently. Migrating architectures can take a significant amount of effort, but it just depends what you want to accomplish.
One way to think about Wildcard (and RPC in general) is that it allows you to directly use SQL queries to retrieve and mutate data for your frontend.
That said, if you prefer using Relay + GraphQL over writing SQL queries, then Wildcard (and RPC) may not be the right tool for you. Although I'd worry about the complexity of your stack. Unnecessary complex stacks tend to be an evil time sink in the long run. Simplicity is key.
RPC + PotgreSQL is fundamentally simpler than Relay + GraphQL + Hasura + PotgreSQL.
The thing is that you need GraphQL only when you need to expose your data to third parties.
GraphQL = generic API = thid-party devS.
For consuming your database from your own frontend, you don't need GraphQL and RPC is enough and simpler.
> Decoupling is good any time you want to allow different parts to change independently
With Wildcard(/RPC) you deploy frontend and backend at the same time but you develop both independently.
Migration is easy when you create a GraphQL API in parallel to your existing RPC API and progressively transition from your RPC API to your newly created GraphQL API. That said, chances are high that GraphQL will never be needed; only very large companies need GraphQL (the organization is so large that exposing an API to the whole organization is almost like exposing an API to the whole world). Basically devS of very large companies ~= third-party devS and you then need a generic API such as GraphQL.
I think if I was going to be deploying a real database (PostgreSQL), I'd want to do things with authorization and network configuration; at which point I'd be dealing with enough stuff around the user profile that I'd want my preferred query and mutation design (GraphQL + Relay).
If at any point you're going to be fetching data containing long lists, I'd also prefer to be working with GraphQL and Relay because the design is well thought-out for doing filtering, pagination, and caching.
Decoupling is good any time you want to allow different parts to change independently. Migrating architectures can take a significant amount of effort, but it just depends what you want to accomplish.