Documentation May 14, 2020
A MetaMate relies on services to read data. Services are IPv4/IPv6-routable network services and expose a subset of the endpoints, that are defined in the abstract type graph.
Every service exposes a LookupService endpoint. This endpoint returns information about the service and the endpoints the service exposes. Every exposed endpoint defines a request filter and a request select.
The request filter specifies criteria a request needs to fulfill to be handled by the service. The most common use case for request filters is to narrow down the accepted request modes. A service may only handle the search and id mode of a GetRequest and passes on all other modes.
Services are build around specific datasources or use-cases. They can be loosely grouped by the following categories.
Discovery services supply a MetaMate with services it can interact with. Every MetaMate comes with a virtual discovery service that returns virtual services, which are deployed in MetaMate’s internal virtual cluster. An instance administrator can deploy environment-specific virtual discovery services to discover external services. MetaMate ships with an embedded kubernetes discovery service, that discovers services in a given kubernetes cluster.
The latter two discovery services return services running in private environments. The same principle can also be applied to a public context, where services can register themselves with public discovery services to be served to any requesting MetaMate.
Gateway services interact with external data providers. They talk to apis, they map mql requests to vendor specific requests and map the response back to the corresponding mql response. Talk to APIs, blockchains, websites, or p2p networks. In a nutshell: everything that’s connected to the internet.