Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: OneGraph (YC S18) – Build API Integrations with GraphQL
130 points by sgrove on July 24, 2018 | hide | past | favorite | 38 comments
Hey HN,

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 {
        uploadChannel {
          snippet {
          twitterLinks { # twitter accounts associated with the channel
            twitter(first: 5) {
              tweets {
(You can see the full result of the query https://gist.github.com/sgrove/5f17d046e535763c3c85258054ed0... or play with it yourself https://bit.ly/2NL89GA)

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.

In my experience one of the hardest parts of dealing with APIs is sticking within their rate limits.

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?

Long story short, we give you a way to declare what rate-limiting strategy you want.

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

That's a great answer, thanks. You've clearly thought very hard about this problem.

Congrats on launching !

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.

To follow up on Daniel's answer, here's a demo video showing how powerful link-parsing + link connections are https://www.youtube.com/watch?v=fEo6jsPD524

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

Congrats! I feel like this is a modern approach to fulfilling the unrealized promise of the semantic web.

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.

So your approach to the semantic web is to use a proprietary service to bundle proprietary api's that is queried in a language controlled by a single corporate entity and where the resulting data is pretty much never able to be semantically understood by anyone except the api client that constructed the query? A lot of that sounds like the opposite of what the semantic web was supposed to be.

I agree with some of your points here, but I think you might be missing some context in the technologies that are being used to accomplish what OneGraph is doing.

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

Thank you, this is a really succinct and clear explanation of how I think about it as well.

Right now we only have our hosted version, but we'll offer an on-premise/vpc version of OneGraph down the road, with some auto-integration for existing GraphQL servers as well that'll handle this exact use-case, and should be pretty magical.

Congrats on the launch Sean! Would love to help with that :)

Here's an example OneGraph app that'll extract the captions/subtitles for a given YouTube video and let you search through them, so you can e.g. find when a term is mentioned in a talk - pure React/Apollo app!

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.

This kind of middleware has the potential to be as significant as relational databases.

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

Congrats guys.

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.

Great question, we spend a lot of time on overall latency questions.

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.

Very intriguing. Does OneGraph support mutations? Or is it read-only data?

It would be nice to have fire base support so you could have your own mini database for mutations.

Firebase would be a great integration! Being able to query/store data from it, and jump into any service from it seamlessly - that's the dream.

We'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.

We're adding mutations ad-hoc as customers request them. For example, we have mutations in Stripe for refunding charges.

If the underlying API is GraphQL, like GitHub or Eventil, then we expose all of the mutations that they support.

I just want to chime in with a link to a talk that Daniel gave at this year's GraphQL Europe conference: https://youtu.be/eLSWLtmzdWU?t=3m43s (It links to the OneGraph demo Daniel gave during the talk.)

this is an interesting idea. offhand i would have to weigh the risk of adding a (Smyte-able) middleman api vs the potential benefit of time saved having basic integrations done for me. putting a business hat on i'd say it'd be great to start with onegraph for sideprojects but once these data pipes become serious business it would make sense to invest some time bringing it inhouse. Will be interesting to see if that hypothesis is wrong; I know nothing about this market.

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?

Do you plan to release the endpoint code as on premise? What's your SLA?

For some companies/developers (including myself), using centralized cloud services is a red flag, especially for security and for downtime.

Very cool! I actually considered building something similar myself about a year ago but got pulled into other projects... definitely see a lot of value in providing a single interface.

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?

Congrats on launching! This is really cool. How hard would it be to integrate OneGraph into an existing GraphQL endpoint that I'm already hosting to power my application?

It depends on the backend that powers your GraphQL API, some are much easier than others, but all are doable. Which backend are you using?

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.

I'm using apollo-server-hapi. I've briefly looked into schema stitching before but haven't done that recently. Is that something that you'd recommend doing with OneGraph?

I remember Sean showing this to me earlier this year - it's really cool to see this work in real-time. It's like magic. Congrats on launching!

Congrats for launching! This is very promising.

1. Can you please integrate Auth0?

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?

fyi running the query in https://bit.ly/2NL89GA gives

{ "data": { "youTubeVideo": null } }

right now. did a limit bust?

Oh, no, you just need to authenticate with YouTube to run the query. We need to make that much more clear (should be in a week or so, have some big plans for much nicer errors)

SSaaS (schema-stitching as a service) :D

And Schema-as-a-Service! :D

does 24/MON mean $24/month?


Are you guys using Clojure(Script)?

This seems smart!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact