Repository files navigation

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.

• Grab thedocker-compose.yml athttps://start.orbitalhq.com/
  • Note that some of Orbital's test features leverage platform-specific docker features.
  • So, either visit the above in a browser and download the file (we'll work out the correct one to serve you), or...
  • curl -H "x-os: ${OS:-${OSTYPE:-$(uname)}}" https://start.orbitalhq.com -o docker-compose.yml will also fetch the right version for your OS
• Thendocker compose up
• Finally visithttp://localhost:9022 in your browser.

# for the impatient...curl  -H"x-os:${OS:-${OSTYPE:-$(uname)}}" https://start.orbitalhq.com -o docker-compose.ymldocker compose up -d

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 poweredTaxi which adds richSemantic Metadata to your exist API specs, that describes how data relates between your data sources.

1. No glue code: Glue code that stitches APIs together is brittle, breaking whenever APIs change.
2. API First: Orbital is powered by your existing API specs, meaning less code to maintain
3. Technology Agnostic: Using gRPC? REST? SOAP? Kafka? Orbital doesn't care. It'll work with what you have
4. 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.

0. Define some shared terms

Create aTaxi project:

taxi init

... and create some types...

type MovieId inherits Inttype MovieTitle inherits String// ... etc...

1. 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 forOpenAPI, or other examples inProtobuf andDatabases)

2. 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

3. Query for data

Some example queries:

// Find all the moviesfind { Movie[] }// Find a specific moviefind { Movie(MovieId == 1)}// Join some other datafind { 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 aTaxiQL query server.

• Taxi
• TaxiQL

• 💬Connect with us on Slack
• ☎️Book a call with the founders
• 🐞Report a bug
• 🙋Ask a question

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 inWhy 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)

• Semantic Integration 101
• Why we built Taxi
• Using Semantic Metadata to automate integration
• Querying for data