Episode #3: Serverless GraphQL using AWS AppSync with Marcia Villalba

About Marcia Villalba

Marcia Villalba is an AWS Serverless Hero and a software engineer from Uruguay, currently living in Helsinki. She currently works as a Full Stack developer at Rovio, and has her own consultancy company, Unicorn.codes. Marcia also hosts her own YouTube channel, FooBar, creating fun and creative videos and tutorials that focus on how to use AWS serverless technologies and managed services. She loves to help others in the serverless community learn about migrating to serverless, and publishes courses, all of which you can find on her blog.

Transcript

Jeremy: Hi, everyone. I'm Jeremy Daly and you're listening to Serverless Chats. This week I'm chatting with the fabulous Marcia Villalba. Hi, Marcia. Thanks for joining me.

Marcia: Hello, Jeremy. Thank you for having me here and I hope my cat is not meowing because she's already meowing.

Jeremy: That's fine. My kids love cats. I'm sure the people listening will love them as well.

Marcia: She always appears in my video. So it's part of FooBar.

Jeremy: Perfect. So you are a full-stack developer and an AWS serverless hero. So why don’t you tell the listeners a little bit about yourself and what you've been up to lately.

Marcia: Yes. So I’ve been doing serverless since 2015 so Lambda was launched in November 2014. I started quite early on more or less when API gateway was announced and was able to connect with Lambda. And since then I've been just working on different types of projects. My first project was to migrate something to serverless and then I've been working on greenfield projects most of the time. Then one of the things I really like is to create content. So I think, besides my show, that's what I do the rest of the time - my shows, create YouTube content, and a lot of courses. I have a small consultancy where I help companies with workshops and training, some things like that. So I spend all day doing this serverless stuff.

Jeremy: I know that feeling. You have a blog too, right?

Marcia: Yeah, as well. My blog is not really a blog per se. It’s more or less where I gather all the content I create in one place. I used to use Medium but I quit. So I think blog is more like I can do whatever I want with it. It's just a place to have my content. But most of the content I create is video. It's the place I feel more comfortable. So YouTube is the place I hang out. I just put all everything there, but well, the blog is good too.

Jeremy: You do an amazing job with all of the videos. So thank you so much for all that stuff. So I wanted to have you on today to talk about AWS AppSync. So I've seen I've seen you do your talks before. You have a great talk on the subject and you've done videos on it and things like that. So maybe let's start by, just in case people don't know, because I think this is one of those – it’s not obscure if you are in this world, but if you're just kind of getting into it, I think AppSync is maybe an obscure sort of thing. And why that's different than API Gateway. Maybe you could tell us what is AppSync exactly?

Marcia: Well, in a few words, AppSync is is a GraphQL service. So it's managed GraphQL service by AWS. It’s a platform where you can kind of – AWS will take care of all the heavy lifting for the GraphQL. And you just basically need to put your schema and create your resolvers that are a bit. But basically the schema and the resolvers are the two proprietary things that you need in order to have a GraphQL application. The rest is very generic between every GraphQL implementation. So AWS create this platform and then you just do the smallest amount of work you can and get a working GraphQL server. And that's really good for, for example, creating mobile applications. It's really fast to create fast back-ends for mobile applications or to interconnect multiple microservices or do all kinds of things. So it's a very interesting service.

Jeremy: So it's basically like a managed Apollo server.

Marcia: Well, yeah, Apollo has their own platform as well, so they have their own AppSync. So, yeah, this kind of concept is – when I talk in my talk about the ways, because GraphQL is a specification. It’s not something that somebody –well, somebody wrote it down and then different people implement in different ways. So there is, like, three ways of doing GraphQL, as I said. Either you write your whole GraphQL specification yourself. You are a hardcore developer. You want to have your GraphQL done in Cobol and then you do it yourself - I don't know why. Then the most common way is that you use some library like Apollo. That's the most popular library that you just put it in a server, and maintain that server and this kind of serverless way of doing GraphQL is using a platform where all this heavy lifting of maintaining the infrastructure, and do we know the small connections that needs in order to hook up your library to your server. That is already done by the platform, and you just focus on your business logic. That is the main mantra of serverless.

Jeremy: Awesome. So let's actually talk about GraphQL specifically because again, it's another one of those things where I think a lot of people are very used to REST APIs that has been the way to do things for quite some time. I think it was Facebook that came out with GraphQL and…

Marcia: Yes, GraphQL was released by Facebook, but now it's owned by everybody.

Jeremy: So maybe just quickly explain what is GraphQL exactly?

Marcia: So first of all, GraphQL and REST are not like enemies. So you do not have to choose one or the other. And I think that's an important starter for the discussion, because people are like, well have my REST endpoints to use GraphQL. No, we are not talking one or the other. They're two different things. So GraphQL is a specification that when you implement, usually it sits between all your microservices and your clients, and it’s, thus, like an entry point for your application. So you can, instead of having multiple different endpoints and point to the different microservices independently, you can have one entry door and that's really convenient. For example, if you're doing, um, I don't know a mobile app and you have multiple different microservices with different people working on them, then you can combine all these requests and responses into something that is like a contract between the client and the server as a big entity. So that helps a lot of the client developers, because that's one of the big problems when client developers are starting to work on a project, they need to [really understand] the whole backend architecture, and sometimes there is really not a lot of need for them to understand that. So GraphQL will provide a contract where all the possible operations are specified. All that is a strongly-typed language. So all the operations request a response with really clear defined types that they have strongly-typed. So you know exactly what you can put in, what you can get out, and then when you do these operations that you'll get a type...