Ep. #39, GraphQL Services with Sean Grove of OneGraph

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.

It's 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.

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

Brian: Yeah.

Sean: GraphQL makes it easy to describe the relationships between them, so you can explore that. 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.

Brian: Yeah.

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

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

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

Brian: OK.

Sean: Spotify took less than a day.

Brian: Less than a day?

Sean: Yeah.

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

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

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

We'll still keep them there, we'll stitch them into the new functionality. Existing 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.

Brian: Yeah.

Sean: You go to your blog and you go to slash edit and it loads up some extra JavaScript, and you can make those changes and 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."

Brian: Yeah.

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

If you want you can go to GitHub and you can provision a new API token and you can use that directly, but we also provide a JavaScript library 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.

Sean: Exactly.

Brian: OK. Just hit the button and I'm good to go?

Sean: Exactly.

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 lot of this JavaScript world.

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.

Brian: Yeah.

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

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.

But 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 home page.

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

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 providing?"

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? I have a JavaScript app or a Python app, how do I take this and get 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.

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

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

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?

Sean: Yeah.

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

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 be writing? 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.

Sean: Exactly.

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

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 component?"

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

Brian: Yeah.

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," or whatever.

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

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 around it. 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 GraphQL.

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, it's amazing. Fastly is implementing isolation between processes without containers, using web assembly as the universal IR.

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 want JavaScript developers to realize "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.

You'll 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 great.

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. Everything's remote. 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 realistic, hopefully.

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

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.