Ben Sklar is a Senior Product Manager here at Salesforce. Though he started college as a pre-med major, he quickly shifted his interests after taking a Coding 101 course. He went on to pursue Computer Science and even to do research at Vanderbilt University and Hamilton College.
Today, Ben and I are talking about GraphQL. GraphQL is a new standard which provides significant performance and organizational benefits to API calls as opposed to REST. Specifically, we’re discussing how Salesforce is implementing it and how you can use it. Join us!
Show Highlights:
- How Ben got into web technology and front-end engineering.
- How he got introduced to Salesforce and what he does in his current job here.
- An overview of GraphQL.
- The key limitation of REST that GraphQL is trying to solve.
- The two main ways to use GraphQL APIs.
- How lightning web components fit into all of this.
- More things on the roadmap for GraphQL.
Links:
- Ben on LinkedIn: https://www.linkedin.com/in/benjamin-sklar/
Episode Transcript
Ben Sklar:
I studied computer science, but I also studied medicine, health and society. I actually thought I was going to end up becoming a doctor.
Josh Birk:
That is Ben Sklar, a senior product manager here at Salesforce. I’m Josh Birk, your host of the Salesforce Developer Podcast. Here on the podcast you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Ben about GraphQL, what it is, how Salesforce is implementing it and how you can use it, but we’re going to start where we left off there with his early years.
Ben Sklar:
Yeah, so I think I actually started with pre-medicine, and that wasn’t a specific major, it was just taking some of those classes, like chemistry, biology, et cetera.
Josh Birk:
Right.
Ben Sklar:
I tried an intro to coding class, and I realized that I actually really liked it.
Josh Birk:
Nice.
Ben Sklar:
So from there, I was like, “Okay, well, I think I need to also pursue computer science and kind of figure out what do I like better?” I ended up pursuing both, but by the time I graduated college, I knew I wasn’t going to go to medical school. I didn’t end up doing all of the pre-med requirements I needed, but rather focused on computer science.
Josh Birk:
Yeah, yeah. Yeah, I hear you. I also went into pre-med when I went to college, and I believe it was the advanced chemistry class that murdered me, that made me think maybe there’s other avenues for my life. I thought I was going to go into psychology or become the first person to write another great American novel, none of that actually ended up happening.
Ben Sklar:
Yeah, organic chemistry, that’s what really kicked me off the path. I just couldn’t do it.
Josh Birk:
Shivers, shivers. But then you went on to Hamilton University where you’re doing research doing machine learning with Python?
Ben Sklar:
Yes. Okay, so I did spend a summer at Hamilton College and working also with Syracuse University. There was a psych study that was done, and they needed some statistics, and-
Josh Birk:
Really?
Ben Sklar:
We basically had to take some machine learning algorithms. There was a framework called Orange, and we plugged in the data they got from their study and output a bunch of results using machine learning. I think we used about 12 processors calculating for several days to get the data. It was a massive amount of data. So yeah, it was a really interesting project, and it taught me a lot and definitely made me more interested in technology.
Josh Birk:
I mean, that’s sort of jumping into the deep end of the pool.
Ben Sklar:
Right, yeah.
Josh Birk:
Nice, nice. Well, then how did you go from that into more web technology and front-end engineering?
Ben Sklar:
Yeah, so this experience really, again, made me more interested in technology as it pertains to web technologies, as well as front-end engineering. I ended up working for BNY Mellon, and they had offices in Pittsburgh, Pennsylvania, New York City, and Nashville, Tennessee. I actually bounced a little bit between their Pittsburgh, Pennsylvania and Nashville, Tennessee offices. I was working on some mobile apps, basically just internal at the time to allow for room bookings internally.
Josh Birk:
Gotcha.
Ben Sklar:
It seems like now that’s not so interesting, but at the time it was a pretty interesting project to be able to book a room.
Josh Birk:
Right. Nice. Yeah, well, I hear you. One of my first projects for Salesforce that got any kind of notice from Salesforce itself was actually trying to find how many contacts for an account were within the radius of an account, which now is a SOQL query. So yeah, stuff changes, stuff changes.
Ben Sklar:
Yep.
Josh Birk:
When did you first get introduced to Salesforce?
Ben Sklar:
Yeah, so I started about a year ago at Salesforce.
Josh Birk:
Okay.
Ben Sklar:
I had of course heard about them prior to that. The last company I worked at was actually SAP.
Josh Birk:
Okay.
Ben Sklar:
So of course Salesforce and SAP are competitors, although I worked in a different space than your traditional CRM, I was on the recruiting software side.
Josh Birk:
Really?
Ben Sklar:
Yeah, so I was at SAP SuccessFactors for the last few years before I joined Salesforce. I actually was doing a lot more front-end product management, making sure that the sites that customers had in order to attract talent, that that looked really good so that other companies could hire. So, what I’m actually working on at Salesforce now is much more backend-focused with our APIs.
Josh Birk:
Right. Was that an intentional change? Was that something that attracted you to the job at Salesforce?
Ben Sklar:
Yeah, so being someone who studied computer science, and as a former engineer, I sort of wanted to get back to my roots and work on something a bit more technical, and that’s kind of how I was led to Salesforce. This was a really interesting opportunity to continue to be a product manager, but work more on the backend side of things on the platform and on our APIs.
Josh Birk:
Gotcha. How would you describe your current job at Salesforce?
Ben Sklar:
Yeah, so I am the product manager of our backend data services for the Salesforce platform. What that entails, we have the user interface API, and that API is the same API that Salesforce uses to power the Lightning Experience.
Josh Birk:
Right.
Ben Sklar:
For customers and developers, they can use that API to build web and mobile apps, along with we just launched a brand new GraphQL API here at Salesforce, and that’s generally available as of winter ’23.
Josh Birk:
Love it. All right, let’s level set here. What exactly is GraphQL?
Ben Sklar:
All right, so GraphQL is a query language, first and foremost, and it’s also a run time for fulfilling queries. It’s also a standard across the web, and more and more companies are adopting GraphQL today. It’s sort of a new paradigm of data transfer between clients and servers. Whereas in the past we used REST and before that SOAP, GraphQL is sort of the evolution of these things.
Josh Birk:
I don’t know why just bringing up SOAP makes me giggle, but it kind of does. I mean, I wrote my first iOS application for Salesforce by deconstructing the SOAP API and putting it back together again, so it’s like an old friend, we haven’t talked in so long. So let’s walk kind of slowly through that, because I think that’s a brilliant way of describing it, but what are some of the key limitations of REST that GraphQL is trying to solve?
Ben Sklar:
Yeah. Yeah, so there’s a few features that GraphQL has that make it a bit more powerful than REST. So one of the main features is field selection, and what this allows developers to do is actually choose the fields that they want returned back from the server. REST has this functionality if you use query parameters, if the actual endpoint supports that, but there are some limitations there. Sometimes the actual endpoint doesn’t support it. It’s kind of up to the owner of that API whether they built in the functionality, versus GraphQL, you always know it’s going to be there.
Ben Sklar:
But some of the limitations are the URL character limit, and so if you have a really complicated query, REST, you may run into that URL element and then you can’t actually select all of the fields that you want returned. So, what ends up happening is maybe you make a call to an end endpoint and you get back a bunch of fields that you didn’t need.
Josh Birk:
Yeah.
Ben Sklar:
This is data waste, right?
Josh Birk:
Right.
Ben Sklar:
Then you have to deal with that response and either don’t use those fields or do some sort of orchestration on your end. Versus with GraphQL, the response actually is shaped by you as the developer. The call you make, the response is going to look almost identical and get you back those fields that you requested.
Josh Birk:
Yeah, and as a podcast, I know it can be a little hard to visualize, but in looking through some of your documentation and your slides and stuff, when you’re framing a URL for a REST call, it’s almost like you’re trying to figure out a way to ask the endpoint nicely to please do something for you. But with GraphQL, the format of the request itself, the JSON itself is, which I have a follow up question to, but the format of the request itself inherently drives the response. It’s hard to describe how painless it is.
Ben Sklar:
That’s exactly right. Another major benefit too is resource aggregation with GraphQL. So what this means is, in a single GraphQL query, or in other words, a single trip to and from the server, you can get back data from multiple resources. A good example for Salesforce is being able to bring in, let’s say, accounts, opportunities and contacts, and have the server give you back all of those resources in a single call, rather than having to individually make multiple REST endpoint calls to give back that data.
Josh Birk:
Mm-hmm. To be clear, even if you’re doing interracial data, with REST, if I got an account ID back from my first response, then I’d have to ask the server again, “Okay, what are all the contacts that are related to this account?” You’re doing that in one call.
Ben Sklar:
That’s exactly right, yep.
Josh Birk:
Nice, nice. I love the example that you had in your presentation for Dreamforce, where when you asked the REST API if you want, was it lasagna? Was that the-
Ben Sklar:
Ravioli, of course.
Josh Birk:
Ravioli, right. If you want cheese with your ravioli, the REST API may or may not know the difference. It’s serving you the pasta, or with GraphQL, you’re basically kind of giving it the ingredients that you want back.
Ben Sklar:
That’s right. So let’s say I make a call to the cheese ravioli endpoint, it’s always going to give me back cheese, ravioli and sauce, because that owner of that endpoint doesn’t support query parameters, so I’m stuck, right? I make the call, I always get back, I don’t have to take the cheese off of that ravioli.
Josh Birk:
Right.
Ben Sklar:
Versus with GraphQL, I can query just for the pasta and get back plain ravioli, no cheese, no sauce.
Josh Birk:
Yeah. It feels like the REST API has a little bit more opinionated intent to it even. How much is that … because we have a fairly straightforward Vanilla REST API, but that sort of still holds true, right? You’re still kind of having to ask the API nicely how to format itself back.
Ben Sklar:
That’s right. Again, with the URL limitations, I believe the character limit is 2,048 characters. Once you hit that limit, that’s as large as the URL can go, and you can’t really go further than that. Versus with GraphQL, you can make some really complicated queries to get back what you need, and that may be far more than that number of characters.
Josh Birk:
Right. Back to the format of the response and the request, is it pure JSON?
Ben Sklar:
It’s JSON Lite.
Josh Birk:
Okay.
Ben Sklar:
I don’t know if it’s considered JSON, but it looks just like JSON.
Josh Birk:
As I was visualizing that slide asking that question, now that I’m remembering it, it’s easily readable and it feels almost like JSON Lite. It does just what it needs and not all the other stuff that JSON throws at you sometimes.
Ben Sklar:
That’s right. I think officially what they say is that GraphQL services typically respond using JSON, but the GraphQL spec does not require it.
Josh Birk:
Oh, okay. Got it, got it. Now, one of the things I like about REST APIs is that it’s very easy to basically, especially if you can talk to it really quickly and have JSON thrown back to the browser, there’s some rapid testing you can do and we’ve got some great tools like Postman. Now in the world of GraphQL, GraphQL’s always in post method, right? You can’t just throw the URL, you have to package it in the body and then get the response, right?
Ben Sklar:
That’s right, yep.
Josh Birk:
So, what tools are out there for me to easily see, okay, I know that there’s a GraphQL API out there, I’m going to ask it questions and see what kind of answers I’m getting?
Ben Sklar:
Yeah, so there are two main ways to use GraphQL APIs, and you mentioned Postman already. Postman is one way, and it’s a really nice tool to allow you to test out your GraphQL queries. We also have a GraphQL collection on Postman, and you can get there through our publicly-facing documentation.
Josh Birk:
Cool.
Ben Sklar:
There’s actually another tool called GraphiQL or GraphiQL, which-
Josh Birk:
Ah, I see what they did there.
Ben Sklar:
Is GraphiQL. Yeah, I like to think that the I stands for introspection.
Josh Birk:
Okay.
Ben Sklar:
Some people might think it’s IDE, it’s a nice IDE for GraphQL.
Josh Birk:
Okay.
Ben Sklar:
Yeah, so GraphiQL is nice, because it allows you to introspect the schema. What does that exactly mean? So, it allows you to see the fields and resources that you have access to. Here at Salesforce, we respect field level and object level security for the user.
Josh Birk:
Nice, nice.
Ben Sklar:
So, any user using this will only see the fields and resources that they should have access to, or objects. So GraphiQL lets you see those, and it kind of also helps you write those queries. It’s got some nice features as well, where if you’re not really sure how to write it, it will, again, just help you write those queries. It executes really fast and it allows you to create multiple queries and choose which one you want to execute, even if you have a list of them. So, it’s a really nice tool to place.
Josh Birk:
So digging a little bit more into Salesforce itself, how are we ruling this out? What’s GA right now? Is this like the REST API where I just update my object model and then there’s a mirroring GraphQL that automatically works with it? Or is it something different from that?
Ben Sklar:
Yeah, so in the first release of the GraphQL API, we have support for record queries, and the same list of objects that are available through the user interface API today are available on the GraphQL API today.
Josh Birk:
Got it.
Ben Sklar:
We have various resources available through UI API, and we are going to be bringing more of those into the GraphQL API over time.
Josh Birk:
Got it.
Ben Sklar:
But we also want to bring in other core Salesforce API families into the GraphQL schema, so some of these other ones might be the metadata API or the tooling API. So we would be having multiple API families into one GraphQL schema, so you could query across what would, again, be multiple API calls, multiple API families, it would all be in the same GraphQL schema, and again, just making it kind of a one-stop shop for all of your Salesforce data needs.
Josh Birk:
Right, right. I’m salivating just at the idea of the tooling API being designed like that alone. Metadata is kind of obvious, because it’s sort of reflective of our structure, but having built tools against the tooling API, there’s literally nothing you can do with the tooling API without asking it three questions first, and then reconstructing the whole darn thing again and then doing it. So, that’s awesome. How does Lightning Web Components fit into this?
Ben Sklar:
Yeah. Yeah, that’s actually a really great question. So right now, the API that we have, you could use it with Lightning Web Components, but we want to make this a lot easier. So, we’re actually working on a GraphQL wire adapter that will let you take the queries that you’ve written on your Salesforce GraphQL API and plug it right into your Lightning Web Components. You just will have an @wire similar to what you’ve been doing for REST using the Lightning Data Service.
Josh Birk:
Gotcha.
Ben Sklar:
It’s going to work almost exactly the same, and it’ll offer really efficient caching for our clients as well.
Josh Birk:
Ooh, nice. I think that’s interesting going back to the whole resource aggregation, because also in your presentation, you’ve got here’s your typical web interface, right? It’s never one thing, it’s your person, it’s your company, it’s your profile and all that kind of stuff. So, that means a Lighting Web Component would basically be able to wrap that into one JSON Lite request, and then just sort of be done.
Ben Sklar:
That’s right. So, the example I gave before was kind of building a social media app where you have the username and the profile, and maybe a feed of information and maybe some photos. Each one of these things is traditionally one API call, one REST API call, and you have maybe 10 things on the page, maybe that’s 10 API calls.
Josh Birk:
Yeah.
Ben Sklar:
But with GraphQL, you can query for all of these in just one call and only take the pieces that you need. So, let’s say in the bottom there it says notifications and it says maybe five notifications, rather than having to pull in all that notification data and kind of not use it right now, you can just request for, okay, how many notifications do I have? That’s really lightweight and fast.
Josh Birk:
Yeah, yeah. So I think the way we’re describing it, it’s pretty easy to understand how that’s friendlier to at least the client. I’m thinking in terms of JavaScript, just how that would even change somebody’s lazy loading formula. If I sent out five API requests, but they’re doing it asynchronously, I still have to wait for them to come back in some random millisecond and before I know my UI’s complete. Here, it’s just ask and receive, right? It’s just one fell swoop.
Josh Birk:
But what do we see on the server side from that? Because you’ve also reduced that down to one call and you’ve reduced the resources required to ask the question and also to answer the question.
Ben Sklar:
Yeah, what we’ve seen in our performance testing is just faster performance. We’ve seen, depending on the situation, sometimes it’s a two times improvement, sometimes a 5X improvement. We’ve seen really, really good performance data so far in reducing the number of fields you need, the number of resources you need to call, and again, just making it only what you need, rather than pulling all this data that you might not need, and you’re probably not using a lot of it and it’s just getting wasted. That’s not good for the client or the server, there’s a bunch of data waste.
Josh Birk:
Right, right.
Ben Sklar:
Yeah.
Josh Birk:
Nice, nice. Anything else on the roadmap you want to give a shout out to?
Ben Sklar:
Yeah, so we’ve been talking a lot about queries, which is the concept of reading, but I haven’t yet mentioned mutations, which for GraphQL mutations are synonymous with writes. So, these are your creates, your updates, your deletes. We’re working hard to bring mutations to this API as well, and we’re hoping to release these in an upcoming release soon.
Josh Birk:
Gotcha.
Ben Sklar:
Release over release, add more write functionality for this GraphQL endpoint.
Josh Birk:
That works the same with resource aggregation, I assume. I get the parent, I get the children, I update for the children, and I just send the whole plot back?
Ben Sklar:
That’s right. Yeah, and so again, it would be a mutation with GraphQL, as opposed to a query.
Josh Birk:
Uh-huh. That’s our show. Now as this was a discussion on product, please note there were several things we talked about which are on the roadmap and not yet released, so please make your decisions based on current features and all that jazz. Some of the future things we talked about was how GraphQL will eventually work with Lightning Web Components, using the bulk API, the tooling API, and of course that wonderful, wonderful word, mutations. Now before we go, I did ask after Ben’s favorite non-technical hobby.
Ben Sklar:
So, I am an avid skier-
Josh Birk:
Nice.
Ben Sklar:
And I actually grew up on the East Coast. We talked earlier about Hamilton College, which is actually close to my hometown. I grew up in Central Upstate New York, and Hamilton College happens to just be 10 minutes away from where I grew up, making it pretty convenient to do some research there.
Josh Birk:
Also, to get some skiing in.
Ben Sklar:
That’s right, also to get some skiing in. So, I’ve been skiing since I was four years old.
Josh Birk:
Oh, wow.
Ben Sklar:
I skied on my first black diamond when I was five.
Josh Birk:
What? What?
Ben Sklar:
Yeah, so I am a huge-
Josh Birk:
Were you too young to have fear?
Ben Sklar:
I think so, I think so. Yeah, children typically don’t have fear at that age.
Josh Birk:
Right. I love it, I love it. Ben, thank you so much for the great conversation information. That was a lot of fun.
Ben Sklar:
Yeah, thanks Josh. This was great.
Josh Birk:
I want to thank Ben for the great conversation information, and as always, I want to thank you for listening. Now if you want to learn more about this show, head on over to developer.salesforce.com/podcast where you can hear old episodes, see the show notes and have links to your favorite podcast service. Thanks again everybody, and I’ll talk to you next week.