September 21, 2017
B2B SaaS & Dev Co Investment Panel w/ Bessemer, Redpoint, and Andreessen Horowitz
Heavybit Managing Director Tom Drummond moderates a panel featuring venture capitalists Ethan Kurzweil of Bessemer, Scott Raney of Redpoint,...
In episode 39 of JAMstack Radio, Brian is joined by Sean Grove of OneGraph to unpack common misconceptions about GraphQL, and discuss some of the peripheral services and tools available to educate and inspire GraphQL users.
About the Guests
Brian Douglas: Welcome to another installment of JAMstack Radio. In the house we've got Sean Grove from OneGraph. Hey, Sean.
Sean Grove: Hey, thank you for having me.
Brian: We'd met-- Maybe you reached out to me through Twitter, maybe? Possibly?
Sean: A mutual friend introduced us.
Brian: OK, awesome. You're
doing OneGraph stuff, so you do you want to tell the audience what OneGraph is
and what you're working on?
Sean: Sure. The idea is pretty simple.
It's schema stitching as a service, in a way.
a single GraphQL API end points, through which you can reach in and pull out
data from Spotify, Stripe GitHub Salesforce
and connect data between all of them.
With one query, you can pull out all the data your application needs in a fun way.
Brian: Excellent. Is this a GraphQL company, or why GraphQL?
Sean: GraphQL has a lot of different
benefits. Some of them are-- One, that you can finally
represent the connections between all of these different data sources.
That's a big one.
your Salesforce data has some connection over to Zendesk,
and GitHub might have some connection to NPM.
These are separate APIs usually, and in a REST structure it's hard to represent those connections between them without cramming all of them at the same time.
Sean: GraphQL makes it easy to describe the relationships between them, so you can
The other big one that is near and dear to my heart is that
GraphQL is introspectable.
That means the tooling that you can build around it is phenomenal. It's very different.
Brian: Yeah. You mentioned schema stitching, which I'm not sure we
particularly talk about that on the podcast.
But you explained it really well and eloquently.
Are you legitimately using schema stitching on the back end to connect all these other APIs in the quote unquote OneGraph? Or, how does that work?
Sean: Sure. Most of these services that we provide through OneGraph don't have a GraphQL API.
Sean: Spotify has a really well documented and nice API, but it is a REST API. The tooling and the experience with it is limited in many ways.
We have built a lot of tools internally to make it easy to build a GraphQL API on top of these REST APIs.
Then in addition to that we make it so that we can add connections between Spotify and Wikipedia, or something like that.
Brian: OK. Am I going to you for the APIs, or do I bring the REST API to you and it makes it GraphQL?
Sean: Right now we don't have any crowdsourcing mechanism, so everything is span>
We pick an API, we figure out how to approach it.
There are a lot of lessons to be learned in how to
take a REST API and make it idiomatic and
joyous to use inside of GraphQL.
want to make sure that we have a lot of automated tooling that
makes sure that whenever we bring in a new API, that it looks
every other API.
should be normalized, authentication should be normalized, field names should be
normalized, all the stuff you would expect.
Once we have a lot of that infrastructure laid down, the goal is to make it so that
other people can bring in descriptions of their APIs.
With a swagger file or Open API, or their own mechanism, and say "I want to add this to the OneGraph. I want to be able to join against this API, take advantage of all that tooling, along with all the other APIs that are inside of the OneGraph."
Brian: Yeah. After today, if I wanted to leverage the bar API through OneGraph, there's no way for me to submit that to OneGraph to be able to use?
Sean: You would be able to email us, and within about two or three days we'd have it out for you.
Sean: Spotify took less than a day.
Brian: Less than a day?
Brian: OK. So you're just taking ad hoc community recommendations through email?
Sean: We're very horizontally driven right now, where we work with our users
and whenever they want to add something we go and we figure out how to add
Each time we take a look at our tooling,
"How well did that work?
What did we learn from it?"
We improve that tooling to the point where eventually we'll be able to open source this and anyone else will be able to do it as well.
Brian: Since you're providing a majority of these APIs within OneGraph or REST APIs that have been quote unquote converted to GraphQL, is there anything that the users are missing out on for not having a true pure GraphQL experience? Or does that matter at this point?
Sean: No, I don't think so. We do a lot of things that are incredibly optimized, so because we have a deep understanding of how each of these APIs work we can apply a lot of optimizations to them.
The Trello API is interesting
where it allows you to batch together different requests.
If you were to take a naive GraphQL wrapper or if they were to
implement their own naive GraphQL API, it would be--
could make one request on our side, and it would turn
into 1,500 API requests.
But we're able to reduce that to 5 through some optimizations that we're able to
run. So, it's not too bad.
In fact even GitHub is interesting.
GitHub has a native GraphQL API and it's really well done.
However, it is missing some features from GitHub's
REST API, and we are the only GraphQL API
through which you can create a repository on GitHub.
We stitched together the GitHub REST API into the GraphQL API so you have more complete access to all of the GitHub functionality.
Brian: Interesting. You're filling in the holes. At GitHub, they're still working on it?
Sean: Yeah. The idea is that GitHub is
methodical about how they roll these things out.
I have deep respect for them.
At some point they're definitely going to figure out how to
bring that functionality in, and what we'll do at that point is deprecate our
We'll still keep them there, we'll stitch them into the new
users will keep working, but in the meantime it means that there is a way to
access all this functionality.
The other important thing is that we support serverless access, or being able to hit all these APIs directly from the browser.
Being able to make a commit into a GitHub repository directly from your browser is magical.
It is really interesting the kinds of tools-- You could imagine, building a log editor. Maybe Jekyll, or something.
Sean: You go to your blog and you go to slash edit and it
preview them in the browser.
Whenever you're happy, click a button and make that mutation
through the OneGraph GraphQL API for GitHub.
That'll create a PR, or automatically emerge it, and that'll kick off a Netlify new build so you can edit your blog without any server involved whatsoever. It's a cool feeling.
Brian: That's pretty powerful. Also, it sounds like OneGraph is a business and it's a product that you're working on. Are there customers, or who are you focusing on to get the word out?
Sean: Sure. Our initial use
case, we went after a lot of young
startups and particularly ones who were looking for a serverless way to
access all this data.
We found a lot of front end developers resonated because there's
so much interesting data in Salesforce, or
Spotify, or Trello, or Twilio.
But the thing is learning those APIs and standing up a server,
understanding rate limiting, authentication and all that stuff.
It's a big burden.
What that does is it raises the bar for "How
much investment do you have to put in to build something interesting?"
Our thought was "If we can lower that bar so it becomes trivial and you can click around and build something cool, you'd see a lot more front end developers build cool things."
Sean: That was our first set of users that resonated with us. There has been another set of back end developers, in particular there's this omni CRM space where a lot of times a product is pulling together data-- Again, from Gmail, Google Calendar and Salesforce.
Being able to do that on the back end efficiently without learning all those APIs, we were surprised to see how much back end developers also like it as well.
Brian: Yeah. When you say, "Lowered the bar," am I just providing you my keys to these APIs, and then I have access to it through OneGraph?
Sean: You can do it either way. Authentication
is one of the bugbears of building these
If you want you can go
to GitHub and you can provision a new API token and you can use that
that is one line, where you say "One off .login
GitHub, or Spotify, whatever."
We handle that whole round trip. We embed all of that logic, and then you get a token and you can make these queries and authentication is taken care of for you.
Brian: As a user, I don't have to actually find out where my tokens live.
Brian: OK. Just hit the button and I'm good to go?
Brian: Interesting. I'm curious about-- You seem to be,
OneGraph is in the middle of all these other situations
of GraphQL and you're seeing a lot of first hand experience of people using it.
What is GraphQL missing at this point?
You mentioned tooling as well, I know there's a lot of companies who are
now coming up.
Hasura is handling all this Postgres
handling, we got Prisma and Apollo handing a
What are the open range for people who want to use GraphQL, but is there missing opportunity out there?
Sean: Yeah. You can split it in a couple of different ways.
There are forms of
schema stitching that are going to be incredibly powerful.
One that we've been looking at is if we were to take your database tables and you have a table of users, maybe one of them has a Stripe customer ID field.
Sean: We could detect that and say, "Do you want us to just add a Stripe customer note
here?" You could just query into this Hasura or
Postgres file end point and pull out all of the data
on your user, but also join right there into Stripe and pull out
all the Stripe information.
Same with Salesforce or Zendesk, it's a
deeper level of schema stitching that's going to be really powerful
in the future.
GraphQL is young, and what we find is that a lot of people who are excited about GraphQL don't realize how young it is. There's this assumption that everyone knows what it is and how great it is.
People sign up for
OneGraph oftentimes what they're looking for is easy access to the data, and they
heard that OneGraph is a way to get easy access to this data.
They think that GraphQL is our proprietary language, they've
never seen it before.
It's a big hill for them to
climb, so we deal with people who have never heard of
GraphQL and we
want to make it as easy as possible
every step along the way.
There's a lot of great workshops and a lot of documentation,
but the tooling isn't great for newcomers
in many ways.
We've worked hard to mate with Graphical,
which is a great open source
IDE by Facebook. It allows you to write nice GraphQL
queries and experiment with a GraphQL server.
The thing is it's
textual and it requires that you understand
GraphQL syntax and for a lot of our users that's pretty
terrifying. We made it so that we realized that
GraphQL was so introspectible, and the tooling that you can build are so
We made it so it's exploring a file system
where you simply have a list of all your files of Stripe and GitHub
and whatnot, and you just check it and it opens up and shows you the sub folders.
For GitHub you'd check it and it's like, "User," or "Repositories," or whatnot.
I can now say "All right. I
want GitHub and I want a user with this user name.
I want the repositories, and for each repository I want the name."
You see people click through and build up a GraphQL query. They are able to express clearly the data they want, and get that out, and it's exciting for them.
There is a ton of low hanging fruit in
that area of building out great
joyous experiences in the beginning for a lot of GraphQL
users. There's a lot of stuff also on the backend, in
terms of analytics and network
layer stuff for GraphQL that would be cool.
Then some PHD research level stuff that could be cool. I'm happy to talk about any of those.
Brian: Yeah. I'm all ears, all interested.
Because you seem to have a lot of experience, and my experience
primarily is the GitHub GraphQL API.
That's been the majority of my day to day, as far as interacting with
GraphQL, at least in the last year.
before we get into that, I had a question, because you mentioned about GraphQL being new.
I'm curious-- I'm looking at your site and GraphQL is only mentioned once on the
Is that intentional? Are you looking to abstract the idea of GraphQL to make it less daunting for people to approach OneGraph?
Sean: Yeah. Because GraphQL is new, we don't talk about
GraphQL to our users upfront unless
it's a developer endpoint that you're hitting.
If you're a developer, we'll be explicit, "This is a GraphQL
We're not looking to offer a REST endpoint
or anything like that with this, but the point is we first want
to get you sold on "What is the value we're
We're providing easy access to the state of GraphQL as an implementation detail after that. If we lead with GraphQL it's intimidating for a lot of new users.
Brian: Yeah. Because in the context switching and maybe they go into a rabbit hole of trying to figure out where this thing came from.
Sean: Exactly. Along those lines,
we see it as-- If you imagine a funnel from left to
right, people come to our site and they sign up and then
we put them in Graphical.
The first thing they were hit with was this blank canvas where they had to type
in GraphQL, which we mentioned before.
The explorer, with that filesystem approach, that was an attempt to
help ease the gap between not knowing anything, and running your
first GraphQL query, and being able to explorer
physically and almost tangibly.
Like, touch these things.
What we find now is people get pretty excited as they get through, because they're able
to pull out the data directly inside of Graphical, but now there's a
big challenge where it's like "Alright.
I built up my query, and I see this is the data I want.
How do I get this into a useful context?
How do I get this into my app?
it in there?"
To that end we've worked on another open source tool that we'll
be releasing pretty soon, which is a code exporter.
This is meant to be customized much more than the other tools that we've released
so far, but the idea is we can introspect your
query and say "Look, we can generate all of the
nice React Apollo components or Fetch."
In one case we can say "I want to Curl, Bash program." It's cool because you say, OneGraph offers RSS via GraphQL. You're like, "For RSS I take a podcast feed and I want to get the title and the items and the title of each episode." Then you can take that and generate a bash file that you can use on the command line, with no external dependencies.
Because right now another problem is that people tend to think that GraphQL is only for use on the front end. But it's this abstract thing, and as long as you can make an HTTP request you can use it anywhere.
It's cool to be able to interact with these sophisticated APIs even from Curl. The goal here is to make it so that you can take this query that you've built up, that you've been happy with and you're excited, and move it somewhere in a copy and paste manner and be productive. Just keeping that flow through the funnel as smooth as possible.
Brian: Yeah. Are you translating that GraphQL query into something like a REST as well, so they can-- For people to wrap their brain around? Or is that too--?
Sean: We don't do anything like that. We bet pretty heavily on GraphQL. It is young in the industry, and the idea is there's going to take time for this to grow out. We're OK with that. We've positioned ourselves to grow and educate our users along the way.
Brian: As far as education goes, what ways are you educating your users, or even new users in GraphQL?
Sean: Yeah. The tooling that we released--this explorer, the
code exporter and what not, that's meant to keep you
going through your GraphQL experience at a high
pace to avoid all of the pitfalls that you might otherwise have.
We work pretty closely with a lot of workshop and
educational material providers, so that we figure out "What
are the roadblocks that their students hit during this?"
We try to figure out tools that we can build that help them teach
their students GraphQL faster.
GraphQL is really exciting. The idea is if we can get more people excited about it and show it to them in a way that they understand, you're going to see a lot more usage of it in the long term.
Brian: OK. You guys did this as part of the content, not really doing any training or showing up at companies or anything like that?
Sean: We don't do that as a company.
One thing I do personally, is we started a meetup here
in San Francisco that's a dojo style. The
goal here is to have ideally no
talks, or maybe lightning talk at the most.
we want to have is people building things with GraphQL and trying
it and learning there, and the dojo style
is where everyone comes to meet up.
We split off anyone who has experience with them on one side, and everyone else we
number off into teams of about three.
We then take that group of experienced people and make sure that there's at least one of
them on each team.
From then on, everyone works on the same
project, and the idea is there's only one
person programming on each team and that's the person with the least
It sounds intimidating at first, but what
happens is they get experience in their editor and on their
computer typing and using GraphQL.
Whenever they leave they'll have a working project, and
everyone else is trying to figure out how to architect a solution or how
to model it.
It takes a lot of pressure off of the person with the least experience
and gives them a lot of practice, and at the end of the night what
we do is everyone demos what they built and they show
how they built it.
They go over the code.
The nice thing is if we're on
different teams and you're presenting, because we're solving the same
problem I can look at your solution and understand the
tradeoffs more deeply.
Much more nuanced and be like, "Brian solved it in this way.
That has these tradeoffs, that's really
Then we asked the teams "What did you
like? What did you dislike?
Were you blocked on anything?"
Then we tried to take that, what you disliked and what you were blocked on,
and feed that back into either the tooling or into the documentation.
The goal here is this is a personal thing that we do, it's not a company thing, but get people to actually have experience and leave and be excited about it on their own.
Brian: OK. The name of that meetup is--?
Sean: That's the Golden Gate GraphQL Meet Up.
Brian: OK cool. I don't think I've seen a come through in my feed. That's on Meetup.com?
Brian: OK, I'll definitely check it out in the future.
I liked, aside from the GraphQL talk, I like the structure of that
meetup. I'm from Florida, and we had a dojo style
meetup where we'd do coder dojo, where we did learn Ruby
problems and write tests.
So it was test driven development to solve, and it was a way to force
everybody to learn the basics of Ruby as well as testing. Because
six years ago testing was still-- It was a thing,
but a lot of the boot camps were only just starting to
Actually, the boot camps are just now getting around. It was a good opportunity for everybody to walk away learning, but we didn't have a clear structure to sound--
Sean: I really like the idea for test driven development because when I first got
into it I was really struggling with "What are the tests that I should
How does this work?" It would have
been great to have actually been in a group with someone who--
Because the nice thing with having one experienced person on the team is anytime you bump up into something you're struggling with, they can just unblock you.
They'd be like-- Rather than you spending two days bumping your head against the wall trying to figure it out, this person can take five minutes and say "This is the problem. This is why it's a problem. You can do this, don't do this, and now you move on." You can keep that momentum up and it makes it much more joyous.
Brian: Yeah. A good strategy to live by is asking for help earlier than later.
Surround yourself with experienced good people who know the domain. It's great.
Brian: OK. Excellent. Anything else about OneGraph that we didn't cover, or GraphQL in general?
Sean: I'll maybe drop a few ideas that are
inspirational, but one is
it's possible to subsume
GraphQL in a way that people shouldn't be writing--
people shouldn't potentially not be writing
There is a few people,
Cristiano Calcagno at Facebook is the one who
came up with this idea for me, but the idea is if you could take
TypeScript and you have a function and we know
that this is some type, it's a GraphQL query.
What I'm going to do is, it gets passed in and I'm going to say "This
query.user, the query.user.name, or
whatever." And what I do is by having
autocomplete and the fields I use, you can
tell "What is the GraphQL query that should be generated for this exact
It's like, "Maybe we don't have to have GraphQL as a thing that we write, it's just the mechanism by which tools communicate."
Sean: That one is a little bit of a research problem, but it's incredibly exciting
because it also translates to lots of other tools.
You can imagine an IDE tool
where I'm building maybe a React native app.
Draft Bit is a great example of this, where they're building a
React native IDE and I'm dragging in a component.
What I want is to be able to say "I have a GraphQL server,
and I have this text box right here, and what I want is this text box to
be the GraphQL server "Me.email,"
That can be a nice autocomplete, or that file system metaphor.
The thing is you're saying physically tangibly "This is the data I want," and then the GraphQL can be generated and hyper optimized for that exact thing behind the scenes.
So people won't even know-- Even things like Haiku, animation tools where you have designers who can express the data they want without even knowing or caring that GraphQL is powering under the hood. There's a lot of exciting potential things for GraphQL around that.
Brian: So then you're-- I know you've been in the GraphQL space for a couple of years, GraphQL has been around for a couple of years. What is your sentiment on the community and the spec itself, and where it's going?
Sean: The GraphQL Foundation is an encouraging move.
In many ways, Facebook-- They have
chosen a deliberate set of tradeoffs and they have this
monolith, they have
different engineering takes from the rest of the world.
GraphQL came out of that and that's great, but
it doesn't necessarily always reflect how everyone else wants to use it.
Moving it out of Facebook and into an area where
it can transform more based off of communities is going to
Seeing some actual companies that are GraphQL first and growing up around that ecosystem is also going to be exciting.
Brian: What companies are those?
Sean: Apollo, is one that's pushing end rates.
Things like Postgraphile, Hasura, things
like those. The Guild has done a lot of different open source work
There's a lot of exciting things that we're still
very early, but a secular shift from
SOAP to REST, that took a decade. That
took a long time.
GraphQL has been around since 2015, roughly.
Early 2015 is maybe when the first ideas were out there.
It's going to take a long time for
actual migration over to GraphQL.
If you look on Google Trends and you can see if you plot
SOAP and REST and
The lines are exactly what you would expect.
SOAP is big 10 years ago and down into the right,
REST is up into the right and is huge, and GraphQL is this tiny little
blip that started out recently.
The curve is great, it's spiking, but it's going to be a long time before that surpasses REST.
Brian: Excellent. Sean, I appreciate you coming on and talking about OneGraph.
If you don't mind, I'm going to transition back to the picks.
These are anything you're jamming on, music related or tech related.
We've had fish cutting as well, as an
example. I go to that example all the time because it's
completely off the wall.
So, if you don't mind, I see you're pretty prepared. Do you want to just go ahead and jump in with yours?
Sean: Sure. My Saturdays are generally spent no tech and no outside work, and disconnecting.
One thing I've been enjoying is watching the Poirot Series Agatha
Christie, and more recently Star Trek: The Next Generation, which I watched as a
child but I haven't watched as an adult. I was a little bit worried it wouldn't hold up, but I quite like it.
On the tech side maybe one of the things I'm most excited
about recently is in particular the Rust Tool Chain and WebA
ssembly. There are so many interesting opportunities
for, in particular, library authors.
The stuff that's happening with WebAssembly in the browser and outside,
Fastly is implementing
isolation between processes without containers, using
web assembly as the universal
The other thing about Rust is it's a systems level
language, but it is inspired by ELM in terms
of great error messages.
The developer tooling is so polished.
The cool thing is they're inclusive in this way where they
"You are also a systems level developer, you could be.
You have been artificially kept out of it for now."
So they have a tutorial anyone can go through on the
Rust WebAssembly thing, where within 30 minutes
you will have written the game of life in Rust, you will have compiled
it down into WebAssembly.
use the tool chain to automatically generate an NPM
package with beautiful typescript bindings that are
typesif all the way through.
What happens is you write everything in Rust, and then you go in your typescript editor and you get auto completes and enums and it's time saving, and it's beautiful. I really recommend that people go and check out the Rust and WebAssembly Handbook.
Brian: Excellent. I'm going to check that out. I was not even aware that they've moved on that far. So WebAssembly, Mozilla has been using it for the Firefox browser as well as Rust, but I've only been a spectator up until this point so I'd love to check that out.
Sean: As a warning, it is more work and you will be frustrated in the beginning, but it's one of those things where if you bang your head against the wall--
It's like you're banging your head against the wall at a slight angle, so every time you do it you make a little bit of progress, and it's quite nice.
Brian: Excellent. I've got some picks, I just came back from Tokyo. I
spoke at DevRelCon Tokyo.
Feel free to watch that talk, it was OK, but the city was
I had a lot of opportunity to take the train system which works
very well. I got lost in Tokyo Central Station, which is my
main pick, which if you want to get shopping done before you
had to catch an airplane just walk around there.
I went to the Pokemon store, they have every single Pokemon. My son's a Pokemon Master, he's specializing in fire type, so I got him a Pokemon as well.
Sean: That's cool.
Brian: I got him Pokemon, got a bunch of
Japanese stuff, got some anime stuff for my wife.
Tokyo Central Station, if you have a time crunch and need to do a lot of
shopping, check it out.
Also I want to mention green screens. I've been doing this thing since I worked
at-- Basically since I joined GitHub as an employee.
I have a green screen behind me in my office, and
people always get a good kick out of it.
I'll be in interviews and I'll just have a different office in the
background. Up until last week I was-- My office was my
garage, so it wasn't pleasing to have as a background.
So I had a green screen of super nice coffee shops and backgrounds, and it would go 15 minutes in the meeting and people would be like, "Where are you?" Or my co-workers would be like, "How are you in the office right now? Where are you?" And I'd just be like, "That was a green screen."
Sean: Where do you get the green screen, and where do you get the video footage of the coffee shop?
Brian: Yeah. I went to Unsplash, stock
images of coffee shops.
There's not an actual video, I haven't tried video yet because I wanted to make it
In video you can see the edges.
The green screen I got from Amazon, just picked up a cheap green
screen. Zoom has a feature
built in if you're a paid user, you can do visual backgrounds.
Check it out.
I'll hopefully get a blog post written up about this, I'm going to ship it
internally to share with my co-workers first.
But if you have a bad office or a bad setup
that doesn't look aesthetic. Get a green screen.
You'll love yourself, and your co-workers will love you as well.
My final pick is I have a new podcast, it's called Hallway Track.
The Hallway Track, it's a podcast.
Hallway Track online. Check it out if you want to hear me in a different
situation and environment.
I go to conferences and grab speakers and corner them and ask them a couple of questions. It's what we normally do already, we just meet new people in the hallway, so me and my co-worker decided to go ahead and record this and see how --
Sean: Do you want to mention what the hallway track is? It's one of my favorite things about conferences.
Brian: Yeah, "Hallway track." I
don't know if it's-- I'm not sure if it's a well-known term, but anyway, you go to a
conference and majority of the talks are recorded.
You can watch them after the fact and it's either hit or miss.
Especially the single track conferences, whether you get stuck in a good talk
or a bad talk.
Regardless I end up sitting in the hallway and meeting new
people, and a lot of the guests I've had on this podcast have been from the hallway track
Not the podcast, but in general, just meeting people at conferences in the hallway. It's another track at the conference that you stand around and have cool conversations. Definitely check it out. Sean, again, thanks for talking about GraphQL and OneGraph.
Sean: Thank you so much for having me.
Brian: Listeners, keep spreading the jam.