Follow me:
Listen on:

Day Two Cloud 121: Building Cool Things With GraphQL And AWS AppSync

Episode 121

Play episode

Today’s Day Two Cloud is a nerdy show on GraphQL and AWS AppSync and what you can do with these tools. Our guest is Amrut Patil, a senior software engineer using these tools. Please note that Amrut’s opinions are his own and do not reflect those of his employer.

We discuss:

  • Amrut’s study tips for AWS certifications
  • GraphQL’s origins and use cases
  • Problems that GraphQL can solve
  • Potential downsides
  • How AppSync supports GraphQL
  • AppSync authorization mechanisms
  • More

Sponsor: Aviatrix

Check out Aviatrix’s Flight Training to learn about multi-cloud networking and security. It’s worth your time if you’re defining your company’s multi-cloud strategy or want to nail down your Aviatrix Certified Engineer certification. Get details and register at

Show Links: – Amrut’s blog

@amrutdecoder – Amrut on Twitter

Amrut on LinkedIn

Udemy author Stephane Maarek



[00:00:00.190] – Ethan
[AD] Check out sponsor Aviatrix’s Flight Training to learn about multicloud networking and security from the Aviatrix perspective, Aviatrix dot com slash flight-training. Worth your time if you’re defining your company’s multicloud strategy or want to nail down your Aviatrix certified engineer cert. Aviatrix dot com slash flight-training. [/AD] [00:00:26.390] – Ethan
Welcome to Day Two Cloud. We got a nerd show for you today, folks. We are going deep on GraphQL and then AWS app sync with our guest, Amrut Patel. He is a senior software engineer who’s been using these services. And what is GraphQL? Well, Ned, can you even summarize what it is just based on this show?

[00:00:47.810] – Ned
It’d be difficult to put into just one sentence, which is why we nerd it out about it for 45 minutes and really dug into some interesting implementation details. And you even had your own unique use case for it. So I was just enthralled by the conversation. And really, I actually think I learned a lot.

[00:01:07.010] – Ethan
I did enjoy this conversation with Amrut Patel because he’s from the developer side of the house. You Ops, folks.

[00:01:15.530] – Ethan
Amrut, welcome to the show, man. It is nice to see you here smiling on our Zoom session here this morning. But the folks in the Day Two Cloud audience do not know you. So give them a clue, man, who are you and what do you do?

[00:01:29.510] – Amrut
Yeah. So I’m a senior software engineer for Clinical Trials organization. Basically, I develop data applications for clinical trials management.

[00:01:41.570] – Amrut
And. I completed my Masters in computer science, and I worked at Xerox for a couple of years, and then I moved on to health care is more interesting. So let’s get into that and start developing some applications right there.

[00:02:01.670] – Ethan
Ned, Amrut is a developer. He’s from the other side, one of the operations.

[00:02:06.470] – Ned
How did you sneak on to the show?

[00:02:12.450] – Amrut
I guess the topic is interested, you guys. That’s why I’m here. So we’ll see. Yeah.

[00:02:17.370] – Ned
Well, the first thing that caught our eye was you mentioned that you recently passed three of the associate level AWS exams. And I know there’s lots of folks out there that are looking to pass those exams and get those certifications. So I guess what we’re asking for is just give us a brain dump of all the questions and answers.

[00:02:38.590] – Amrut
Well, I have, like, 800 questions to cover. Okay. All right.

[00:02:43.150] – Ned
Welcome to our one of the 20 hours podcast. But seriously, in order to pass the exam, can you give us some tips on what you did from a studying perspective?

[00:02:53.650] – Amrut
Yes. So, like, the three certificate certifications I completed was for the solutions architect, associate, the developer, associate, and the cloud practitioner. So I would say these three form, like the foundation for, like, basically, if you want to get into the AWS world and in terms of tips and tricks, I think if someone who just wants to get an exposure to AWS Cloud, even if that person is a non technical person, I think you start with the AWS Cloud practitioner exam because that will give you a good overview of what all the services are like, whether it fits into the business needs and things like that.

[00:03:42.310] – Amrut
And then you move on to the Solution Architect Associate, which will give you the architecture design principles that AWS recommends, which you should use to build your own apps and improve your system design understanding and the kind of services which you can use. Because the way I look at AWS is like it’s a bunch of Lego blocks and you’re trying to build something. And if you don’t know which piece to put where that’s going to create havoc when you’re actually building architectures and trying to understand business requirements, the Solutions Architect Associate addresses those concerns and teaches you all the concepts you need to understand.

[00:04:29.350] – Amrut
And then I continued towards the Developer Associate Exam certification, which is basically like, you are a developer and you just want to go more hands on and you need to understand what the services are and how to use them. So the focus is less on architecture, but more on using these services to actually develop your application. So these were like the three certifications. I was more interested in getting a broad exposure to AWS. I thought doing the AWS certifications would help. And then in terms of preparing for this exam, I took a bunch of courses.

[00:05:19.390] – Amrut
These are people that I’m not paid to promote or anything, but this is something that I have followed to develop. So again, no business affiliations with these guys, but this is my personal recommendations. Like I looked at Stephane Maarek’s course on Udemy. He has multiple AWS courses, but the two I would strongly recommend were the Solutions Architect Associate Exam and the Developer Associate Exam certifications. And then he also has practice tests, which are nothing but like, bunch of questions that you need to practice. So around 300 to 350 questions with various topics that will be asked in the exams.

[00:06:08.290] – Amrut
So that is one good resource that listeners were interested in doing AWS certifications.

[00:06:17.170] – Ethan
Can you say the instructor’s name again?

[00:06:19.150] – Amrut
Stephane Maarek. Stephane.

[00:06:21.970] – Ned
Okay, I found it. And we will include a link to his Udemy stuff on in the show notes If folks are looking to get into those courses and check them out.

[00:06:31.510] – Amrut
Yes. And another additional resource that I like to mention. Like this guy, Stephane Maarek will focus more on getting the certifications. But if you guys want to really understand the real world problems and how to use it as services, do some hands on practical app. So there’s a course by Adrian Cantrill.

[00:06:57.070] – Amrut
His courses are way too long, like 50 hours courses. But the good part is you feel really confident once you complete those courses. So even if let’s say you don’t want to do the certifications, you just want to understand what AWS is all about. I think this guy does a really good job of doing some practical labs and hands on.

[00:07:18.010] – Ethan
Did you do primarily just online courses. Video instruction and that kind of thing or books part of your study?

[00:07:25.390] – Amrut
I did not take any books per se, but what I did was AWS has some really good documentation where you have white papers which cover certain areas of the exam pretty well. Another good resource is frequently asked questions about a particular service. I think those are really good resources.

[00:07:48.850] – Ethan

[00:07:51.010] – Amrut
And, if you look at the exam questions, you’ll notice that some of them are also asked from there. And they want readers to be aware of what all things are being asked about.

[00:08:01.450] – Ethan
Back in the day that’s the way the Cisco exams were, too. This goes back some years. I think they’ve really changed how they do things, but it used to be all the answers were in Cisco documentation. And if you were familiar with the Cisco docs, you knew what you needed for the exam because it was all right there. And that’s where they were drawing their questions from. I think that’s changed a bit. But anyway, good to know that the AWS exams, there’s plenty of material out there, both third party and then from AWS themselves.

[00:08:28.150] – Ethan
It’s pretty good. Amrut, the thrust of this conversation that we wanted to get to is about a couple of things AWS AppSync, which is a solution you’ve used in the AWS platform. But before we talk about that, we need to talk about what AppSync is kind of all about. Which is GraphQL.

[00:08:45.250] – Amrut

[00:08:46.030] – Ethan
Can you give us an overview of what GraphQL is?

[00:08:50.050] – Amrut
Yeah. So the way I look at GraphQL, is it’s a data query and manipulation language for APIs? Like, the way I look at REST APIs is like it’s an API architecture pattern. Right. And what GraphQL does is it’s going to give you a way to build APIs, but using something called GraphQL language, and essentially the way I look at it is like you use this language to query data, which you need from these APIs, and that’s what it is. It was originally developed by Facebook, and it’s been there since around, like, 2015, but recently it has gained more popularity because of the problems it’s trying to solve.

[00:09:43.690] – Amrut
So I think it’s pretty fun stuff. I know we are going to talk about different things that GraphQL does for us, but it’s something that I think developers and everybody who’s working with APIs should be aware of.

[00:09:58.510] – Ethan
Let me give you a scenario where I think I could use GraphQL in my particular world. I’ve been excited about GraphQL for a while when I got the kind of a high level of what it’s all about. But.

[00:10:11.770] – Ethan
Let’s say you’re just painting a simple scenario about podcasting, since that’s the world I’m in. I want to know aggregate consumption numbers for a podcast. How many people downloaded the podcast from all these different places? So if I have a GraphQL server, it could sit in between me and a bunch of different APIs that are out there that I might need to query to find out how many downloads I got from different distribution sources. So my primary podcast CDN, I could query their API. I could hit Spotify’s API, let’s say, on Google Play, I don’t know, and they’ll offer me all that data that I want, but rather than me and my code having to hit all those individual APIs, I could instead have a Graph QL server that sits in front of those APIs.

[00:10:58.750] – Ethan
Connects to them for me, I run a GraphQL query in my code, hit the GraphQL server, which knows because I’ve set it up to talk to all those APIs for me and get back those podcast download numbers, and I could do it in a single query if I construct it correctly on my client side. The GraphQL is kind of the middleman there that I can customize to present to me. I guess we could call it a custom API. That’s kind of that. I mean, that’s really understating what’s going on there, but basically that and it also gives me the advantage of not having to fuss with whatever crappy API the podcast download provider might be giving me.

[00:11:40.990] – Ethan
They could be giving me a whole bunch of stuff in a JSON blob I don’t care about necessarily. If all I want to know is all I want to know, our podcast download numbers. GraphQL lets me as the client ask for just what I want, and the GraphQL server gives me just what I want without all this extraneous metadata. So there’s my scenario right now that you know more about GraphQL than me, for sure. Do I have the idea about right? Or am I wrong in places?

[00:12:10.870] – Amrut
Yeah, I think you’re right when you say that if you have a bunch of you have data being returned by a bunch of services, you’re trying to combine them and return it in one single request. Yes, that’s exactly what GraphQL does. So think of it like a middleman where who’s going to go and do the job for you rather than you going to each and every person and getting what you want. What GraphQL will do is behind the scenes. It will talk to these different services which are returning the data which you need and then combine them in a response format that will be used by the client.

[00:12:51.610] – Amrut
The good part is that if you try to do the same in Restworld, for example, let’s say the scenario which you mentioned Ethan. You would have to make at least three to four API calls just to get those counts from each and every service which you’re talking to and what GraphQL does is it’s going to abstract that away behind the scenes. And all you need to worry about is how your data is going to get constructed and the data sources that are going to return those data and the way you need to connect those GraphQL fields to those data sources.

[00:13:31.450] – Amrut
I know these are like terms that are specific to GraphQL, and we can go into it a bit more, but essentially, that’s what it’s doing. And that’s what it’s happening. It’s combining data from multiple data sources into a format that the client can easily request and get data from.

[00:13:56.050] – Ned
Okay. So many questions that I have. Let me start with who would stand up the Graph QL server? I mean, in Ethan’s example, he’s standing it up to talk to these other services. But would it typically be a specific vendor who wants to tie a bunch of their APIs together and present them through a GraphQL interface to developers and they would host the server? Or do you more often see people just building their own GraphQL server to tie together a bunch of disparate vendors that all have their own API.

[00:14:29.830] – Ned
Is it both? I’m not sure.

[00:14:32.230] – Amrut
To answer your question in one sentence. AppSync solves all that. But let’s say you are not using AppSync, you’re not on AWS, but you still want to use GraphQL. Then there are, like, libraries and frameworks out there like Apollo is one example. What Apollo does is it’s going to give you a client side version of GraphQL where it’s going to efficiently. If you’re using a content framework like React, it’s going to efficiently integrate that with the Apollo library.

[00:15:10.490] – Amrut
And, you can make GraphQL queries using that framework pretty easily. And it takes care of a lot of the nittygritty details that you don’t need to worry about. As a developer, you just need to worry about how do I construct my query and send it and get the data back? Right. And if you are on the server side, the beauty of GraphQL is like you develop this query on the server side, you can use the same query on the client side. You don’t need to learn a new language or learn a different format to just construct this.

[00:15:43.850] – Ethan
Wait a minute. You actually just lost me there. You said if I’m using the same, I could use the same query on both the server and client side.

[00:15:50.390] – Amrut

[00:15:50.630] – Ethan
But to me, GraphQL is presenting a queryable endpoint, so those would be different things. In what sense are they the same?

[00:16:01.070] – Amrut
So I mentioned about Apollo, right. Because on the client side, how are you going to request data from the client to the server? Essentially, if you’ve used any libraries which make these Http requests to get your data, for example, Axios right now, what you’re doing is you’re using Apollo, which is going to serve as a client to make these API calls. And the way we are doing that is using GraphQL code in that that’s what I meant. Like you use the GraphQL language on both the clients side and sender side in the request so that you get what you need.

[00:16:44.570] – Ethan
Yeah. The GraphQL language, not being especially complex either. It looks like fairly plain English. It’s not YAML, I don’t believe, but it looks yamilish where there’s some white space, and there’s some specific fields of metadata that you wish to get back, and a structured, single little plain text.

[00:17:03.230] – Amrut
Yes. And the way I look at it is just JSON, but strip down to only what you need. That’s how I look at it. And essentially, if you are deciding on how your request and response are going to look like, essentially, what GraphQL has done is they have given you a light weight, easy to understand syntax where you define the request in such a way that you will specify the request in such a way that your response is going to look like the way the data is going to get constructed.

[00:17:43.310] – Amrut
That’s what it means, right. To answer your question Ned, on the GraphQL server side, you will use the same Apollo library, but for the server side. And now what it’s going to do is it’s going to talk to all these different data sources. Let’s say you have a database where you have a certain bunch of data that’s getting stored, or you have, like, an external API endpoint, which does the authentication part of it or a payment part of it. So this GraphQL server is going to handle those requests for you on the server side.

[00:18:17.150] – Amrut
And if you’re using open source libraries like Apollo, then that is going to do the heavy lifting for you. That’s what.

[00:18:27.890] – Ned
Okay. So when you say data sources, it could be like a rest API that the GraphQL server is talking to, or it could be a traditional database endpoint where it’s making SQL queries against it could be either.

[00:18:40.190] – Amrut

[00:18:41.990] – Ned
Okay. So that clicked a few things together. For me. I think an important point to Hammer home is if any of our listeners have ever used a Rest API, you know, you make that request and you have no control over how much JSON it’s going to send back to you. You might be able to filter by date or something, depending on what it is. But generally speaking, you’re just going to get this gigantic payload and you have no say over the format of that payload or what’s in it.

[00:19:05.450] – Ned
You just got to deal with it. Is that one of the things that GraphQL is solving, being able to modify what that payload looks like?

[00:19:13.430] – Amrut
Of course. Yes. That’s one of the key features. Actually, if you read a little bit about GraphQL, you realize that this was the exact same problem the Facebook engineers were trying to solve because they were dealing with huge JSON blobs. And out of which, let’s say there are ten fields or 15 fields, out of which you just needed two fields to work with on the client side. And then what happens is it also increases the complexity of the quote. Let’s say tomorrow, if you want to add certain required fields to your response. Right?

[00:19:48.470] – Amrut
Then if you are in the REST world, you’ll have to create a different version of the API. You’ll have to make sure that the data getting returned does not break the client in any way. Right. The problem GraphQL solves is like you specify only what you need in this GraphQL query, and as long as these fields are in the response, you’re good. Even if you make changes to you create like, ten different versions of the API. As long as these fields are present in the response, you don’t have to maintain different versions because one of the problems that Rest API has is like you’ll have different version of APIs running in different environments.

[00:20:32.030] – Amrut
You’ll have version one in test, you’ll have version two in train, and then you’ll have like a version three in prod. So now, as engineers from a maintenance point of view, it’s harder. And let’s say tomorrow the requirements change. Then you change version one, but you forget version two and version three. Then what are you going to do? Essentially, one other problem. So these were one of the versioning problems that REST had and GraphQL solves all that because what GraphQL does is it’s going to give you one end point and that endpoint is behind a GraphQL schema.

[00:21:17.090] – Ethan
Yes, it solves it from the client perspective, because now your client code base is easier to maintain, but you’ve just shifted the work. The work still has to be done. But now on the GraphQL server, right?

[00:21:29.870] – Amrut
Yes. But if you look at it from like a maintenance point of view, isn’t it easier to just change your Schema and not maintain different versions for different environments and just have one end point that point.

[00:21:48.330] – Ethan
Oh, I’m not arguiing that point. I love this scenario. I’m thinking about different little bits of code I use here and there. And this solves a few problems for me if I wanted to take on the GraphQL burden.

[00:21:57.030] – Ned
If I think about the way Facebook has its native client on a billion 2 billion devices, not having to update all those client apps to the new API version or whatever, and instead just being able to do it on the server side makes so much sense for them and even scaled down to smaller implementations. I can see where that would make a ton of sense to do as well.

[00:22:19.830] – Amrut

[00:22:22.650] – Ethan
Another efficiency improvement. I don’t think we’ve mentioned yet, but as I was reading, I found that GraphQL service can cache responses. Is that right?

[00:22:29.790] – Amrut
Yes, it can at times if there are frequent requests that are being made for a certain set of data. Again, I know we are going to talk about AppSync, but AppSync takes care of this for you as well. The other thing is yes, you can enable Caching in GraphQL and you’ll have again, Apollo libraries. One, the reason I keep mentioning Apollo is because I’ve worked closely, but yeah, there are built in features that this library offers where you can enable Caching on GraphQL, which will always cache frequently used data and things like that.

[00:23:13.650] – Ethan
So it strikes me just from an architecture perspective that a GraphQL server is a potential SPOF, or maybe a choke point if it’s under load. Is that a concern? Do I have to think about that.

[00:23:27.970] – Amrut
From a GraphQL server? I think I don’t have that much knowledge to comment on that.

[00:23:34.210] – Ethan
Because you’re just going to punt us back to AppSync again, aren’t you? Aws, just takes care of all of it.

[00:23:37.630] – Amrut
Exactly. I cannot comment on GraphQL server without using AWS, whether it’s scalable. I think I don’t have that much expertise to comment on that.

[00:24:00.350] – Ethan
Now you mentioned Apollo. And when I just searched for open source GraphQL just to kind of see what came up, Apollo came up and I ran into a bunch of other systems or services as well. Prisma Hashura, Community Edition, Meldio or Meld IO? Meldio, and then a whole bunch of programming language libraries that will present a GraphQL API act as a GraphQL client, et cetera. It seems like it’s incredibly well supported out there, but each of these things kind of do something specific within the GraphQL ecosystem. They don’t all do the same thing.

[00:24:33.650] – Ethan
There’s servers, there’s client components, there’s glue in the middle. Kind of how you describe Apollo. Aside from Apollo, are there other open source, either resources or code bases projects that you think are interesting to mention?

[00:24:48.710] – Amrut
So I think, yeah, Prisma is another library like you mentioned. Ethan is what you can use for GraphQL, or I think Apollo is more popular, but I know there are companies out there who started, like we’ve, the place I work at is like a relatively small company, but it’s growing and expanding. And one of the architecture discussions we had was like, tomorrow, if our organization grows, can this API scale with that? And we needed something that will address the changing business requirement needs that we always have.

[00:25:37.830] – Amrut
Like, every three months, you’ll have something where you need to come and change the data again. So those things I think GraphQL has helped a lot in terms of, like, we are able to deliver products pretty quickly in less than nine months and in a team of, like, two or three people. So that’s pretty good.

[00:25:57.930] – Ned
Yeah. It kind of reminds me of what Citrix was trying to do with their Net scaler product as the application delivery controller. They stopped calling it a load balancer, and they’re like, no, it has a fancy new name. Now they were inspecting the requests that would come in before they would forward it along to the back end service. And they would try to do things like Caching or optimization or something along those lines. It could even cache database query results and return those. It sounds a little bit like that, but even more advanced.

[00:26:29.730] – Ned
And the things they were saying was kind of what you’re saying. It improves efficiency. It lowers the burden on the back end to a certain degree. And it also adds a load balancing layer. I guess it kind of adds a load balancing layer to a certain degree. Does AppSync do that too?

[00:26:48.330] – Amrut
Yes, AppSync does that. I think we should name this podcast to, like, just an AppSync podcast. I’m coming and talking about just AppSync stuff. That’s it.

[00:27:01.390] – Ethan
Well, you know what? I think we’re ready now.

[00:27:03.610] – Ethan
We’re ready. We’re ready to talk about AWS AppSync. We got our GraphQL foundation to build the AppSync conversation on. So let’s transition Amrut, what is AWS AppSync.

[00:27:15.610] – Amrut
So to put it simply as listeners are aware AWS has a service for basically anything you want to do, AppSync is another way of it’s, a fully managed GraphQL service from AWS. So essentially the things which you mentioned, Ned, earlier where if I have to set up a GraphQL server, do I need to do something? So do I need to use Apollo library for that? Things like that. So all that stuff is taken care of by AWS AppSync, including stuff like maintenance, scalability, responsiveness, caching. It has tighter integration with other AWS services, which things like if you want to perform authentication using AWS Cognito, which is a Cognito, which is an authentication service from AWS, it has integration with that.

[00:28:21.070] – Amrut
If you’re already using a database that is offered by AWS, like Postgres, for example, which I think it’s AWS Aurora that is Postgres based implementation. It already has integration with that. So the good part is you don’t need to worry about the administration side of things like, okay, how do I specify the configuration so that I’m able to connect to the back end database correctly? All that is taken care of behind this.

[00:28:54.190] – Ethan
That makes sense. You as the developer, then can just focus on coding and not the mechanics and the glue to connect these services together. If it’s AppSync, talking to another AWS service, then they just make that easier for you. That makes sense.

[00:29:07.270] – Amrut
Yeah. And then, like I mentioned before, GraphQL, AppSync will, you just need like, one endpoint, which behind which there is a schema that will make sure that the data that you requested conforms to that schema. Right. So it sits behind that endpoint and AppSync just gives you that you don’t even have to worry about the set up and all. And there is like a good UI console where you can directly write code within AWS and spin up these endpoints pretty quickly.

[00:29:47.150] – Ethan
Now they call it AppSync, as I was reading about this, because it seems like the primary use case that AWS is citing for the service is mobile apps where you’ve got people that maybe are on tenuous Internet connections that comes and goes and they need to work offline a little bit and then sync back and so on. So you can use AppSync to sit in between potentially millions of clients and whatever your back end services are and AppSync keeps everything literally all of those applications in sync.

[00:30:18.350] – Ethan
Is that kind of your use case Amrut? Are you using AppSync? Because we haven’t really talked about GraphQL in that context. But that’s how AWS seems to be positioning this.

[00:30:29.030] – Amrut
Yes, I would say that is one use case. Yes serving mobile user. So, for example, if you want to work with offline data storage where you want to make sure that whatever changes the user is making on the client side, your data needs to be synced with the server. Right. So GraphQL offers something called as subscriptions. Where your client where your AWS, your mobile clients are going to be in sync with your back end servers using these subscriptions. I know there are key things that GraphQL offers.

[00:31:15.150] – Amrut
There’s something called S Queries, which is essentially like similar to what you use in REST which is get where you want to just query your data without modifying it. And the other key thing that you need to understand is like mutations, which is essentially when you are trying to update or delete the data or change the data in any format. Right. And then there’s something called a subscriptions where you open, basically. I mean, if you go into the internal details, it’s basically like a web connection that the client is always connected to, and whatever real time updates are happening on the back end, those updates are getting pushed to the client.

[00:32:02.190] – Ethan
So you mentioned mutations. Now what that seems like to me is it would be changing like a data format and normalizing it. But that’s not what you said. It sounds like Mutations is actually simply changing data in the data field itself, not transforming the data in some way.

[00:32:18.870] – Amrut
So the way to look at mutations is it’s essentially you are trying. They are basically like three CRUD operations, as you call it. Right. Create update and delete. The mutation is like the Create update and delete part of it. So let’s say if you want to delete some data in the back end in GraphQL, you’ll do it through something called as mutation. If you want to query the data from a particular endpoint, the way you’ll do it is using something called as a query. And then if you want to have, like, real time, let’s say you’re building a real time chat application and you want to make sure that your messages are delivered in real time, and you always want your server updates to be pushed to the client instantly.

[00:33:06.870] – Amrut
Then the way you will do it is using something called a subscription, which GraphQL offers.

[00:33:13.290] – Ethan
[AD] I’m rudely cutting into this conversation to ask you where you’re at with your multi cloud networking strategy. Because a few different multi cloud networking vendors, they’ve come on as podcast guests.

[00:33:21.210] – Ethan
And they’ve shared their approach here on the Packet Pushers Podcast Network. One of those vendors is today’s sponsor Aviatrix. And in fact, you heard from Aviatrix engineers and a customer as Ned and I nerded out with them on the Day Two Cloud Podcast Episode number 113, we covered their data plane that’s common across all the different clouds, giving you consistent network operations.

[00:33:42.270] – Ethan
Now, if Aviatrix isn’t a company name, you know very well, don’t just blow them off. I challenge you to consider all vendors that might solve your problems, and Aviatrix is going out of their way to make it easy for you to include them in your upcoming multi cloud networking Bake off. First, they are well funded. So they’re going to be around for a long time.

[00:34:01.170] – Ethan
Tell your boss, Aviatrix just closed $200 million Series E funding round if you get asked. Second, Aviatrix is also offering Nerdy deep dives for you, the engineer, so that you can make an informed, nuanced decision about whether Aviarix is the right multi cloud networking strategy for your organization. They call it flight training.

[00:34:19.830] – Ethan
And you can go for a 90 minutes hands on lab, a five hour deeper instructor led hands on experience and even prep for the Aviatrix Certified Engineer certification. So give Day Two Cloud Episode 113 a listen and then visit Aviatrix dot com slash flight-training to find out more. I’m hoping to take the five hour flight school training sometime myself soon if they can find room for me. Again, that is Aviatrix dot com slash flight-training and let them know you heard about it on the Packet Pushers Podcast network. And now back to today’s episode. [/AD] [00:34:56.130] – Ned
AppSync is a service. So when you spin up AppSync, you don’t see any of the I guess, instances that are running the service in the background. Do you have to worry about scaling or I guess I’m curious if you have to worry about scaling and also how you’re charged to use it. Is it by the transaction?

[00:35:17.490] – Ethan
When you say scaling like it’s AWS Ned, you don’t have to worry about scaling until you get the bill.

[00:35:24.090] – Ned

[00:35:25.830] – Amrut
That’s true. So AWS AppSync is serverless behind the scenes.

[00:35:32.430] – Ned

[00:35:34.830] – Amrut
And the way I look at it is like you go to the AppSync service. You create your own API, you’re going to get an endpoint, right? And then you create whatever queries or mutation based schema fields you need to add to the schema, right? And then that’s it. You’re done. You don’t need to worry about infrastructure and scaling because it will scale based on the number of requests that are coming in. Let’s say you have millions of requests coming in every ten minutes, 15 minutes or a day.

[00:36:13.050] – Amrut
It’s going to scale behind the scenes for you. So if you try to do that on your own, you will have to set up the infrastructure in place to make sure that I know Ethan is making faces here. So you want to avoid all that. And that was actually one of the key reasons we went with AppSync because our team, we don’t have, like, DevOps experts on our team. We wanted something where we don’t have to worry about administration and maintenance and AppSync fits beautifully into that use case for us.

[00:36:52.510] – Ned
Okay. And from a pricing perspective, because you’re not paying for instances, I assume you’re paying kind of per request.

[00:37:02.230] – Amrut
Yes. There are, like 250K requests per month that are free. Okay. It’s in free tier for the first twelve months, and there are million requests per month that are free. I think that’s what AppSync offers.

[00:37:21.770] – Ethan
$0.04 per thousand or something like that. I know exactly what it was. Yeah, it’s pretty plain they spell it out, Ned, but it’s designed that if you are dealing with millions of requests, you’re not going to pass out when you get the bill. It’s priced reasonably.

[00:37:39.410] – Ned
And if you’re just trying something out, you might not get charged anything.

[00:37:44.690] – Amrut
Yes. And that’s what the good part is. Twelve months, and you can try this service out and see whether from a cost point of view, whether it fits into your business needs and then take it from there. I think it’s pretty neat.

[00:38:03.830] – Ethan
Talk to me about security with AppSync. Actually, this goes back to even GraphQL. So I’ve got this GraphQL server in the middle. I’ve got a bunch of endpoints that are going to need their own authentication of some kind. Then I’ve got GraphQL on the front end. I’ve got authorization coming into the GraphQL endpoint itself. How does this all fit into my authentication schemes and such?

[00:38:32.370] – Amrut
So from an AppSync point of view or GraphQL, just both.

[00:38:38.670] – Ethan
Well, if there’s comments to make on GraphQL, start there. And then. Yeah, let’s move into AppSync.

[00:38:43.050] – Amrut
Yeah. So if you did it in GraphQL, you’ll have to use some sort of an authentication library where if you are using a third party authentication service, this library talks to that service and makes sure that the users are authenticated. Right. But if you are in the AppSync world, you can use third party providers out of the box because you will have configurations in place for AppSync where you can connect to these third party servers and get your users authenticated using the authorization request that was sent.

[00:39:25.950] – Ethan
So is the authentication a pass through from the GraphQL client through the GraphQL server to the ultimate endpoint that’s being queried, or is it like there’s two authentications going on GraphQL client to GraphQL server and then GraphQL server to the final endpoint?

[00:39:46.770] – Amrut
No, there’s just one pass through. I think it’s not a GraphQL server doing an authentication thing per se. It’s like you will have to do the authentication piece on the GraphQL server side.

[00:40:00.030] – Ethan
Oh, Interesting. Okay. I was thinking of it more like a proxy kind of a thing, I guess. But, yeah okay.

[00:40:06.510] – Amrut
it’s a proxy for your API request, not for authentication.

[00:40:11.490] – Ethan

[00:40:12.390] – Amrut

[00:40:13.170] – Ned
That does change things. I see where AppSync is coming from, where it already has a common framework in IAM or identity and access management that it can use, especially with all the native services. If I’m already authenticated in, IAM now I can use that to figure out my authorization with all these other endpoints that I’m trying to talk to.

[00:40:35.790] – Amrut
Not only that, you can also let’s say you are using a third party authentication service like Auth Zero, for example. Right. App Sync has configurations in place where because these are like Open ID Connect based authentication standards, you can already configure them, and you can specify the endpoint where you need to, where this service is going to call that endpoint and authenticate your users. And you can do that if it’s in App sync itself.

[00:41:12.450] – Ned
Okay, yeah. Because I think we might have gotten authorization and authentication a little bit confused there for a second. Ethan.

[00:41:21.390] – Ethan
Yeah, I did that. I’m sorry.

[00:41:22.890] – Amrut
So authorization? Yes. To answer Ethan’s question. If you are using identity access management like Ned mentioned, so then because you have certain set of rules and permissions for a given user, you could directly have authentication measures in place within AppSync using IAM like I mentioned, because it has tighter integration with AWS services. You can easily configure them within the console and get started.

[00:41:54.810] – Ned
Right. No big surprise there. It’ll be easier to consume an AWS service with AppSync than anything else. But if I do have some external data source, I want to hook into AppSync that’s obviously supported. Right?

[00:42:07.830] – Amrut
Yes. But if it’s an Http based endpoint, then all you need to do is AppSync has a concept called as data source, which is essentially like where your data is going to come from. It can either be a relational database, like, for example, Postgres it can either be a no SQL database like DynamoDB. It can be an Http based endpoint. Where.

[00:42:36.270] – Amrut
To answer your question Ned, that’s what is going to meet the needs. You’re going to specify the endpoint, and then that endpoint gets called. Whenever you create a query, that’s the data source and the final data source is like Lambda resolvers, which is essentially invoking Lambda functions. And we can get into that a bit more if you want.

[00:42:59.130] – Ned
Yeah, I’m curious about that. What situations would you use a Lambda Resolver? Because it sounds like GraphQL is kind of doing a lot of what I might want to use Lambda, for, which is to customize the response before it’s returned. Do these data mutations all that kind of stuff? So why would I use Lambda as opposed to just doing it all in AppSync?

[00:43:18.870] – Amrut
Sure. What AppSync does is when you want to develop these queries and mutations, you need to be familiar with something called as a Velocity template language, which is an open source thing from Apache, but that’s what it’s using. I’ve always tried to understand. Why did the AWS team ever choose this VTL language? Because the syntax is hard to read. But again, that’s their way of doing it. Then let’s say you want to bypass all that you are familiar with something called as JavaScript, which is where you want to write code.

[00:43:59.770] – Amrut
So you want to be write lambda functions and use the serverless technology. What AppsSync gives you is like a type of data source where you can invoke this Lambda Resolver whenever a request happens to this endpoint, and then it depends on what you want to do in Lambda. Like in your Lambda, you can query other endpoints directly, you can make Http requests, or you can perform some analytical operations. So that is another cool feature. I think that was launched pretty recently, actually, in June last year, and it’s been widely used.

[00:44:44.750] – Amrut
I think we we’ve given up on writing VTL, and just write Lambda functions.

[00:44:53.670] – Ned
You do have the potential to add way more complexity there, because you can pretty much put whatever you want in Lambda and have it do it.

[00:45:01.530] – Amrut
And then, of course, if you’re more familiar with Lambda, you can take advantage of all the good things that Lambda functions give you. That’s a neat addition to it.

[00:45:15.270] – Ethan
Amrut, I got a kind of a concluding question for you. You’re in AWS world. You code in that you develop in that that’s where your infrastructure lives and so on. And so AppSync was the obvious choice for your GraphQL needs. Is there a scenario you can imagine where you wouldn’t have chosen AppSync? You might have gone a different direction for GraphQL.

[00:45:42.790] – Amrut
For example, could you clarify that.

[00:45:45.370] – Ethan
Maybe you’re multi cloud. Maybe you’re on Prem. Would those things change your interest in AppSync? In other words, is AppSync the best fit if you’re all in on AWS and so you just use App Sync. Otherwise you would use some kind of an independent or a third party GraphQL server.

[00:46:04.070] – Amrut
I think GraphQL will meet most of your needs if you ask me. Like, for example, let’s say I didn’t want to do AWS. I just wanted to maintain my own thing. You can use GraphQL server and set it up on your own, and then you can have multiple. Whenever you want to interact with different data sources, you can make sure that your GraphQL server. The problem with that is you’ll have to take care of maintenance and administration and things like that, right? That’s the headache that AppSync takes care of.

[00:46:45.090] – Amrut
But yes, to answer your question, you can go with another. You can just use Apollo like, for example, and just do GraphQL on your own and forget about it if you want.

[00:46:57.090] – Ethan
Okay, fair enough. Well Amrut, thank you for sharing about GraphQL AWS AppSync and your knowledge here. If folks want to follow you on the Internet, read more of your stuff, et cetera. How can they do that?

[00:47:09.330] – Amrut
So I write technical blogs on Medium. So one of my Amrut Patel dot medium dot com is the URL for that. On Twitter, I go by the Twitter handle at Amrutdecoder. And I am also on LinkedIn. If people want to connect with me.

[00:47:33.210] – Ethan
Well, again, thank you for sharing your time. Thank you for raising your hand. I believe you contacted us and said, hey, I got stuff to talk about. This ended up being a very cool conversation. So it’s been wonderful to have someone that’s not pure infrastructure and Ops, someone from the Dev side to come in and chat with us on Day Two cloud because Ned, as we know that is the reality. It’s both infrastructure, Ops and developers all working together in the modern world. So it was nice to have you from the developer perspective.

[00:48:02.730] – Ethan
Come and chat with us. If you want to follow Amrut on Medium on Twitter, et cetera. All the links will be in the show notes at Packet Pushers dot net or Day Two Cloud dot IO. So again, Amrut, thank you for appearing. And if you’re still listening because you wouldn’t be hearing this if you weren’t virtual high five to you for tuning in. You’re amazing.

[00:48:20.130] – Ethan
If you have suggestions for future shows topics you want Ned and I to cover, we would love to hear them hit either of us up on Twitter at day Two cloud show. Ned and I monitor that Twitter account or you can fill out the form of Ned’s fancy website. Ned in the cloud dot com.

[00:48:33.630] – Ethan
Now we know a lot of you because we watch the geoips you’re listening from Silicon Valley. Maybe you’ve got a way cool cloud product you want to share with our audience of IT professionals. You can become a Day two Cloud sponsor. In doing so, you will reach several thousand listeners, all of whom have problems to solve and maybe your product fixes their problem. We are never going to know unless you tell them about your amazing solution. Find out more at Packet Pushers dot net slash sponsorship. Until then, just remember, Cloud is what happens while IT is making other plans.

More from this show

Day Two Cloud 174: Building Kubernetes Clusters

On today's Day Two Cloud podcast we walk through how to build a Kubernetes cluster to support a container-based application. We cover issues such as what constitutes a minimum viable cluster, rolling your own vs. Kubernetes-as-a-service, managing multiple...

Episode 121