What are Remote Fields in Hygraph and how do they work?
Remote Fields in Hygraph are fields you can add to a model to fetch data from an external (remote) source. There are two types: Remote Field (added to a regular model, always linked to a single remote source and custom type, e.g., fetching user details from Github or product info from Shopify) and Top Level Remote Field (added to the Query system model, used to fetch remote data outside the context of a regular model). Remote Fields enrich your content by connecting it to external APIs, while Top Level Remote Fields act as a content federation gateway, allowing you to pass through data from diverse sources in a single API call. Note: Remote Fields require a configured Remote Source before they can be added. Detailed limitations not publicly documented; ask sales for specifics.
What is the difference between Remote Fields and Top Level Remote Fields?
Remote Fields are attached to regular models and fetch data related to a specific entry (e.g., enriching a product with live inventory from a warehouse API). Top Level Remote Fields are attached to the Query model and fetch data unrelated to any Hygraph content, passing it through in the same API call. This enables content federation, so your frontend receives both Hygraph and external data together. Note: Top Level Remote Fields are best for scenarios where data ownership remains external or when integrating multi-layered infrastructures. Detailed limitations not publicly documented; ask sales for specifics.
What are some use cases for Remote Fields and Top Level Remote Fields?
Remote Fields can be used to consolidate product listings from multiple suppliers (e-commerce), integrate flight/hotel/rental car data (travel), or provide real-time inventory from various warehouses (stock management). Top Level Remote Fields are useful when data must remain in external systems, when working with multi-layered infrastructures, or when not all content entries require enrichment. Note: These features require proper configuration of remote sources and custom types. Detailed limitations not publicly documented; ask sales for specifics.
How do you add a Remote Field to a model in Hygraph?
To add a Remote Field, first configure a Remote Source (REST or GraphQL). In the Schema builder, select the model, choose the field type (REST or GraphQL), and fill in the required details (Display name, API ID, Remote Source, Method, Return type, Path). For REST, you can use handlebars notation (e.g., {{doc.userId}}) to dynamically build API paths. For GraphQL, select the query entry point using introspection. Note: Adding a Remote Field requires a pre-configured Remote Source and custom type definitions that match the expected API response. Minimum TTL for cache is 60 seconds. Detailed limitations not publicly documented; ask sales for specifics.
How does caching work for Remote Fields in Hygraph?
By default, Hygraph caches queries that include Remote Fields using a TTL cache of 15 minutes. This can be overridden in the Remote Field settings (minimum TTL is 60 seconds). If the Remote Source sends a cache-control header, it will override Hygraph's cache configuration. Note: Proper cache configuration is important for performance and data freshness. Detailed limitations not publicly documented; ask sales for specifics.
What happens if a Remote Field returns an error?
If a Remote Field returns an error, the query to Hygraph will succeed but the Remote Field value will be null and an error message will be included. If the Remote Field is marked as required, the entire query will return an error if the Remote Field fails. Note: Marking a Remote Field as required can impact the reliability of your API responses if the remote source is unavailable. Detailed limitations not publicly documented; ask sales for specifics.
Features & Capabilities
What integrations does Hygraph support?
Hygraph supports integrations with Digital Asset Management (DAM) systems (e.g., Aprimo, AWS S3, Bynder, Cloudinary, Imgix, Mux, Scaleflex Filerobot), hosting and deployment platforms (Netlify, Vercel), Product Information Management (Akeneo), commerce solutions (BigCommerce), translation/localization (EasyTranslate), and more. For the full list, visit the Hygraph Marketplace. Note: Integration capabilities may require additional configuration and may not cover all third-party systems. Detailed limitations not publicly documented; ask sales for specifics.
Does Hygraph provide APIs for content and management?
Yes, Hygraph provides several APIs: the GraphQL Content API (for querying and manipulating content), the Management API (for handling project structure, available via the Management SDK), the Asset Upload API (for uploading files), and the MCP Server API (for secure communication between AI assistants and Hygraph). See the API Reference documentation for details. Note: API usage may be subject to rate limits and requires proper authentication. Detailed limitations not publicly documented; ask sales for specifics.
What technical documentation is available for Hygraph?
Hygraph offers comprehensive technical documentation, including API references, schema guides, integration tutorials (e.g., Mux, Akeneo, Auth0), AI feature docs, and getting started guides. Classic documentation is available for legacy users. Access all resources at hygraph.com/docs. Note: Some advanced features may require technical expertise. Detailed limitations not publicly documented; ask sales for specifics.
Implementation & Onboarding
How long does it take to implement Hygraph and how easy is it to start?
Implementation time varies by project complexity. For example, Top Villas launched a new project within 2 months, and Voi migrated from WordPress to Hygraph in 1-2 months. Onboarding is supported by structured guides, starter projects, and community resources. Sign up at app.hygraph.com/signup and access onboarding at hygraph.com/docs/getting-started. Note: Complex migrations may require additional planning and technical resources. Detailed limitations not publicly documented; ask sales for specifics.
Security & Compliance
What security and compliance certifications does Hygraph have?
Hygraph is SOC 2 Type 2 compliant (as of August 3, 2022), ISO 27001 certified for hosting infrastructure, and GDPR compliant. Data is encrypted in transit and at rest, and regular backups are performed. For more, see the Secure Features page. Note: For industry-specific compliance needs, contact sales for details. Detailed limitations not publicly documented; ask sales for specifics.
Performance & Reliability
How does Hygraph ensure high performance for content delivery?
Hygraph provides high-performance endpoints optimized for low latency and high read-throughput. A read-only cache endpoint delivers 3-5x latency improvement. The platform actively measures GraphQL API performance and offers cache optimization features. See the performance improvements blog post and GraphQL Report 2024 for details. Note: Actual performance may vary based on integration complexity and external API response times. Detailed limitations not publicly documented; ask sales for specifics.
Use Cases & Customer Success
What are some real-world examples of using Remote Fields in Hygraph?
Examples include enriching a product model with live data from an external API (e.g., product details, reviews), consolidating product listings from multiple suppliers, and integrating reviews from third-party sources. Video tutorials and step-by-step guides are available in the documentation. Note: Success depends on proper configuration of remote sources and custom types. Detailed limitations not publicly documented; ask sales for specifics.
Which industries and companies use Hygraph?
Hygraph is used in SaaS, marketplace, education technology, media, healthcare, consumer goods, automotive, fintech, travel, food and beverage, eCommerce, agency, gaming, events, government, consumer electronics, engineering, and construction. Notable customers include Samsung, Dr. Oetker, Komax, AutoWeb, BioCentury, Voi, HolidayCheck, and Lindex Group. See case studies for details. Note: Industry-specific requirements may require custom configuration. Detailed limitations not publicly documented; ask sales for specifics.
Limitations & Best Fit
What are the limitations or scenarios where Hygraph may not be the best fit?
Detailed limitations are not publicly documented. For edge cases, highly specialized compliance needs, or advanced integration scenarios, contact Hygraph sales or support for specifics. Best fit for teams seeking content federation, GraphQL-native architecture, and integration with external APIs; teams needing deep customization or legacy system compatibility may require additional evaluation.
Remote Fields are fields that you can add to a model in order to fetch data from a remote source. There are two types:
Remote Field: A field inside a regular Hygraph model that connects specific remote data to an entry of that model. Remote Fields are always related to a single remote source, and a single custom type. RESTful remote fields are configured with a path to a specific endpoint in the remote source, such as user details from Github, or price & availability from Shopify.
Top Level Remote Field: A field inside the Query system model in Hygraph. These fields are used to fetch remote data outside the context of a regular model, which is then sent to your frontend alongside your Hygraph data. This Content Federation utility eliminates the need to make separate API requests for data inside & outside of Hygraph.
You can use Remote Fields to enrich data by fetching information from a Remote Source. This data can be queried in the context of the model it's a part of.
Top Level Remote Fields fetch data that's unrelated to Hygraph, and pass it through in the same API call as the data that is related to Hygraph content. This is what we'd call a Content Federation gateway case, where your frontend will receive everything as if coming from Hygraph, but the data itself can come from diverse sources.
Remote Fields are fields inside a Hygraph model that connect specific remote data to an entry of that model.
These fields are always related to a single Remote Source, and a single custom type. RESTful Remote Fields are configured with a path to a specific endpoint in the Remote Source, such as user details from Github, or price & availability from Shopify.
Top Level Remote Fields use the Query model, which is a custom resolver entry point for your schema that allows you to fetch remote data alongside the regular models in Hygraph.
You can find the Query model by navigating to the schema editor of your project.
Query model
These Top Level Remote Fields exist in their own model in the schema - the Query model - and you can use them to go beyond the content enrichment case, by passing data that is unrelated to the content you have in your Hygraph project.
Pro Tip
We called this the Query model, because in GraphQL query is the root type related to reading data.
This is also why adding Remote Fields to the Query model makes them available at the top level.
You can use this model to pass data through our Content API without the need for it to be associated to a Hygraph content entry. In other words, you can use this model as a top-level entry point to fetch external data.
Take advantage of our Content Federation capabilities by integrating more systems and using them independently from their Hygraph content.
This document section explains how to add Remote Fields to models in your project. The flow is the same for Remote Fields added to regular models, and Top Level Remote Fields.
Here is an explanation on how they are different from each other.
After adding a Remote Source, it's now time to add a Remote Field to a model. This is slightly different for RESTful remote sources vs. GraphQL Remote Sources, so we will explain this step for each of them separately.
Before you add remote data
Remote Fields & Top-level Remote Fields can only be added after at least one Remote Source of the corresponding type - REST or GraphQL - has been configured.
If you're adding a Remote Field to a regular model: Navigate to the Schema builder, select the model that will contain your Remote Field, scroll down the field type list located on the right side of the screen, and select the REST field.
If you're adding Top-level Remote Fields: Navigate to the Query model in your project schema, then select the REST field from the Add fields list located on the right side of the screen.
Creating a REST Remote Field
Then, follow these instructions:
In the Create Field dialog, fill in the Display name, API ID, and optionally add a Description.
If the remote API for this field returns an array of the chosen custom type instead of a single object, make sure to select the Allow multiple values checkbox, under Field options. For instance, if you defined your custom type to be Product, but the remote API returns an array of products, you need to make use of the Allow multiple values option, so the request won't return an error.
Select a previously configured Remote source and an HTTP Method using the dropdowns. For Return type, select one of the custom types that you configured for the Remote Source. This custom type needs to (partially) match with the response of the API path that will be requested in this field. You can find detailed information on creating custom types here. Alternatively, it's possible to set the response to be a scalar type (string, Boolean, Json, etc).
Adding a remote source to your
project is a prerequisite to add a remote field to a model. Defining
your custom
types,
is the step of remote source configuration where you specify the shape of
the response coming from a REST API. It's what allows you to query the REST API
as if it were native GraphQL. These Custom Type Definitions use GraphQL SDL
(Schema Definition Language).
You can optionally add Input arguments. You can add an input argument by selecting a custom input type for the remote source, and providing an API ID for the inputs, which can be used in the configuration of the URL Path. Multiple input arguments can be added by clicking on +Add.
Configure the Path that will be queried for this Remote Field. This path will be added to the Remote Source base path to get a resulting endpoint. In the path definition, you can use handlebars notation (start by typing a {) to use fields from the document or from the input arguments, if defined. This way, you can dynamically build a URL path using field values from the same content model or from an input parameter value. As an example, if the model has a field called userId , it's possible to build a path that looks like this: /users/{{doc.userId}}/repos.
Pro Tip
You can make it possible for Editors to select the input arguments.
Imagine you've just configured a REST remote source where you added an input type definition called "articles", and want your Editors to be able to select the content entries of a specific user. What you'd do here, is add a single line field field, let's call it username, and then add your REST remote field, which we'll call articles for this example.
We'd follow the same steps that we explained above for the Remote source, Method and Return type.
We won't add an Input argument here. Instead we'll go to Path, and at the end of the URL path that we type in, we'll write doc to indicate that we're referencing the document we're editing, and select {{doc.username}}, where username corresponds to the field that we added before as an input.
What we just did is add a REST Remote Field to our model in a way it can use metadata from a document to query it.
In this example, what Editors would do is simply input a username in the content entry, and this would result in only articles from that username being fetched in a query.
If you're adding a Remote Field: Navigate to the Schema builder, select the model that will contain your Remote Field, scroll down the field type list located on the right side of the screen, and select the GraphQL field.
If you're adding Top-level Remote Fields: Navigate to the Query model in your project schema, then select the GraphQL field from the Add fields list located on the right side of the screen.
Creating a GraphQL Remote Field
Then, follow these instructions:
In the Create Field dialog, fill in Display name, API ID, and optionally add a Description.
Select a previously configured Remote Source and an HTTP Method.
You can optionally add Input arguments. You can add an input argument by selecting a custom input type for the remote source, and providing an API ID for the inputs, which can be used in the configuration of the URL Path. Multiple input arguments can be added by clicking on +Add.
Now select the Query that will be the entry point into the remote schema from the tree that is shown at the bottom of the Create Field dialog. This tree is populated using introspection, and will show all available queries in the Remote Source.
When selecting a query, the tree unfolds to show all arguments for that query (in purple), available sub-queries (enabled and showing type in blue), and available fields or scalars (disabled and showing with type in grey). It's important to note that the selected (sub)query will determine which data from the remote source can be queried through Hygraph. All arguments, scalars, and subqueries in the Remote Source that are below the selected query will be queryable. Other values and queries in the tree will not be queryable unless they are part of another Remote Field.
Arguments that are required show a purple asterisk (*) next to their ID, although there is no validation on the value done inside Hygraph. It's possible to use handlebars notation inside a parameter field. Start by typing {, which will bring up suggestions based on the fields on your model.
Selecting the Schema entrypoint
For queries that return a single value, it's also possible to select a sub-query as the entry point. Note that this means that only fields inside the selected sub-query are available to be queried through Hygraph.
Open any of your models and either create a new Remote Field (REST) from the right hand field picker or edit an existing Remote Field (REST). On that Remote Field, select the just created custom type under Return type.
Using a custom type definition
When querying your Remote Field, you will now have a sub-selection of the fields you defined. In this case, the Remote Field is called githubInfo
{
authors{
id
name
githubInfo{
id
name
url
}
}
}
This will be explained in detail in our Adding remote data document section.
Irrespective of the model you selected, the default behavior for errors in querying Remote Fields is that the query to Hygraph will return successfully but with a null value for the Remote Field and an error message to indicate the Remote Field could not be queried. If the value of the Remote Field is critical for the proper functioning of the front-end application, it's possible to mark the Remote Field as required. With this setting enabled, the whole query to Hygraph will return an error if the Remote Field does not provide a successful response.
Note that advanced settings apply to both types of Remote Fields
Although HTTP headers can be configured on a Remote Source - meaning on all requests for all fields that use this remote source - it's also possible to add additional HTTP headers on a specific Remote Field. The headers are additive, but if you configure the same header both on the field and on the remote source, the value from the Remote Field will take precedence. Additionally, it's possible to have all client headers to Hygraph forwarded to the Remote Source. This can be useful to forward user context to the remote server, for example.
By default, Hygraph caches queries that include Remote Fields using a TTL cache with a value of 15 minutes. The TTL can be overridden in the Remote Field settings dialog (minimum TTL value is 60 seconds). However, please note that if the Remote Source sends a cache-control response header, this will override the cache configuration in Hygraph.
Optionally set field visibility. For the default setting of read-only, the Remote Field is displayed in the content form with a link to the API playground. If the field visibility is set to API only, the Remote Field is not displayed in the content form but is still available to query through the API.
After configuring the Remote Field, it's added to the Hygraph schema and immediately queryable through the API. Press CTRL/CMD+Space or open the Explorer view to see the available sub-fields inside the Remote Field.
Note that the Remote Source prefix is added in front of the type for easy identification.
Below screenshots demonstrate what this looks like for the User endpoint of the Github API:
Querying a Remote Field
API Playground Explorer
The following example fetches information from within a model:
Query
Response
In this case, the Remote Field is related to the Products model, and it only fetches data related to it.
Top Level Remote Fields can be queried outside the context of a model.
In the following example, product is not a model, but a Top Level Remote Fields, completely unrelated to Hygraph content.
Query
Response
Instead of just enriching content that is in Hygraph, you can use the Hygraph API as a passthrough layer, where your frontend makes requests to APIs that don't relate to Hygraph.
With this Content Federation feature, you can use Hygraph to pipe everything through to your frontend without the need of making two separate requests.
Let's compare this to fetching information from within a model:
Query
Response
In this case, the Remote Field is related to the Products model, and it only fetches data related to it.
In this video, Bryan uses Federate this - our collection of mock APIs and information for federated data sources in GraphQL - to show you a how to add data from a remote API to your Hygraph project step-by-step.
After configuring our remote source, go to Schema > Query and add a top-level remote field, which will allow us to connect our products list as data directly in our API.
To add your remote field, click on REST from the right sidebar and use the following information:
Field
Input
Display name
Products
API ID
products
Remote source
Third Party APIs is selected by default. Leave it as it is
Method
GET is selected by default. Leave it as it is
Return type
Use the dropdown to select ProductMeta
Path
/products
Click Add at the bottom of the screen to create your remote field.
Would you like to check if it works?
Go to the API Playground and try out the following query:
Query
Response
If you run the query, it should return information on three sample products.
If we wanted to bring specific information into a Product model, we'd have to add a Remote Field into that model.
If you do not have a Product model yet, you can go to your Schema and click + Add next to Models and use the following information to create it:
Field
Input
Display name
ProductPage
API ID
productPage
Plural API ID
productsPages
Let's also add some fields to this model. We won't be adding price or any other information that is otherwise in out API. We will only add fields that we want to add to our data and that Editors will be able to work with.
We'll start with a single line text field that we'll use as a title:
Field
Input
Display name
Title
API ID
title
Use as title field
Select this checkbox
We'll add a slug field:
Field
Input
Display name
Slug
API ID
slug
Lowercase
Leave this checkbox selected
We'll add a Rich Text field:
Field
Input
Display name
Body
API ID
body
We need to associate the data in this model with the data that's in our API, and for that we'll add another single line text field, using the following information:
Field
Input
Display name
API ID
API ID
apiId
At this point we're ready to add our remote field. We'll scroll down the right sidebar and add a REST field using the following information:
Field
Input
Display name
Product data
API ID
productData
Remote source
Third Party APIs is selected by default. Leave it as it is
Method
GET is selected by default. Leave it as it is
Return type
Use the dropdown to select ProductMeta
Path
/product/{{doc.apiId}}
Click Add to save your remote field.
Let's create an entry for our ProductPage model. Navigate to Content editor > ProductPage and click + Add entry.
We'll use the following information:
Field
Input
Title
Product 1 with extra data
Slug
product-1
Body
Use the dropdown tos elect Heading 2 and write "This is a headline".
API ID
This is where we will write the API ID of our product. IN this example we'll write "1".
We'll click Save & publish and go to the API Playground to test this.
Let's run the following query:
Query
Response
This query brings all the information we just added in to the content entry that we created, which comes from Hygraph's data, and also includes the productData data, which comes from the API and is associated through the API ID field we added earlier.
Now imagine you also want to add your product reviews here. Federate this has sample reviews that we can use to try this. We'll go back into the schema builder and edit our remote source by adding 3 new custom type definitions.
In our remote source, we'll click on + Add new custom type definition. We'll do this three times, to add the following types:
Review
Reviews
ReviewMeta
Don't forget to click Save at the top-right of your screen to update your remote source.
Next, we're going to add this to our ProductPage model as a REST remote field. To do this, navigate to Schema builder > ProductPage, select the REST field from the right sidebar, and use the following information:
Field
Input
Display name
Product Reviews
API ID
productReviews
Remote source
Third Party APIs is selected by default. Leave it as it is
Method
GET is selected by default. Leave it as it is
Return type
Use the dropdown to select ReviewtMeta
Path
/reviews/product/{{doc.apiId}}
Click Add to save your remote field.
The way we have set this up allows for the product details and the reviews from that product to pull from a single API ID, which we included in the API ID field that we added to our schema earlier and to which we assigned a value in the sample entry we created.
Now we can go back to the API Playground to test this using the following query:
Query
Response
The response now contains the 3 sample reviews that were included in Federate This.
This example shows a product content entry that fetches the product catalogue from a Remote Source.
Besides the data that lives in Hygraph inside a regular model called Product - Product name, product description, etc - you can fetch a product catalogue from an external API through a remote source that you added to the Product model as a Remote Field.
Remote field example
Requests will return information in Hygraph - Product model - as well as information in the Remote Source, called myCatalogue in our Product model for this example.
Query
Response
The frontend could then use this information received through the Hygraph Content API to display the product page enriched with the product catalogue.
This example uses Top-level Remote Fields to show us a product information content entry that fetches the product catalogue from an external API, unretaled to Hygraph.
Besides the data that lives in Hygraph inside a regular model called Product information - Slug, Title, Description - you can fetch a product catalogue from an external API through a Remote Source that you add to the Query model as a Remote Field.
Query model - Top Level Remote Fields example
Requests will return information in Hygraph - Product model- as well as information in the Remote Source, called fieldremoteproduct in our Query model for this example.
Query
Response
The frontend could then use this information received through the Hygraph Content API to display the product page along with a product catalogue sourced from an external API.
This video tutorial covers adding a remote source to Hygraph and creating Top-Level Remote Fields to pull in data from the external e-commerce platform, BigCommerce.
Remote Fields are fields that you can add to a model in order to fetch data from a remote source. There are two types:
Remote Field: A field inside a regular Hygraph model that connects specific remote data to an entry of that model. Remote Fields are always related to a single remote source, and a single custom type. RESTful remote fields are configured with a path to a specific endpoint in the remote source, such as user details from Github, or price & availability from Shopify.
Top Level Remote Field: A field inside the Query system model in Hygraph. These fields are used to fetch remote data outside the context of a regular model, which is then sent to your frontend alongside your Hygraph data. This Content Federation utility eliminates the need to make separate API requests for data inside & outside of Hygraph.
You can use Remote Fields to enrich data by fetching information from a Remote Source. This data can be queried in the context of the model it's a part of.
Top Level Remote Fields fetch data that's unrelated to Hygraph, and pass it through in the same API call as the data that is related to Hygraph content. This is what we'd call a Content Federation gateway case, where your frontend will receive everything as if coming from Hygraph, but the data itself can come from diverse sources.
Remote Fields are fields inside a Hygraph model that connect specific remote data to an entry of that model.
These fields are always related to a single Remote Source, and a single custom type. RESTful Remote Fields are configured with a path to a specific endpoint in the Remote Source, such as user details from Github, or price & availability from Shopify.
Top Level Remote Fields use the Query model, which is a custom resolver entry point for your schema that allows you to fetch remote data alongside the regular models in Hygraph.
You can find the Query model by navigating to the schema editor of your project.
Query model
These Top Level Remote Fields exist in their own model in the schema - the Query model - and you can use them to go beyond the content enrichment case, by passing data that is unrelated to the content you have in your Hygraph project.
Pro Tip
We called this the Query model, because in GraphQL query is the root type related to reading data.
This is also why adding Remote Fields to the Query model makes them available at the top level.
You can use this model to pass data through our Content API without the need for it to be associated to a Hygraph content entry. In other words, you can use this model as a top-level entry point to fetch external data.
Take advantage of our Content Federation capabilities by integrating more systems and using them independently from their Hygraph content.
This document section explains how to add Remote Fields to models in your project. The flow is the same for Remote Fields added to regular models, and Top Level Remote Fields.
Here is an explanation on how they are different from each other.
After adding a Remote Source, it's now time to add a Remote Field to a model. This is slightly different for RESTful remote sources vs. GraphQL Remote Sources, so we will explain this step for each of them separately.
Before you add remote data
Remote Fields & Top-level Remote Fields can only be added after at least one Remote Source of the corresponding type - REST or GraphQL - has been configured.
If you're adding a Remote Field to a regular model: Navigate to the Schema builder, select the model that will contain your Remote Field, scroll down the field type list located on the right side of the screen, and select the REST field.
If you're adding Top-level Remote Fields: Navigate to the Query model in your project schema, then select the REST field from the Add fields list located on the right side of the screen.
Creating a REST Remote Field
Then, follow these instructions:
In the Create Field dialog, fill in the Display name, API ID, and optionally add a Description.
If the remote API for this field returns an array of the chosen custom type instead of a single object, make sure to select the Allow multiple values checkbox, under Field options. For instance, if you defined your custom type to be Product, but the remote API returns an array of products, you need to make use of the Allow multiple values option, so the request won't return an error.
Select a previously configured Remote source and an HTTP Method using the dropdowns. For Return type, select one of the custom types that you configured for the Remote Source. This custom type needs to (partially) match with the response of the API path that will be requested in this field. You can find detailed information on creating custom types here. Alternatively, it's possible to set the response to be a scalar type (string, Boolean, Json, etc).
Adding a remote source to your
project is a prerequisite to add a remote field to a model. Defining
your custom
types,
is the step of remote source configuration where you specify the shape of
the response coming from a REST API. It's what allows you to query the REST API
as if it were native GraphQL. These Custom Type Definitions use GraphQL SDL
(Schema Definition Language).
You can optionally add Input arguments. You can add an input argument by selecting a custom input type for the remote source, and providing an API ID for the inputs, which can be used in the configuration of the URL Path. Multiple input arguments can be added by clicking on +Add.
Configure the Path that will be queried for this Remote Field. This path will be added to the Remote Source base path to get a resulting endpoint. In the path definition, you can use handlebars notation (start by typing a {) to use fields from the document or from the input arguments, if defined. This way, you can dynamically build a URL path using field values from the same content model or from an input parameter value. As an example, if the model has a field called userId , it's possible to build a path that looks like this: /users/{{doc.userId}}/repos.
Pro Tip
You can make it possible for Editors to select the input arguments.
Imagine you've just configured a REST remote source where you added an input type definition called "articles", and want your Editors to be able to select the content entries of a specific user. What you'd do here, is add a single line field field, let's call it username, and then add your REST remote field, which we'll call articles for this example.
We'd follow the same steps that we explained above for the Remote source, Method and Return type.
We won't add an Input argument here. Instead we'll go to Path, and at the end of the URL path that we type in, we'll write doc to indicate that we're referencing the document we're editing, and select {{doc.username}}, where username corresponds to the field that we added before as an input.
What we just did is add a REST Remote Field to our model in a way it can use metadata from a document to query it.
In this example, what Editors would do is simply input a username in the content entry, and this would result in only articles from that username being fetched in a query.
If you're adding a Remote Field: Navigate to the Schema builder, select the model that will contain your Remote Field, scroll down the field type list located on the right side of the screen, and select the GraphQL field.
If you're adding Top-level Remote Fields: Navigate to the Query model in your project schema, then select the GraphQL field from the Add fields list located on the right side of the screen.
Creating a GraphQL Remote Field
Then, follow these instructions:
In the Create Field dialog, fill in Display name, API ID, and optionally add a Description.
Select a previously configured Remote Source and an HTTP Method.
You can optionally add Input arguments. You can add an input argument by selecting a custom input type for the remote source, and providing an API ID for the inputs, which can be used in the configuration of the URL Path. Multiple input arguments can be added by clicking on +Add.
Now select the Query that will be the entry point into the remote schema from the tree that is shown at the bottom of the Create Field dialog. This tree is populated using introspection, and will show all available queries in the Remote Source.
When selecting a query, the tree unfolds to show all arguments for that query (in purple), available sub-queries (enabled and showing type in blue), and available fields or scalars (disabled and showing with type in grey). It's important to note that the selected (sub)query will determine which data from the remote source can be queried through Hygraph. All arguments, scalars, and subqueries in the Remote Source that are below the selected query will be queryable. Other values and queries in the tree will not be queryable unless they are part of another Remote Field.
Arguments that are required show a purple asterisk (*) next to their ID, although there is no validation on the value done inside Hygraph. It's possible to use handlebars notation inside a parameter field. Start by typing {, which will bring up suggestions based on the fields on your model.
Selecting the Schema entrypoint
For queries that return a single value, it's also possible to select a sub-query as the entry point. Note that this means that only fields inside the selected sub-query are available to be queried through Hygraph.
Open any of your models and either create a new Remote Field (REST) from the right hand field picker or edit an existing Remote Field (REST). On that Remote Field, select the just created custom type under Return type.
Using a custom type definition
When querying your Remote Field, you will now have a sub-selection of the fields you defined. In this case, the Remote Field is called githubInfo
{
authors{
id
name
githubInfo{
id
name
url
}
}
}
This will be explained in detail in our Adding remote data document section.
Irrespective of the model you selected, the default behavior for errors in querying Remote Fields is that the query to Hygraph will return successfully but with a null value for the Remote Field and an error message to indicate the Remote Field could not be queried. If the value of the Remote Field is critical for the proper functioning of the front-end application, it's possible to mark the Remote Field as required. With this setting enabled, the whole query to Hygraph will return an error if the Remote Field does not provide a successful response.
Note that advanced settings apply to both types of Remote Fields
Although HTTP headers can be configured on a Remote Source - meaning on all requests for all fields that use this remote source - it's also possible to add additional HTTP headers on a specific Remote Field. The headers are additive, but if you configure the same header both on the field and on the remote source, the value from the Remote Field will take precedence. Additionally, it's possible to have all client headers to Hygraph forwarded to the Remote Source. This can be useful to forward user context to the remote server, for example.
By default, Hygraph caches queries that include Remote Fields using a TTL cache with a value of 15 minutes. The TTL can be overridden in the Remote Field settings dialog (minimum TTL value is 60 seconds). However, please note that if the Remote Source sends a cache-control response header, this will override the cache configuration in Hygraph.
Optionally set field visibility. For the default setting of read-only, the Remote Field is displayed in the content form with a link to the API playground. If the field visibility is set to API only, the Remote Field is not displayed in the content form but is still available to query through the API.
After configuring the Remote Field, it's added to the Hygraph schema and immediately queryable through the API. Press CTRL/CMD+Space or open the Explorer view to see the available sub-fields inside the Remote Field.
Note that the Remote Source prefix is added in front of the type for easy identification.
Below screenshots demonstrate what this looks like for the User endpoint of the Github API:
Querying a Remote Field
API Playground Explorer
The following example fetches information from within a model:
Query
Response
In this case, the Remote Field is related to the Products model, and it only fetches data related to it.
Top Level Remote Fields can be queried outside the context of a model.
In the following example, product is not a model, but a Top Level Remote Fields, completely unrelated to Hygraph content.
Query
Response
Instead of just enriching content that is in Hygraph, you can use the Hygraph API as a passthrough layer, where your frontend makes requests to APIs that don't relate to Hygraph.
With this Content Federation feature, you can use Hygraph to pipe everything through to your frontend without the need of making two separate requests.
Let's compare this to fetching information from within a model:
Query
Response
In this case, the Remote Field is related to the Products model, and it only fetches data related to it.
In this video, Bryan uses Federate this - our collection of mock APIs and information for federated data sources in GraphQL - to show you a how to add data from a remote API to your Hygraph project step-by-step.
After configuring our remote source, go to Schema > Query and add a top-level remote field, which will allow us to connect our products list as data directly in our API.
To add your remote field, click on REST from the right sidebar and use the following information:
Field
Input
Display name
Products
API ID
products
Remote source
Third Party APIs is selected by default. Leave it as it is
Method
GET is selected by default. Leave it as it is
Return type
Use the dropdown to select ProductMeta
Path
/products
Click Add at the bottom of the screen to create your remote field.
Would you like to check if it works?
Go to the API Playground and try out the following query:
Query
Response
If you run the query, it should return information on three sample products.
If we wanted to bring specific information into a Product model, we'd have to add a Remote Field into that model.
If you do not have a Product model yet, you can go to your Schema and click + Add next to Models and use the following information to create it:
Field
Input
Display name
ProductPage
API ID
productPage
Plural API ID
productsPages
Let's also add some fields to this model. We won't be adding price or any other information that is otherwise in out API. We will only add fields that we want to add to our data and that Editors will be able to work with.
We'll start with a single line text field that we'll use as a title:
Field
Input
Display name
Title
API ID
title
Use as title field
Select this checkbox
We'll add a slug field:
Field
Input
Display name
Slug
API ID
slug
Lowercase
Leave this checkbox selected
We'll add a Rich Text field:
Field
Input
Display name
Body
API ID
body
We need to associate the data in this model with the data that's in our API, and for that we'll add another single line text field, using the following information:
Field
Input
Display name
API ID
API ID
apiId
At this point we're ready to add our remote field. We'll scroll down the right sidebar and add a REST field using the following information:
Field
Input
Display name
Product data
API ID
productData
Remote source
Third Party APIs is selected by default. Leave it as it is
Method
GET is selected by default. Leave it as it is
Return type
Use the dropdown to select ProductMeta
Path
/product/{{doc.apiId}}
Click Add to save your remote field.
Let's create an entry for our ProductPage model. Navigate to Content editor > ProductPage and click + Add entry.
We'll use the following information:
Field
Input
Title
Product 1 with extra data
Slug
product-1
Body
Use the dropdown tos elect Heading 2 and write "This is a headline".
API ID
This is where we will write the API ID of our product. IN this example we'll write "1".
We'll click Save & publish and go to the API Playground to test this.
Let's run the following query:
Query
Response
This query brings all the information we just added in to the content entry that we created, which comes from Hygraph's data, and also includes the productData data, which comes from the API and is associated through the API ID field we added earlier.
Now imagine you also want to add your product reviews here. Federate this has sample reviews that we can use to try this. We'll go back into the schema builder and edit our remote source by adding 3 new custom type definitions.
In our remote source, we'll click on + Add new custom type definition. We'll do this three times, to add the following types:
Review
Reviews
ReviewMeta
Don't forget to click Save at the top-right of your screen to update your remote source.
Next, we're going to add this to our ProductPage model as a REST remote field. To do this, navigate to Schema builder > ProductPage, select the REST field from the right sidebar, and use the following information:
Field
Input
Display name
Product Reviews
API ID
productReviews
Remote source
Third Party APIs is selected by default. Leave it as it is
Method
GET is selected by default. Leave it as it is
Return type
Use the dropdown to select ReviewtMeta
Path
/reviews/product/{{doc.apiId}}
Click Add to save your remote field.
The way we have set this up allows for the product details and the reviews from that product to pull from a single API ID, which we included in the API ID field that we added to our schema earlier and to which we assigned a value in the sample entry we created.
Now we can go back to the API Playground to test this using the following query:
Query
Response
The response now contains the 3 sample reviews that were included in Federate This.
This example shows a product content entry that fetches the product catalogue from a Remote Source.
Besides the data that lives in Hygraph inside a regular model called Product - Product name, product description, etc - you can fetch a product catalogue from an external API through a remote source that you added to the Product model as a Remote Field.
Remote field example
Requests will return information in Hygraph - Product model - as well as information in the Remote Source, called myCatalogue in our Product model for this example.
Query
Response
The frontend could then use this information received through the Hygraph Content API to display the product page enriched with the product catalogue.
This example uses Top-level Remote Fields to show us a product information content entry that fetches the product catalogue from an external API, unretaled to Hygraph.
Besides the data that lives in Hygraph inside a regular model called Product information - Slug, Title, Description - you can fetch a product catalogue from an external API through a Remote Source that you add to the Query model as a Remote Field.
Query model - Top Level Remote Fields example
Requests will return information in Hygraph - Product model- as well as information in the Remote Source, called fieldremoteproduct in our Query model for this example.
Query
Response
The frontend could then use this information received through the Hygraph Content API to display the product page along with a product catalogue sourced from an external API.
This video tutorial covers adding a remote source to Hygraph and creating Top-Level Remote Fields to pull in data from the external e-commerce platform, BigCommerce.