Skip to main content

Overview

The Universal Data Graph (UDG) lets you combine multiple APIs into one universal interface. With the help of GraphQL you’re able to access multiple APIs with a single query. It’s important to note that you don’t even have to build your own GraphQL server. If you have existing REST APIs all you have to do is configure the UDG. With the Universal Data Graph Tyk becomes your central integration point for all your internal as well as external APIs. In addition to this, the UDG benefits from all existing solutions that already come with your Tyk installation. That is, your Data Graph will be secure from the start and there’s a large array of middleware you can build on to power your Graph. Universal Datagraph Overview Currently supported DataSources:
  • REST
  • GraphQL
  • SOAP (through the REST datasource)
  • Kafka
    To start creating your first Universal Data Graph in Tyk Dashboard, go to “Data Graphs” section of the menu.
Make sure to check some of the resources to help you start:

Key Concepts

Universal Data Graph

The Universal Data Graph (UDG) introduces a few concepts you should fully understand in order to make full use of it. UDG comes with a fully spec compliant GraphQL engine that you don’t have to code, you just have to configure it. For that you have to define your “DataSources” and might want to add “Field Mappings” as well as “Arguments” to your configuration. Read on in the sub sections to understand the full picture to use UDG to its full potential. To help you, we have put together the following video.

DataSources

In most GraphQL implementations you have the concept of Resolvers. Resolvers are functions that take optional parameters and return (resolve) some data. Each resolver is attached to a specific type and field. DataSources are similar in that they are responsible for loading the data for a certain field and type. The difference is that with DataSources you simply configure how the engine should fetch the data whereas with traditional GraphQL frameworks you have to implement the function on your own. DataSources can be internal as well as external. Internal DataSources are APIs that are already managed by Tyk, such as REST or SOAP services configured through the Dashboard. You can take advantage of Tyk’s rich middleware ecosystem to validate and transform requests and responses for these internal DataSources. External DataSources are APIs that you’re not currently managing through Tyk. For simplicity, you can add them to your data graph without first configuring them as dedicated APIs in Tyk. If you later decide to apply middleware or other policies, you can easily transition an external DataSource into a managed internal API. Head over to the connect data source section to learn about the supported data sources and how to connect them to Tyk.

Arguments

Looking back at the example from the “Field Mappings”, you might wonder how to use the “id” argument from the GraphQL query to make the correct REST API call to the user service. Here’s the schema again:
We assume you already have your DataSource attached and now want to configure it so that the path argument gets propagated accordingly. You need to tell the GraphQL engine that when it comes to resolving the field “user”, take the argument with the name “id” and use it in the URL to make the request to the REST API. You do this by using templating syntax to inject it into the URL. This is done from the “Configure data source” tab, which will show after clicking a schema argument or object field. Typing an opening curly brace ( { ) will produce a dropdown that contains all available fields and arguments.
Create New API

Field Mappings

Universal Data Graph can automatically resolve where data source information should go in the GraphQL response as long as the GraphQL schema mirrors the data source response structure. Let’s assume you have a REST API with a user resource like this: http://example.com/users/:id The following is an example response:
If GraphQL schema in UDG is set as the following:
and REST data source at attached behind user(id: Int!) query, UDG will be able to automatically resolve where id and name values should be in UDG response. In this case no field mapping is necessary.