We're happy to announce the release of Remote Joins today. Data Federation using Hasura Remote Joins is now available in v1.3 beta. You can join the discussion on the #preview channel on our discord community.
With Remote Joins, developers can treat data across different data sources as if it were one database without having to modify or affect the existing data source
As developers and teams move to using more and more 3rd party APIs, multiple databases & microservices, data and "the source of truth" is getting spread across these data-sources. Application developers have a hard time getting access to precise slices of data and a lot of dev cycles are spent in bringing all that data together securely.
Remote Joins in Hasura extend the concept of joining data across tables, to being able to join data across tables and remote data sources. Once you create relationships between types from your database and types created from APIs, you can then “join” them by running GraphQL queries.
Remote joins can join across the database and APIs. These APIs can be custom GraphQL servers you write, 3rd party SaaS APIs, or even other Hasura instances.
Of course, because Hasura is meant to be a GraphQL server that you can expose directly to your apps, Hasura also handles security and authorization while providing remote joins.
Use Case #1: Customer data joined with Account/Billing/Payment information in Stripe
If you have a payment method on your app that uses Stripe, a lot of account and billing information about your customer resides with Stripe. For example, the customer's saved cards, account balance, billing/invoice history.
On your app, you'd typically want to show users their saved cards and invoice history. You'd write code to fetch the right data from the Stripe API for the right users/invoices and return that as an API response to your app.
This is what this setup looks like on Hasura:
Step 1: Setup OneGraph to connect to your Stripe account
Step 2: Add OneGraph as a remote schema to Hasura
Step 3: Setup a remote relationship from your customer table to the Stripe resolver using the
stripe_customer_id as the "join" key
Step 4: Make GraphQL queries to fetch customer and stripe information in one shot!
Use-case #2: User data joined with profile information in Auth0
When you use an external authentication provider (or even an authentication/user management microservice that your team doesn't own directly), there will be some information that is only provided by the auth service. For example,
login_count and so on.
In your database, you would typically have a user table that has an
auth0_id. To fetch auth specific information, you would need to use this id and the Auth0 API.
Here's how Hasura helps you automate that process:
Step 1: Write a serverless function that wraps the Auth0 profile API in a GraphQL query resolver.
Step 2: Connect this as a remote schema in Hasura
Step 3: Go to the User table on Hasura and add a "remote relationship" to the schema you added above
Step 4: Make a GraphQL query to query data from the user table and the Auth0 profile information simultaneously
Use-case #3: Joining data across 2 separate databases
The title says it all ?. And here's how this works with Hasura!
Step 1: Setup Hasura to point to Database 1 and Database 2 with the right access control rules so that your GraphQL API is secure
Step 2: On the Hasura of your "primary" database, add the second Hasura as a remote schema
Step 3: Set up remote relationships from any table in your "primary" database to resolvers in the other database.
Step 4: Run a GraphQL query that joins data across 2 databases!
Note: Hasura Remote Joins is a type of federation, similar to Apollo Federation. The key difference is that Apollo Federation aims to help organisations with multiple GraphQL teams “federate” a global GraphQL schema. Hasura remote joins help you “join” across multiple data-sources (or GraphQL & REST microservices) so that you get a unified GraphQL API with data federation. This unified GraphQL API might be required for a team that has multiple sources of data for their application or might be a unified GraphQL API across various teams maintained by a central data API team in the organisation.