I'm not sure I understand your point about AGPL? Do you have the same issue with the MongoDB license and would hesitate to use Mongo because of their AGPL? Why is this different? Just curious, would love to understand where you're coming from!
That, and the AGPL issue are both more important in this case (compared to MongoDB), because of the position in the stack that Hasura GraphQL Engine (HGE) would have. In the MongoDB case, we would almost always have an application server between Mongo and the GraphQL client, where custom business logic could be implemented, so Mongo can be treated as an external system whose source code we do not need to modify (like PostgreSQL in the case of HGE).
In case of HGE, the GraphQL client would talk directly to HGE, and thus any customisation would most likely need to happen inside HGE, whether by plugins or patches or whatnot, making it tricky to avoid having to open source your custom business logic (as well as probably having to write it in Haskell).
We didn't intend for Hasura to be something like a boilerplate that you would modify. Mostly because it's harder to work with upstream changes when you work with OSS software like that unless it's an explicit library type dependency. What OSS service type component do you use (know of?) that is used in this way?
Currently, we encourage users to use GraphQL schema stitching to customise their GraphQL schema/resolvers treating HGE almost as an external GraphQL service.
But if you’re already building a separate GraphQL server with database integration, the business case for HGE is weakened, since you might as well build the same logic in the other system.
How much of the code base (and complexity) is doing that vs the auto-schema mapping and whatnot?
I would just "read the source, Luke" but haskell isn't one of those languages I can idly read.