We were pretty happy with Hasura but had to switch to Postgraphile due to poor multi-database support, bummer.
(Postgraphile is not as polished as Hasura in some ways, but since it can used as a library, it's easy to dynamically create N instances of it with different configurations at runtime. Hasura required our ops team to define a new instance of the service in the docker-compose.yml file for each database)
Basically, if two entities in the databases have the same names, Hasura fails unless you manually define a unique `custom_name` for each such entity.
Given that the most common multiple database scenario involves different databases with either the exact same schema (one-db-per-tenant) or similar schemas (staging vs. production database), it forces you to painstakingly set a custom_name for basically every single entity in your db.
Thankfully there is an API so in theory you could set this programmatically, but it still means that your client code needs to be manually kept in-sync with whatever custom name generator rule you used.
Hey, I'd be curious to hear your thoughts on our solution. It allows you to combine any number of Databases with PostgreSQL, MySQL, SQLite and SQLServer are supported, here's the full list of supported DataSources: [0]
Our solution comes with a feature called Namespacing [1], which means, every API has its own namespace so there are 0 collisions between the different types and fields. It even goes so far that we also namespace directives so you can have a combined schema of multiple GraphQL APIs and can still use the namespaced directives on fields from that particular upstream.
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
We were pretty happy with Hasura but had to switch to Postgraphile due to poor multi-database support, bummer.
(Postgraphile is not as polished as Hasura in some ways, but since it can used as a library, it's easy to dynamically create N instances of it with different configurations at runtime. Hasura required our ops team to define a new instance of the service in the docker-compose.yml file for each database)