Launch HN: OneGraph (YC S18) – Build API Integrations with GraphQL
We’re Sean and Daniel, founders of OneGraph (https://www.onegraph.com). We're a single GraphQL endpoint that brings together all your SaaS APIs.
We make it easy to build integrations for your app into services like Salesforce, Stripe, GitHub, Clearbit, and Gmail. Since each service’s API is unique you usually have to read their documentation, implement their specific authentication, make very specific calls to their servers, etc.—it seems normal right now, but all of this adds up.
Both of us have done plenty of integrations into these services for different startups over the years, so we knew intimately how painful it can be, especially when you have to coordinate data from multiple services.
Then GraphQL came along, and we saw that it could be a query language for all of the APIs we wanted. We can express our data requirements—even between services—succinctly, and let a single execution engine figure out how to translate those requirements to specific API calls.
We’ve built a GraphQL service that does just that - it knows how to talk to each backend API we support to pull out exactly the data you need. Here’s an example of how it works:
{
youTubeVideo(id: "YX40hbAHx3s") {
snippet {
title
uploadChannel {
snippet {
title
}
twitterLinks { # twitter accounts associated with the channel
twitter(first: 5) {
tweets {
text
}
}
}
}
}
}
}
We charge based on the services you’re integrating with, whether you want white-label authentication for your users, and overall usage. Eventually we’ll offer an on-premise solution for bigger enterprises that need it.
We’d really appreciate your feedback on OneGraph. We have a lot we want to improve on, and would love to hear where you want us to go next.
38 comments
[ 3.1 ms ] story [ 88.6 ms ] threadWe're thinking about different approaches to pulling this off - if it's for a greenfield app, then maybe we control your schema.
If we're integrating with an existing app, we'd probably have to walk your entire schema and try to pull out the normalized data-structures and figure out nullable fields/their types/etc., then allow you to make the final edits that would be enforced when accessing/updating it from OneGraph.
If the underlying API is GraphQL, like GitHub or Eventil, then we expose all of the mutations that they support.
If this works as advertised, this is huge.
When I'm making API calls from my app to different services, I know for a fact that there is no extra latency that might be caused by a third-party. How do you deal with maintaining low-latency while still having to re-route my original API call?
Again, as someone who dealt with many APIs over the years, I think this kind of service is game-changing.
If you're hitting a single API endpoint (imagine getting a tweet without getting the user information), we'll introduce an overall latency of ~100-ms. So this may well be slower, and might not work depending on your use case (though we have plans for working on lowering the overall latency).
But if you hit more than one API endpoint, or especially if you're jumping between API services, we'll deliver a really big win, in part because of declarative nature of of GraphQL. As we descend each node we know that we can execute the subsequent API requests concurrently, so this usually ends up being an automatic win.
And if you're doing something like joining against Salesforce data, we can automatically switch the query to use the SOQL/batch API, which can be both faster and significantly cheaper, all without changing the implementation on your side.
Two questions:
1) In the example you show above, how are you figuring out which twitter accounts are linked to the channel ?
2) API integration is a one-time effort and largely done using libraries. Do you have a real world use case example ? My sense is most calls are isolated - for example I want to read my last few trasactions from Stripe or get last few tickets from Zendesk. Would it make sense to go through an intermediary like you and pay another monthly fee ?
For 1), we're parsing links the creator added on the about page of their YouTube channel.
For 2), a great example is https://heysavvy.com/, a company building omni-search across all your SaaS apps. Before OneGraph, they invested a lot of time learning the idiosyncrasies of the underlying API for each new integration they added. Now, they just open up the Explorer in GraphiQL and find exactly the fields they need without needing to look at documentation or install any new packages.
Hopefully it's also a bit of an answer to #2, showing how easy it is to explore and iterate an API, even without a library, so that should help speed up the initial one-time effort, and then we handle things like rate-limiting, inter-service dependency, and per-service optimization (like automatically switching between Salesforce's REST api and their Batch API, both of which have radically different implementations that would require an entire re-arch if you build on them directly).
I would expect concurrent API requests made via GraphQL to make this worse - since it's very easy to accidentally construct a GraphQL query which results in a flurry of API requests under the hood.
How are you handling this? Are you doing your own internal rate-limiting, or are modern APIs more generous with their limits than they used to be?
- You can tell us to immediately fail the whole query right away, - Fail just that sub-part of the query - Back off for that API and try again (delaying your overall query but now you don't have to deal with the failure/rate limit case at all) - Potentially do this for all requests across your app, queuing up the api requests to the service that's rate-limited so that you don't have to worry about reasoning locally/globally about rate-limits.
We've found this is the level that developer usually feel comfortable thinking about the trade-offs, rather than in the nitty-gritty implementation steps.
I've worked with a bunch of big companies and they have dozens or often hundreds of individual APIs and micro-services. Would it be feasible to deploy OneGraph in a closed environment like that? I can't think of a big IT department who wouldn't want to interconnect their internal services like that.
I agree that this example is that of a proprietary API bundling other proprietary APIs, but the technologies they are (likely) using are open source and make it possibly to build self-documenting (via GraphQL introspection) APIs with visualization [1] that can be combined in a modular fashion [2].
If every API was a GraphQL API, there’s no reason you couldn’t easily create a facade that links university course curriculums to, say, associated Wikipedia articles.
Not the semantic web, but it can be a very powerful way to combine data.
[1] https://apis.guru/graphql-voyager/
[2] https://www.apollographql.com/docs/graphql-tools/schema-stit...
Source to it is on GitHub: https://github.com/OneGraph/youtube-captions-helper
Try it out here: https://onegraph.github.io/youtube-captions-helper/
It might be fun to build a site that has transcripts for tech talks and use this to 1. bootstrap the transcript and 2. search across all talks for a term and be able to jump into the video exactly when the term is mentioned.
We have already done a lot of the groundwork, embedding other GraphQL APIs like GitHub's into OneGraph. We're careful to namespace all of the types so that there will be no collisions.
For some companies/developers (including myself), using centralized cloud services is a red flag, especially for security and for downtime.
{ "data": { "youTubeVideo": null } }
right now. did a limit bust?
as a former product manager i could see an internal-facing product here pulling up analytics for nontechnical employees; PMs, marketers, even customer success/support. any interest in pursuing that kind of customer?
Did you ever use one of those "xml data mapping" tools in your integrations?
If so, how would you compare their strengths and weaknesses with your solution?
This comparison could be compelling for enterprise customers (though your early customers will be the less risk-averse, more technical startups/small companies).
2. Can OneGraph Authentication be used for user and session management instead of Auth0?
3. RE: pricing, is it $24/mo for 5K/mo is ~ 1 request every 20 minutes. The next tier is about 1 request per second on average. So I guess your Individual plan is for evaluation and side-projects?
How are you planning to handle the explosion in complexity? Once you have hundreds/thousands of different services integrated, the schema becomes rather huge, especially if a specific user only needs a fraction of it. Is the plan to toggle services on/off and then only stitch the schema for a particular user with the limited set of fields?