Website • Docs • Blog Get in touch
Orbital automates integration between your data sources.
It's decentralized by nature - there's no central mapping code defined. Instead, Orbital is powered by the API specs you're already building.
Orbital creates integration on-the-fly, without engineers having to write glue code.
Get started right now, by spinning up Orbital on your machine
docker run -p 9022:9022 orbitalhq/orbitalThen visit http://localhost:9022 in your browser.
Orbital is a data gateway that automates the orchestration, integration and transformation of data and services (API’s, databases, message brokers) across your enterprise. Powered by your API specs enriched with Semantic Metadata, Orbital removes the need for glue code, and self adapts as your services evolve.
Think of it as data federation (a single API for all your sources), without having to shift to GraphQL.
Orbital integrates on-the-fly, automatically adjusting as your data sources change.
This is powered Taxi which adds rich Semantic Metadata to your exist API specs, that describes how data relates between your data sources.
- No glue code: Glue code that stitches APIs together is brittle, breaking whenever APIs change.
- API First: Orbital is powered by your existing API specs, meaning less code to maintain
- Technology Agnostic: Using gRPC? REST? SOAP? Kafka? Orbital doesn't care. It'll work with what you have
- Automatically Adapts: As your API specs change, Orbital automatically adapts it's integration flows, so consumers stay unaffected.
Here's the main ideas of Orbital.
- Define some shared terms
Create a Taxi project:
taxi init... and create some types...
type MovieId inherits Int
type MovieTitle inherits String
// ... etc...
- Add metadata into your APIs
# An extract of an OpenAPI spec:
components:
schemas:
Reviews:
properties:
id:
type: string
+ # Embed semantic type metadata directly in OpenAPI
+ x-taxi-type:
+ name: MovieId
(See the full docs for OpenAPI, or other examples in Protobuf and Databases)
- Publish your API specs to Orbital
Tell Orbital about your API. There's a few ways to do this.
- Get Orbital to poll your OpenAPI spec
- Read from a Git repository
- Get your app to push directly to Orbital
- Query for data
Some example queries:
// Find all the movies
find { Movie[] }
// Find a specific movie
find { Movie(MovieId == 1)}
// Join some other data
find { Movie[] } as {
title: MovieTitle
// Compose together APIs:
// Where can I watch this?
// This data comes from another REST API
streamingServiceName: ServiceName
price: PricePerMonth
// Reviews - is the film any good?
// This data comes from a third API
reviewScore: ReviewScore
reviewText: ReviewText
}
Orbital builds the integration for each query, and composes the APIs on demand.
Because it's powered by API specs:
- There's no resolvers to maintain
- Changes to API specs are automatically main
Under the hood, Orbital is a TaxiQL query server.
Orbital gives you many of the benefits of GraphQL (API federation, custom response schemas), without having to move your tech stack over to GraphQl - instead working with your existing tech stack(s).
The key differences are:
GraphQL works great when you have GraphQL everywhere. For everything else, you have to maintain a seperate shim layer to adapt your RESTful API / Database / Message Queue etc., to GraphQL.
Orbital and Taxi work by embedding metatdata in your existing API specs (OpenAPI / Protobuf / Avro / JsonSchema, etc), so that you don't need to change the underlying tech you're using.
Orbital is built for decentralized teams, so that teams can ship changes independently, without having to build and maintain a seperate integration layer.
Resolvers in GraphQL are integration code that has to be maintated - often by a dedicated GraphQL / middleware team. This means teams that own services have to co-ordinate changes with a seperate integration team.
Instead, Orbital uses Taxi metadata embedded in API specs to define how data relates semantically. From here, most integration can be created automatically.
Nope. Taxi is designed to encourage teams to evolve independently, without sharing common models. Instead, semantic scalars are used to compose models together automatically.
We talk more about that in Why we built Taxi
Nope. There's plenty of options if you can't edit API specs directly (or don't have them) - such as working with a clone of the spec, or implementing the spec from scratch in Taxi (it's really quick)