pgmcgee/orbital

Orbital automates integration between data sources (APIs, Databases, Queues and Functions). BFF's, API Composition and ETL pipelines that adapt as your specs change.

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

curl https://start.orbitalhq.com > docker-compose.yml
docker compose up -d

Then visit http://localhost:9022 in your browser.

What is Orbital?

Orbital is a data gateway that automates the integration, transformation and discovery of data from data sources (API’s, databases, message brokers) across your enterprise.

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.

Why Orbital?

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.

How does it work?

Here's the main ideas of Orbital.

0. Define some shared terms

Create a Taxi project:

taxi init

... and create some types...

type MovieId inherits Int
type 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 for OpenAPI, or other examples in Protobuf and Databases)

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

Taxi

Under the hood, Orbital is a TaxiQL query server.

Links

• Taxi
• TaxiQL

Get in touch

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

FAQ's

How does this relate to GraphQL?

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:

Technology agnostic

GraphQL works great when you have GraphQL everywhere. For everything else, you have to maintain a separate shim layer to adapt your RESTful API / Database / Message Queue etc., to GraphQL.

Orbital and Taxi work by embedding metadata in your existing API specs (OpenAPI / Protobuf / Avro / JsonSchema, etc), so that you don't need to change the underlying tech you're using.

Decentralized, spec-first federation

Orbital is built for decentralized teams, so that teams can ship changes independently, without having to build and maintain a separate integration layer.

Resolver-free

Resolvers in GraphQL are integration code that has to be maintained - often by a dedicated GraphQL / middleware team. This means teams that own services have to co-ordinate changes with a separate 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.

Does this mean all my systems have to have the same ID schemes and request/response models?

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

I can't embed tags in my API specs - does that stop me using Orbital?

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)

Doc links

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