dwwoelfel commented 3 years ago

We’re Sean and Daniel, founders of OneGraph (https://www.onegraph.com). We wrap existing public APIs in GraphQL to make building integrations much faster.

At different startups over the years, both of us had to integrate our products into dozens of others services, like GitHub, Salesforce, Stripe, Marketo, Clearbit, etc. By their nature, each integration was a unique snowflake, where we had to:

Read their docs
- The docs are often under-specified, and sometimes just incorrect. A fun example is Twitter’s timeline api example - They omit a complete list of fields, their types, description, and nullability, and their example JSON doesn’t even parse if you copy/paste it into the console!
Figure out how they structure their API
Figure out how they handle authentication (query params, headers, body?)
Handle their specific OAuth flow

But that was the status quo, we knew it was painful, but we’d suck it up and just do it. What was the alternative, anyway?

Then GraphQL came along, “a query language for your API”

GraphQL gives us a way to access all of these APIs in a uniform way, with great tooling, and really fast. We can just specify what data we want from the APIs, and have the execution engine figure out how to handle the API-specific interactions, and deal with things like rate limiting and flakey services.

One other thing we realized along the way is that there is no explicit graph connecting the world’s data. We have a graph for documents (WWW), and for people (Facebook/LinkedIn/etc.), but the connections between Hacker News, GitHub, Twitter, and Salesforce are all implicit. When you make a call to Stripe to get a customer’s data, and from that data pull out the Intercom user id, and then make a call to intercom, you are imperatively traversing the graph.

Again, GraphQL solves this case for us by letting us specify connections inline, so we can query and join across all of these services in a single, declarative query.

{
  ## Retrieve a YouTube video by its id
  youTubeVideo(id: "YX40hbAHx3s") {
    snippet {
      # Pull out the title
      title
      # Jump to the channel the video was uploaded to
      uploadChannel {
        snippet {
          # Get the title of the channel
          title
        }
        # Find all of the Twitter accounts associated with the YouTube channel
        twitterLinks {
          # Retrieve the first 5 tweets for each account
          twitter(first: 5) {
            tweets {
              # For each tweet, pull out the text body
              text
            }
          }
        }
      }
    }
  }
}

(You can see the full result of the query or play with it yourself)

Finally, while we don’t attempt to normalize the data model at all (a GitHub user is different from a Twitter user, and we don’t try to create a “super user” type), we do normalize the interface by which you get the data, so we can build really useful tools like the GraphiQL Explorer - you can literally click your way through to a working API query!

As a fun aside, the backend is built in ReasonML with some code generation built in Clojure, which has been useful for keeping the structure of the graph as the number of services we’ve supported has grown. We’ll also open source the GraphiQL explorer soon, which is written in Reason and Bucklescript.

We initially thought OneGraph would be useful for back-end developers doing integrations into their product, but we’ve found we have a pretty even split between people using us on the backend, and people using us purely from the frontend with no server. It’s pretty cool to see frontend developers able to access services that would have been too much work to interact with before.

Some customer cases that rely on OneGraph today:

A fire-tracking drone company uses us to control YouTube live streaming + get the elevation data along the route to a fire
Customers embed us in their dashboard, one is pulling out all of the Zendesk activity related to a customer for their support team
A company building omni-search across all your SaaS apps (e.g. Google Docs, Zendesk, Salesforce, Gmail, etc.), sped up both implementing their integrations and their overall performance drastically
OneProfile is an open-source demo app we’ve been working on that’s a bit like Rapportive-anywhere, letting you look up a user by their twitter/hn/github/etc. handle, and find all of their related content

We’d love your feedback on OneGraph:

Try to use OneGraph? What did you like? What are the pain points?
What integrations that would improve your product today are you holding off on because the API is too much work? We should support these
Where do you see a smart GraphQL service helping you the most in your architecture? We want to make these use cases easier

{"source":"blog","publishedDate":1531897200000,"url":"https://www.onegraph.com/blog/2018/07/18/OneGraph.html"}