Ep. #130, Faster GraphQL APIs with Jamie Barton of Grafbase

Brian Douglas: Welcome to another installment of Jamstack Radio, on the line we've got Jamie Barton from Grafbase. Jamie, you want to say hello?

Jamie Barton: Hey, everyone. How's it going?

Brian: I can speak for everyone, everyone is peachy, amazing. They're all hitting the like button in their car on the drive home. Please, keep your hand on the wheel. Yeah, so you're from Grafbase. Do you want to give a quick intro on who Jamie is first and what you work on?

Jamie: Yeah, sure. So I've been around for many years. Mostly around from the days of dial up modems and Flash websites, but these days I'm working with things like GraphQL, React and JavaScript. I work as a DevRel at Grafbase, so we are unifying data APIs and creating these incident GraphQL APIs for anyone that wants to consume data from wherever, I guess. So that's really good fun, I work on a lot of content and videos, speaking to developers. It's so cool.

Brian: Very cool. Yeah, I wouldn't have guessed your time in the dial up modem days. I was going to guess you were younger than I was, unless you were four or five years old, trying to plug in the modem and work on some Perl scripts and stuff.

Jamie: Yeah, I spent a bunch of time working with PHP back in the day and, yeah, dial up modems were fun, building PCs. I kept breaking my drivers for my modems, so every weekend I had to go and replace that and try and reinstall it from friends and stuff. Yeah, what a time to be alive. Flash websites were awesome as well, I did a lot of Swish. I don't know if you heard of Swish, but that, I guess, to these days that's more of like a framework for Flash back in the day. But they were pretty cool times, I miss those.

Brian: Cool. Yeah, in your little bio you mentioned you were an early adopter of GraphQL. Do you want to talk about your early days using GraphQL?

Jamie: Yeah, so I transitioned into using React for a while, started to learn a bit more about JavaScript. I was doing JavaScript with Rails, but it went through that weird Coffeescript period and we were using the ELB files and writing JavaScript inside of there. I like the idea of React and as I started to use React, I found GraphQL as I was just following along building things. I discovered GraphQL, watched maybe just one or two of the first talks.

I can't remember who it was, but somebody gave a demo on creating GraphQL in different frameworks that was pretty cool. I got fascinated from that point of just being able to work with data in a different way, and it felt just nicer and more intuitive to work with and I've just been using it ever since for anything I can. There's been times when I haven't worked on it full time, but I've kept up to date with it at least which has been really good.

Brian: Yeah, cool. I got early in the GraphQL, they had a GraphQL summit. Actually, Apollo previously was called Meteor, was running this GraphQL summit and they had made the decision to switch from whatever they were building for Meteor to use GraphQL and they had all the folks who put it together.

It happened to be across the street from where my office was from the company I was working for, so I was like, "I can get a ticket and just walk across the street, during the day go to the conference." It turned out it was really impactful for my career because I started using GraphQL immediately for some side projects.

I built a little React Native application. The company I worked at was Netlify, so I created that, used GraphQL, built a GitHub app with GraphQL, and yeah, never looked back since.

Jamie: Nice. Yeah, I remember working on a project and I was like, "I'm going to use GraphQL for this." And I really didn't know what I was doing, I was building the backend and the frontend, and I was trying to hook everything in. Back in the Apollo days we had this, I think it was called Connect, and you ended up with all of these different connect functions and you were passing in different queries and trying to tie that to components. I probably spent way longer to build this app for the company at the time because I was using something new, but that's part of the job and I guess that's why we love what we do, because we get to play with these things.

Brian: Yeah, exactly. So can we talk about Grafbase? You've mentioned about the aggregating APIs, but can you explain in a little more detail what people are using it for? What is Grafbase? What problem are they solving?

Jamie: Yeah, sure. So when Grafbase first started out it was a Backend as a Service, it was mostly a single database over GraphQL. So I don't know, you're probably familiar with Graph Cool back in the day, so a few years ago Grafbase started along those similar lines but making the local development experience first class.

You just run an MPX GraphQL dev, and that whole experience is running locally. You get that GraphQL API or locally with a database that's simulated and you don't have to deploy anything to test this. That's where it started, and then over the last 18 months to 12 months, we've spent a lot of time figuring out, okay, our database was good, people are using it.

But we also recognize that not everyone is going to migrate all of their content to our database, so how do we integrate with the world class databases?

We deploy GraphQL APIs to the edge, so how can we integrate with edge databases now? A lot of people are using these edge DBs, how can we bring those and unify those into a single Graph? That's what we're doing today and a whole lot more.

Brian: Okay, cool. Yeah, so I'm familiar with Graph Cool. Actually Johannes has been on this podcast multiple times, twice as Graph Cool and once as Prisma, or maybe the inverse. But I guess what I'm getting at is I'm very familiar with that experience and that was like the Firebase, your hosted cloud experience, and then they had the API integrations.

They completely pivoted into Prisma and that's what they're working on now. But can you talk more about this local experience? You have a SDK or a plugin that serves your GraphQL server, how's that work?

Jamie: Yeah, so actually today we just released a new TypeScript config and up until today you wrote GraphQL SDL and we gave custom directives so if you wanted to create a model you would tag it model, if you wanted a field to be unique you would tag it unique and add max values and things like that.

All of those directives were available in SDL, but not everybody wants to use that SDL. It isn't very type safe, it doesn't compose very well, it's not very modular and we wanted to provide a better experience that people are familiar with, with things like TRPC and all of that.

So we today released a TS Config so people can write config for their backend in TypeScript and that config can be configuring data sources, auth rules, permissions, caching, et cetera. Then what we will release in a few weeks, actually, is going to be the other side of that which is the client. The idea of all of this is you have a client in the backend config and they work together.

You could think of it like the Prisma config and the Prisma client, and we are going to do all the GraphQL handling. We'll handle that within the plugin, the client. You won't have to think about GraphQL if you don't want to, that's there if you need it but we'll just create this client for many different APIs. We use GraphQL as this technology at this point.

But I guess to answer your question and to talk about the CLI, is it's one command. MPX Grafbase init will initialize a new project, and Grafbase dev will actually start the development server. That actually uses MiniFlare, we're built on top of CloudFlare, that runs MiniFlare locally, we simulate the database using SQLite, we have things like live queries which we hook into some of the event streams within there and a lot of simulation.

We do a lot of what you see in our hosted cloud version. All of that runs locally as well, which I think that was really one of the biggest things that excited me when I first started to talk to the founder of Grafbase about joining. I was like, "This is a really cool experience. I've used dozens of these over the years, but actually just being able to run this with a simple MPX command is so good. It's a really nice experience."

Brian: Yeah. That's awesome too. So what comes to mind is my original experience in building my own GraphQL server as an Apollo server. So how does that compare with what Apollo is doing versus what Grafbase is doing?

Jamie: Yeah, so Apollo, you'll get Helix if that's still around and a bunch of others, Mercurius. There's so many great tools to build in GraphQL servers, but yes, you can build GraphQL servers, but do people really want to be spending time getting into the weeds of data loader and handling context and deploying CICD? We actually allow you to write custom type definitions and custom resolvers, and we will deploy that to the edge for you.

If you sync your GitHub repository to Grafbase, every time you make a pull request we will generate a new preview branch. So similar to Netlify, Vercel, you get that preview branch and it's for the new schema which is very cool.

Brian: That's amazing, yeah. It's like the Jamstackification of the backends of the services. I love the fact that you present a deploy preview of that experience because the painful part is being able to test some of this stuff. It's like you've updated your schema, it's in a PR, how do you go and test that? Do you spin up a whole staging server? It sounds like Grafbase has an option for you, and I guess is Grafbase, you have a managed solution and a cloud solution that manages that?

Jamie: Yeah, right now it's all cloud based, all managed. We will open source all of this probably later this year so people can run this themselves, but obviously if you want that experience of branching all done for you, then you'll deploy it with us.

Brian: Yeah, it's a popular interaction where you have the hosted version, that's usually where folks get their teeth cut and experience and bottom up. You're doing DevRel, the bottom up strategy is get people to use it as quickly as possible. I imagine you have tons of examples of folks being able to use Grafbase today. My next question is how do folks use it today? Are there examples of different frameworks and languages to connect to your database?

Jamie: Yeah, so we have a growing library of different examples and templates, and guides as well. So whatever framework you're using, that MPX Grafbase init command can be ran inside of your current project so if you've got something already and you want to start trying Grafbase or using it for something, maybe you just want to proxy it in front of a custom data source that you already use.

You can run that command in your existing project and it will just work, it'll run. Connect that to GitHub, you'll get a deployment. Then it's just a case of taking that API key and the API URL, configuring that with your project and making requests. But yeah, it just works out of the box with any framework.

It's just GraphQL, it works over HTTP, just make a fetch request. As we move more towards server rendering, now that works as well so there's no need to spend a lot of time setting up clients. You can just treat it as another end point. It doesn't even have to be GraphQL if you don't want to. We will release that client I mentioned, which will make that experience, I think, of setting and opening configuring clients go away.

Brian: Cool, yeah. It sounds like Grafbase has done a really good job fitting inside the entire ecosystem of GraphQL, so things that years ago... This is things that maybe people haven't touched GraphQL in a couple years, but things around authentication, caching. Does Grafbase have solutions for those two things?

Jamie: Yeah. We have spent a bunch of time over the past few months working on edge caching so now all of what we've discussed has the ability to be edge cached as well so if you write your own resolvers and you deploy those to Grafbase or if you connect different databases and you make a query, we will cache that automatically.

That's totally configurable as well to different data sources so if you only want to cache one data source and not another, you can do that. Auth as well, there's so many great auth tools and solutions out there. I know you had James from Clerk on not too long ago, and Clerk is something which I default to now. It's very easy, very nice to set up, and they have really nice integrations with Open ID Connect, and we support Open ID Connect so you can bring your existing users, they can log in, and you can use that same token against your Grafbase API.

So if you connect, say, a PostgreSQL database, you can configure permissions for a specific user group that was authenticated with Clerk to have access or not to certain data and actions. That's really, really cool, I think. Just to abstract that and not worry about it, and make auth agnostic. It's a really nice twist to not owning everything, but allowing people to plug and play what they want.

Brian: That's the value of the Jamstack thing with the plug and play and connect. The different pieces that make sense in your current developer workflow, and I think what's good about this is you can dig in deeper later. I can get my backend GraphQL API or my server up and running pretty quickly, those are the things that I usually lean for. Then if I can then opt in to have a deeper experience or connect or extend, that's another opportunity as well. I guess the question is folks who are interested in leveraging GraphQL, what's the persona of folks reaching for Grafbase? Are these solo engineering teams? Is this enterprise organizations or up and coming startups?

Jamie: A mix of that, I think. We are very, very recent to the scene. We have been working for a while to build this and what we are now seeing is a lot of different people using Open AI, for example, with caching. They want to cache a lot of that, so not spend the money on endless amounts of tokens. We can cache a lot of that, we connect with those APIs, we transform things like the spec into GraphQL automatically, their Open API spec.

So we're able to cache that, so we're seeing a lot of demand for people wanting to cache various AI services. eCommerce as well, eCommerce is very composable, we're in this best of breed era where people can bring their own services and APIs. Well, instead of you having to install endless dependencies and learn different APIs and plugins and how they all work, we'll just create one unified GraphQL API for you and soon the clients that you can just use to add things to the cart, fetch inventory, fetch stock, log in customers and all of that.

So eCommerce, Open AI, and mobile applications as well. I think mobile apps are fascinating, Native apps, but a lot of the time people think, "Oh, I can just put in my API key. It's safe." But actually that's not safe, it's still being sent over the wire so we're able to bring that and give mobile application developers this unified GraphQL API that works with different auth providers to be fully safe as well. So tons of different personas joining.

Yes, we have a community and Discord of people coming, "Oh, I'm using your database and your live query stuff. I just want to use that, it's totally cool. I have projects using that, I enjoy it." But, yeah, we are also seeing a huge increase in demand as a lot of companies are in AI, so we're really keen to figure out how do we bring GraphQL things to that? Streaming, the live queries, who can enter various events there, with caching as well to reduce costs elsewhere.

Brian: Very cool. So you started this conversation with your years of experience, so I'd love to actually pick your brain around this current landscape that you're just mentioning about for developer tools and approaching building new projects. I'm fascinated, where we've come. I started writing code professionally 10 years ago, so the world then which I was doing Rails at the time, it seemed very daunting for me to get started. But if someone were starting today and they were like, "I have an idea for this project." What would you be reaching for? Full stack experience?

Jamie: That's a very difficult question, and I'm sure the answer will differ whoever you ask. Honestly, I have a younger brother that is wanting to get more into this stuff and I'm like, "It is very overwhelming when you come into the space that we're in right now."

There's different tools for absolutely everything now, from notifications to text messages, to databases, to rendering markdown. There's something for everything, which is amazing, but it is very daunting.

I started with Code Igniter which was a PHP framework and I learnt that, I used that, I built things with that and it did a lot of what Rails did. It came with it's own solution and patterns for things that I could follow, and I would say maybe spend a bit of time with a framework that does that if you're getting started.

Redwood is really cool and is doing some of this now in a more, not modern, but very new and upcoming collection of tools, but trying to provide that, not old school experience, but a well known or a well defined pattern. So yeah, I would say reach for something like Redwood if you're totally new and not try to overwhelm yourself with having to learn JavaScript, CSS, HTML, databases, APIs, caching. Just don't spend the time doing that, just build something and then as you start to learn or want to go down different paths, then maybe you can start to build, dare I say, microservices and branch out.

Brian: Very cool. Yeah, anything else about Grafbase? You mentioned the SDK is coming out pretty soonish. Is there a rough date, quarter, that we can expect that?

Jamie: There'll be an initial version in the first few weeks of July. I'm looking forward to that.

Brian: Excellent. So by the time this podcast comes out, probably check out the docs or the blog post.

Jamie: Yeah, we have a change log which I post to every few days with new stuff that the team is working on, so all of that will be in there.

Brian: Cool. Sounds good. Well, Jamie, thanks for sharing about Grafbase. I do want to wind down the conversation, put us into picks. But folks, check out Grafbase. There's great guides and docs on how to get started in the framework of your choice so check that out. But Jam picks, these are things that we're jamming on. Could be music, food, technology related. Anything is on the table.

If you don't mind, I'll go first. I've got two picks. One is yesterday I just saw the new Pixar movie which is Elemental. I don't know, I've been running a startup recently so I haven't really paid attention. I didn't know there was a new Pixar movie until my wife was like, "Hey, we're seeing a movie." And I was like, "Cool, I need a break." But it's about elements, fire, water, earth and wind or air.

They all live in a city and I don't want to give away too much about it, but it's a really interesting story that I had no idea where it was coming from. But what I've liked in the last couple movies is the folks who are writing and directing, they come from underrepresented backgrounds so you get to learn a bit about their backgrounds and I think the person who directed or wrote this story has a Korean origin.

I don't know much about Korean culture, but some of those elements are in how folks emigrated to a country like the US, very similar to New York City basically, and emigrated and had to assimilate or bring their culture along for the ride. So a very interesting story if any of our folks live in a melting pot or want to experience different fire cultures and other stuff.

Definitely worth checking out, it's a good conversational piece after talking to kids about what this means and what that means. Pixar, they just don't know how to not hit you in the feels. It's one of those shows as well.

Jamie: Sounds awesome. I think I've seen a trailer for that last week when I went with the kids to see Spiderman. Definitely check that out.

Brian: See, I didn't see Spiderman yet. I guess when I get another break we'll have to take the kid out to see Spiderman as well before it leaves the theaters. I had a second pick which is Posthog. Posthog was a former guest on this podcast as well. Great conversation, super fascinating. I don't want to call it Google Analytics but open source, but it kind of is.

It's more product led growth analytics, so when you've got your project or your documentation, you're trying to figure out what points people click more, what pieces of information is not being leveraged, how are you converting folks, signups, to leveraging features that aren't getting as much exposure. I've just now spent a lot of time going through the documentation, building out some product led growth strategies.

What I've been doing inside of Posthog is doing zero to wow, which I did talk actually at Heavybit around onboarding and converting users and how Stripe and their docs do a great job of getting somebody something really quickly, and how GitHub actually had the opposite problem. They leveraged a community to teach how to use Git in GitHub, and they did no help whatsoever.

This was about four years ago, but they did no help to actually onboard new GitHub users. What we're doing at Open Sauce which is the company I'm running, we're now trying to find out, okay, from the time that you navigate the site, what's the time it takes you to signup within very new users? But also what's the time after signup for you to do something meaningful?

We're now trying to track that time. Within the first few minutes you're doing something meaningful and you're talking about it. That's the kind of thing we've been tracking in Posthog and it's a bit of learning curve because I'm not a product manager, or really put that much energy in product. But it's been fun to now see the results starting to track.

Jamie: That sounds really cool. I think that will be really interesting to check out for what we're doing. We're using a combination of things like Tiny Bird, Pop Sequel and creating all these different charts manually from our data warehouse. But definitely building something that is more bespoke would be pretty cool to check out, so that's a good pick.

Brian: Cool. Yeah, any picks for us?

Jamie: Yeah, two. The first one is a book that I read recently from Jono Bacon called People Powered. That is a great book. I've known Jono for a while, he was a mentor at a previous startup and he wrote this blueprint on building and growing communities. So if you're someone definitely working with DevRel, that's something that you should check out.

Jono does a lot of videos on YouTube talking about this stuff, week in, week out. This book is awesome, it just talks a lot about different psychologies and how people think and how they react and what you can do to pull on some of those. So really worth checking out. Yeah, just had a blast reading through that. I read it on a flight and then I read it on the flight back as well, so I've got it down now.

Brian: Very cool. I didn't know about this book, but I know Jono. So yeah, definitely check it out.

Jamie: Yeah, it's cool. The second is by Steven Tey, from Vercel. He released this thing called Novel which is a notion style, what you see is what you get editor with AI autocompletion. Every day this week there's been a new pull request with a new feature added. That's just typical Steven Tay. There's so many cool things being added every single day. This is definitely something, if someone wants to add an editor with AI powers into your app, then check it out. It's all open source, of course. It can be deployed wherever.

Brian: Yeah, I love Steven and Hassan who also works on the Vercel team. Their ability to ship really cool projects, showcasing things that they're interested in, but also they tie it back into their main objective which is get more people to use Vercel pretty seamlessly. I had a conversation with Steven about a year ago because he was shipping a lot of stuff and it was hard for me to keep up to date, and I don't think I had any influence in what they're shipping now.

But it's nice to see the momentum pick up and see all these cool things. Dub.SH was a tool I used for a bit, absolutely love it. I love seeing the growth and the adoption, and the fact that they're indie hackers. They have a job, but they're doing a bunch of indie hacker type stuff which is fun to watch.

Jamie: Really, really fun to watch, and given that time... I've was talking to Steven as well a while ago, and just being able to have the time to build all of this stuff, but like you say, to tie it back to product is such a niche way to DevRel, I think, from the indie hacking point of view.

Brian: Yeah, it's like when you're not being sold, you have such a better experience. I think that's what they've been really doing, like, "Here's a cool AI thing. I'm going to go clone this, use it, and by the way I can also deploy this to Vercel."

Jamie: Yeah, that's a good way of DevReling, not selling. I think a lot of people fall into that trap, and this is not that trap. It's really, really nice.

Brian: Yeah, we didn't go deep into your DevRel experience and role and how you engage community, but maybe for the next time you come on.

Jamie: Of course, definitely.

Brian: Cool. Well, Jamie, thank you so much for the time, chatting about Grafbase. Folks, check it out. Thanks for the picks as well, I'm going to grab that book and properly add it to my reading list. Here's another pick, have focused reading time in the morning. I feel like it's the best way to start my day, it's better than reading emails. That's for sure.

Jamie: I'm going to have to try that.

Brian: Cool. Folks, keep spreading the jam.