Hadn't heard of Wundergraph, I will keep it in mind if we encounter issues with Postgraphile. Thanks!
Regarding your solution, it seems to be the same that Hasura is working towards. It's a perfectly fine solution if you have a few types that happen to clash in their basic names (we have that too, e.g. for "products.suppliers" vs "services.suppliers").
For multi-tenant solutions, i.e. where all data sources are identical but they refer to different customers' data, separated by user/schema/database/instance, namespacing works but it's not _great_.
It means that the client code needs to get the tenant's namespace from somewhere (probably a claim in the authn system), and then manually interpolate it in all the graphql queries. It's not a security flaw (if you screw up and query spacex_users from a different tenant, you'll just get a 404 - I hope!), but it's going to play awkwardly with most developer tooling, having to always work with interpolated strings.
More importantly, if you use namespace for tenants, now you can't also use them to solve simple name overlaps, unless you split each tenant over multiple APIs.
If you want to improve your multitenant story, here's what we did with Postgraphile (which is a straight adaptation of what our .NET backend does): when the backend starts up, it initializes one identical GraphQL source per tenant. Then looks up each tenant's authorization URL. When a request comes in, the backend validates the auth token, and it uses the signed authorization URL to determine which GraphQL source should run the query.
In this way the clients don't need to worry about tenancy or namespaces at all, there might be a single tenant for all they know. The same request that a developer tests with his login under TestCompany will also run for every other customer, but the auth token and the auth token alone determines which data source it gets run against.
As you can see, this approach isn't a replacement for ad-hoc namespacing. It's meant specifically for the scenario where the same identical schema exists in multiple data sources.
Hey, thanks for your feedback. This sounds like a great feature to add. Would you be available for a chat? I'd like to learn more about how you solved this problem. Your solution sounds very well thought out. You can find me on this discord: https://wundergraph.com/discord
Regarding your solution, it seems to be the same that Hasura is working towards. It's a perfectly fine solution if you have a few types that happen to clash in their basic names (we have that too, e.g. for "products.suppliers" vs "services.suppliers").
For multi-tenant solutions, i.e. where all data sources are identical but they refer to different customers' data, separated by user/schema/database/instance, namespacing works but it's not _great_.
It means that the client code needs to get the tenant's namespace from somewhere (probably a claim in the authn system), and then manually interpolate it in all the graphql queries. It's not a security flaw (if you screw up and query spacex_users from a different tenant, you'll just get a 404 - I hope!), but it's going to play awkwardly with most developer tooling, having to always work with interpolated strings.
More importantly, if you use namespace for tenants, now you can't also use them to solve simple name overlaps, unless you split each tenant over multiple APIs.
If you want to improve your multitenant story, here's what we did with Postgraphile (which is a straight adaptation of what our .NET backend does): when the backend starts up, it initializes one identical GraphQL source per tenant. Then looks up each tenant's authorization URL. When a request comes in, the backend validates the auth token, and it uses the signed authorization URL to determine which GraphQL source should run the query.
In this way the clients don't need to worry about tenancy or namespaces at all, there might be a single tenant for all they know. The same request that a developer tests with his login under TestCompany will also run for every other customer, but the auth token and the auth token alone determines which data source it gets run against.
As you can see, this approach isn't a replacement for ad-hoc namespacing. It's meant specifically for the scenario where the same identical schema exists in multiple data sources.