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.

• Twitter: @mavi888uy
• Instagram: foobar_codes
• Blog: marcia.dev
• YouTube: FooBar Serverless

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 back or many types back and then you can, in your request, you can ask for exactly the same, the right fields that you want from this type. Because that's another problem with REST in general for mobile developers that they need to over-fetch a lot of information a lot of the time and do the filtering in the client, and when you're working in mobile apps then if you're fetching a lot of information, that's a lot of bandwidth, and you might need to do a lot of requests to the back-end and GraphQL will unify everything in one response request. So it's in a way quite efficient for mobile development.

Jeremy: Yeah, you mentioned over-fetching, and I think that's one of those things where you run into that with rest APIs where you know, again, you can't – and you can design REST APIs to act as like a GraphQL server, in a sense where you limit what comes back. But you also have that problem of under-fetching, right? So you bring back your list of products, but then you want to get the product details and you have to make additional calls.

Marcia: Exactly. So the idea is that you can fetch many resources, many types, in one request. So you don't need to fetch one and then fetch another one, and fetch another one. So that's kind of one of the benefits of GraphQL when you use it. So in general it’s a good combination to have both REST and GraphQL, so, for example, if you have, in one of the projects I work [on], we had a back end with a GraphQL, but at that time AppSync didn't exist, but we were just working with plain Apollo, and it was really good because we have 16 different types of clients. So from which we maintain four, the rest were maintained by different types of people. Some of them were consultants that were paid to do this specific application for a smart TV, for example, and it was never maintained again. So GraphQL really performed because you don't need to really synchronize a lot of documentation back and forth because with this contract, everything is specified there and then there is no versioning in GraphQL. Everything is done in one contract, so you evolve your API with time, and GraphQL has kind of ways to do that. So if you do it right, it's very easy to be backwards compatible and support all versions with no problem. And that's one of my favorite features because when you're working with REST, having version 1.2.3.1

Jeremy: Does anybody actually version and then point though with REST API? It's always, so I’m like, well, we're on version 1, but it's really like version 9 at this point, because you keep changing things.

Marcia: I have seen version 49, so yes.

Jeremy: Some people do. But what I like about GraphQL is that fact where it's like you can add a new field or you can add a bunch of new fields. You can add nested fields and things like that that that you just keep adding to your schema and really the weight or the need for maintaining backwards compatibility – it’s all done via the clients. Clients can just enhance themselves by using these new endpoints, but you don't have to get rid of them because they're not being sent down in every request for new clients.

Marcia: You have a choice to get rid of them. For example, if you are changing something in your backend and you're not just returning that field. So they have these two concepts that is hidden files and deprecated files. Fields, sorry. So you can play with those concepts and start like removing attributes from your types if you need to or you can tell this type is not valid anymore. You still can return it, but we will not like – it’s a way to communicate with your clients because at the end of the day, sometimes you cannot return always everything back because the backend changed.

Jeremy: Eventually. That's what I actually love that metadata deprecated stuff that you can put into GraphQL. That’s another really cool feature. So let's go and talk about resolvers for a second. Because I think this is one of those concepts too, where people that are new to GraphQL, what exactly is a resolver?

Marcia: I said that, at the beginning, that AppSync is a kind of already a packaged GraphQL platform that where you need to put your schema, that is the contract between the client and the server, and then the resolvers. So the resolvers are the unique way that your GraphQL middleware kind of component will connect to the different microservices. So that's very proprietary from every application. It’s basically a set of instructions. So imagine that one of your microservices, we can call a data source - that's the word that AppSync uses - because they might not be microservices per se. They can be things like a SQL table, like a relational database. So imagine that one of these data sources is a relational database and we have type, that is, I don't know, order. We have a table that is order. So we want to link our GraphQL type to this table. So the resolver will need to understand SQL, so we need to open a connection to that data source, and do Select All from the orders table and if you have some condition or if you have some fields that you need, so we'll need to write this SQL query and then it will need to get the results back from the table, parse it in a way that it becomes JSON, that is what GraphQL puts out in the response. So it's doing all these translations between the client and the server. So it is a very, very critical part from GraphQL.

Jeremy: Yeah, and I hear a lot of people when they say GraphQL server, they sort of think that’s sort of the end-all, but it's really an intermediary, where you have a client request that goes to the GraphQL that sort of does this assembly or calls all these resolvers, puts everything together for you, but it's really not the server. That's not where your data’s coming from.

Marcia: GraphQL is not a database. It doesn't have any information itself. It's just handling requests and pushing it to the other side. So it's kind of just translating in the middle. Like if you were speaking English and I will be speaking Spanish and we'll have somebody in the middle that is translating.

Jeremy: Well, you speak beautiful English, so I wouldn't worry about it. But so all right, so let's get into AppSync now, because this is where I think we can start putting all this stuff together. So you've got GraphQL, you've got the structured language that you can use. You've got this concept of resolvers, so AppSync is serverless or in the sense that we don't…

Marcia: It’s a managed service.

Jeremy: Yes, so we don't have to worry about the back end servers. So how does AppSync work? What does that do? What's that flow via AppSync?

Marcia: So when you start with AppSync, you need to set up your schema, so you need to find all the types of your kind of GraphQL application. What is GraphQL returning and all the operations that the users connecting to these AppSync or GraphQL servers can do. So you will decide, okay, they can create orders. They can update orders. I can see all my orders and these are my types, my orders, my products. You find all that in the schema. The next step is to set up what are your data sources, where the data for populating this schema comes from. So you need to say OK, I have an SQL table, I have a Lambda, I have an ElasticSearch, and you connect the types with the different data sources or the operations with the different data sources and when you do that connection is when you build the resolvers, that kind of linking between the schema and the data sources is when you need to write the resolvers. So when you use AppSync a lot of things come out from the box if you're using AWS services. So, for example, while the schema you need to write that you cannot escape, but the data sources it has kind of really native connection with Dynamo, Lambda, Elasticsearch, RDS. I think the next one is HTTP in general also, you can call whatever you want. So those are the five data sources that you can use pretty easily and your resolvers need to be written in a specific language. So it's using this velocity language scripting, or velocity template language, VTL. I'm very bad with acronyms - sorry. And that's kind of, one of the trade-offs when you're using someone else’s platform, that you cannot decide which language you want to write your resolvers in.

Jeremy: I don't want to interrupt you…

Marcia: Sure, you can interrupt as many times as you want.

Jeremy: Okay, so before we move on though to getting into the VTL. So we mentioned these data sources and you said Lambda, you said Dynamo, HTTP, Aurora, and ElasticSearch. So those are five very different types of data sources. And so when you're talking about building a resolver, when it's DynamoDB or it's Aurora, it’s ElasticSearch, AppSync will actually be the resolver for you, or the resolver will be built in.

Marcia: You have templates So, for example, if you're using Dynamo, you can just go click on Dynamo and then it will show you a template. Okay, you want to fetch one? You want to fetch two items from a list of items? Or do you want to insert something on Dynamo? And you just click on the template and it will create the resolver for you. Really easy. The same with Lambda. If you want to invoke a Lambda, it kind of comes out all from templating. So it's very, very easy to get started to writing those resolvers.

Jeremy: But the idea would be is that essentially that VTL, the template that you create that can do that translation between DynamoDB and your schema, that kind of acts as your server, the other end of the GraphQL…

Marcia: That’s your business logic, kind of.

Jeremy: It does that business logic. And then if you do want to do very specific business logic, though, then you can do that. Um, you could do that with a Lambda function or call another service, another HTTP, or something like that.

Marcia: VTL is very powerful. So that's something. Sometimes it happens, people underestimate what kind of things you can do. You can do really a lot of things only by playing with VTL over Dynamo, it’s super crazy the things you can do. And then if you want to do some complicated operations, you can always call a Lambda and the whatever from Lambda. Then also AppSync has this feature called Pipelines, where you can connect, for example, a Lambda, different data  sources together. So imagine that you're fetching a profile metadata, and you have to do like one of the fields in that metadata in Dynamo. We have the profile information metadata and one of the fields is a link to a photo in S3. So then you can hook it with the Pipeline and fetch that image from S3 and create this kind of signed URL that you can return back and show in your web app. You can do that pretty easily with AppSync on this Pipeline concept that they have, that you can connect as many resources, data sources as you need, together to return something to the client.

Jeremy: Yeah, that's a pretty cool feature. So what else about AppSync? What are some of these other features? Because it goes beyond just being a managed GraphQL server.

Marcia: Out of the box, one of my favorite things is security and authentication, because that's always something. If you have a mobile app, then you always have some kind of barrier between like all your data, your personal data and the world. So that comes out of the box with AppSync so you can get started super fast with Cognito. It’s super simple to set up, and then you have username, password or Facebook signing or Google signing, or whatever you like from Cognito. And then there’s also more specific ways to authenticate. But I think the most common ways to use Cognito [are] super simple. To get started, you can use an existing using user pool or create a new one. Then you can even filter inside the fields that you don't want to show this information to everybody else but you. For example, if we go back to the profile example, that you can fetch this profile information, and if it's Jeremy's profile, I will be seeing some filter out data and Jeremy will be able to see all the data, like your email address or your phone number. So you can create that with very simple VTL, connecting Cognito and Dynamo, for example, without writing a line of Lambda’s code.

Jeremy: Yeah, and I think people need to understand the importance of that, right, because I've worked with GraphQL before, and then you've got security where it's sort of like, well, GraphQL doesn't do security. It's not part of the specification there. Your resolvers handle that. If you have to write that code into every resolver and then manage it across all these different things, it gets really complicated, so the fact that AWS has Cognito and you can do the federated logins across all those different social networks and things like that, or plug it into Auth0 or even write your own custom one.

Marcia: You can do whatever you want, and there's quite a lot of – they keep on adding different authentications ways, but I think Cognito, if you want to get started, it’s the easiest way and it's really out, integrated with all the mobile kind of platform development that they have AWS build so all the libraries and everything works really well with Cognito.

Jeremy: All right, so why don't we talk about maybe some of the use cases? Because that's the other thing about AppSync where I think it confuses people. It sits or it originally was sitting under the mobile, it was classified as a mobile service, right, because it did some, I think actually, that you could do web sockets originally. There's some real time stuff that you could do there with it. What are some of those use cases that you can use it for – not just with mobile, but with just a web app or, you know, any other service?

Marcia: So I think the easiest use case is building mobile apps. So, as you mentioned, AppSync supports real-time communication out of the box, so that's one of the benefits. If you have an app, you don't really need to sync it, ask the server every 10 minutes, “Have you updated the information?” So that happens in the background with AppSync? So that's a feature a lot of mobile developers are looking because sure, you can have web sockets with API gateway, whether something the client will need to create all the support for that. But with AppSync, it just comes out of the box when using AppSync. So for me, the strongest use is to build mobile apps, but in general, whenever you have multiple microservices and you need to unify them in some kind of way, I think also it kind of works very well. If you have a client applications, not only mobile but desktop, some things like that, that works very well. Also, it's a very good way for managing when you have these client applications that you cannot control, like in our case, that we have all these like different apps that were managed by externals and in a way, it's kind of easy to have this auto documentation in place because, let's be honest, we are very bad at writing documentation, developers, and when you're in a very agile world, then things tend to go faster than the documentation goes. Having something that kind of enforces the documentation just by its nature, it makes life so much easier.

Jeremy: I was told very early on in my career that the code is the documentation.

Marcia: Exactly. And GraphQL is proof of that.

Jeremy: I don't agree with that [that the code is the documentation]. But anyways, that was what I was taught. So some of the other things it does too is like offline sync, right? So if you make changes on a client, it'll store that information and then when you do get connectivity, that'll sync up, and then you obviously have conflict resolution that it needs to deal with and AppSync does that as well.

Marcia: Yes, that's the simple conflict resolution. So if you have very weird things that you might need to create some kind of resolvers there but out for the basic things, it just does it on the back end. So it's important to understand when you use AppSync in the client, you will need to have a library in your client to handle all of these things. That's kind of — it is not something that happens magically. You will need to use a library to connect to AppSync in your client, either web or mobile app. So it will do all the connection and the magic between the server.

Jeremy: All right, so what if we, I don't know if we can do this via audio. But let's say someone's driving in their car, and they just want to get a sense of wiring up a data source in AppSync. Now, obviously they'd go and watch one of your videos. You've got plenty of them on this. They probably can't do that when they are driving or mowing the lawn.

Marcia: What? No, no, it's not a good idea. Don't do that.

Jeremy: So just quickly, just walk us through what that process might be.

Marcia: So first you create a schema, and then you need to link the schema with the data source. So imagine that our data source is a Lambda and we want to invoke that Lambda. So basically, what we will do is just write one line of VTL that says invoke this Lambda and you pass the parameters that are coming in the request. It's super simple. Then you need to write the Lambda that will do all the magic and then you will return from the Lambda some result and then you need to write another piece of VTL that will be the response resolver that will grab that response that Lambda did that we matched in the destination that can be returned like it is to the client that will just grab whatever is in the in the response of Lambda and push it out. So that's [a] super simple kind of example. If you want to connect to Dynamo, what you do is you write a Dynamo query like the ones [that] are very similar like the ones you write in the recent AWS SDK, just with a little different format. So you will put, I get item, you will create this kind of params object where you put, I don't know, the key, the table, and whatsoever in the VTL. Then you need to write again another velocity template for the response that if you are getting just one item, it's just basically whatever Dynamo returns you just push it out because AppSync knows that format and can do all the transformation for you.

Jeremy: So bottom line is learn VTL.

Marcia: Yes, yes, yes, yes, yes.

Jeremy: Awesome. All right. So what about performance of this? Because I've heard stories, people are like, "Oh, yeah, super slow when I'm trying to connect multiple data sources", things like that. What is your advice around, or what are your thoughts on performance?

Marcia: Like everything in life, you need to understand a little bit the things that you're connecting together when you try to go to production. if you're playing in your home, you might not care that much about performance. But in general, my experience of the people that I've been talking to [about the] experience of AppSync, it's very positive. But when people start telling you about performance, it's because they have done some kind of mistakes in their architecture. So one common mistake is people don't want to learn VTL, so they do Lambdas for everything. And Lambdas are quite fast, but it's an added latency in your system. So if you're calling Dynamo and the VTL can do all that, why call a Lambda that might be cold, that you might need to launch and deploy and call the AWS SDK and return and fetch. So that's one thing. Then another thing is that people like to scan in a Dynamo table.

Jeremy: People love scanning DynamoDB tables. I don't know why.

Marcia: Not an efficient thing you can do in Dynamo table. They're not meant for doing that, and AppSync is so easy to get started that it's very easy for people to start scanning Dynamo tables. And that's where performance gets totally kind of rough. If you don't know scanning Dynamo tables goes in kind of one row at the time and Dynamo is a big data source, so you have lots of items there, in general. Also, it's not meant for do[ing] that. If you want to find data use other ways, you can index that data or then put it in ElasticSearch or I don't know, use something else. Not Dynamo tables. Then another thing that people like to do is to sometimes connect to a HTTP. I know it's a data source, but you need to be aware that if you're connecting to an HTTP data source, then you're adding more latency there because that's going outside to the Internet. So everything you do has some costs in general. It's not like when you're inside your own network and everything is ready to fire. So I think those kind of things, it's good just to have it in mind and see how you can improve that. Can you build a cache in front of your HTTP somehow? Or can you do something to speed that up? If it's something you need to do, it's something you need to know. But sometimes it's better to avoid that and put everything in Dynamo.

Jeremy: Yeah, and I've seen HTTP calls just I mean, it probably takes 90 milliseconds just to set up the HTTP call, and then you have the latency that's added there.

Marcia: Exactly, and then you have, like, you need to [do] some weird querying that people don't know. So they call a Lambda. The Lambda then calls an HTTP, and then it returns back, and I have seen all those things, and then, sure, performance is not the best.

Jeremy: So bad architecture or bad queries. I mean, that's the thing. So I think that's one of those, that's that learning curve when you start working with all these services anyways, understanding how they stitch together and what's the most efficient way to do it. All right, so that's great. So let's actually talk about implementing this now in a serverless project, right? So how would we go about doing that? You mentioned sort of client libraries. What do we have to do in order to start using this?

Marcia: So the first thing is to create the backend. So you can either go to the AWS console and click, click, click, click around, and have your GraphQL backend using AppSync. Or, if you want to have a real production application, you need to use some kind of infrastructure as code (IaC). That's my recommendation. Then you can build the whole AppSync service out of configuration files that you can replicate in different environments if you need. So AppSync supports CloudFormation. So if you're using CloudFormation, you can use that. I've been using it with Serverless Framework because they have a really nice plugin, where you can basically build all your AppSync infrastructure, which has writing some files and creating some really simple specification there. So you create your schema file, you create your resolvers file. And then you have this plugin in your infrastructure page that, like in the serverless.yml, if you're familiar with serverless framework, where you just type all these links. Okay, this is my data source. This is my security. These are my resolvers in this case. These are my resolvers in that case. And it's very simple. And then that means that you can have the same GraphQL backend when for dev, and staging, and then production. You can create three different stages for that, or I don't know, whatever you need in your production. So that's the first step to create good production backend. The second step is to create your clients. So that's, you will need to use AWS Amplify. That's the easiest way, in my opinion. AWS Amplify is a library, a client library, that AWS has created, this open source, and it's kind of, I think it's called like a cloud for enabling cloud native applications or something like that. Just a fancy naming.

Jeremy: CDK. Cloud Development Kit is that the...? Is that different?

Marcia: No, no, no. I don't know how they come up with these names, But yeah, the thing is that this library is really cool because it integrates really seamlessly with a lot of the cloud services. So you can also use it for connecting to API Gateway, if you're using API Gateway. So it's not only for AppSync. So it has features like it creates your authentication so you can connect to Cognito. You can get your session there and then you can use it for a GraphQL for AppSync. So when you set up your GraphQL backend, you will get like an URL back and then some other information. With that information, you put in your configuration file of Amplify and it's kind of working. It's super simple to stitch together and the same way you can configure Cognito, you have to know your Cognito user pool and Cognito entity pool. Some other thing is you put it in your configuration file and then you can start calling the different APIs from that library, like auth. I think signing auth login or something like that. And then it's like GraphQL get or it's just very, very straightforward to use.

Jeremy: So if you want to run, like once, you have that all set up and you're logged in and is it Amplify? No, it's not Amplify, but Cognito, for example, same with Auth0, has the login interface for you. You don't even have to write that in your client application. Like that's just done for you.

Marcia: Yeah, you can do that as well. But if you want to have an application that looks like the whole application there, you can also do that with this Amplify library as well.

Jeremy: Um, so once you're all logged in and you're ready to go now you want to run a query. How do we do that?

Marcia: So the general, you write a query. I usually put it in a separate file in my client application because you see here for me to manage those. So I have a file where I have all my queries on I will write, I don't know, give me all the videos, for example, or all the orders with these attributes I want to see from the order. And then I go to where the logic is executing and I shall use the Amplify library, the GraphQL part, and I just do, "okay, get me this," and you will get a JSON by just passing the query.

Jeremy: We didn't talk about mutations. That's another...

Marcia: No, we didn't talk about queries and mutations. That's part of GraphQL actually.

Jeremy: Yeah, but just so obviously queries are when you actually call it, and that's what the query language . But then you can also send updates and make changes to different things. So you're signed in, you can write your queries, you can run your queries, mutations, so forth. That sign in, that like you mentioned, the Cognito user pool. The library automatically sends that authentication token...

Marcia: Yes.

Jeremy: ...up to AppSync.

Marcia: Yes.

Jeremy: And then AppSync uses that and then all your ACLs, your controls, and that's all done in your velocity templates.

Marcia: Yes. Exactly. And for example, when you pass like your login as Jeremy, and you want to see your profile. So, Amplify will hook in your Cognito ID, and then AppSync will see, oh, your Cognito ID is the same as the one that I'm allowed to show you the email, birthday and whatever, and that's all done in the resolvers. So it will return the whole profile to you so you can see it. But if I want to fetch your profile, it will say no, Marcia is not the owner of this record. So she will be only to see the name and the photo, for example. That's it.

Jeremy: So you mentioned, okay, so you're putting your filter, the ability to filter what certain people can see. We're doing that in VTL.

Marcia: Yes.

Jeremy: Maybe we're doing some of that. Would we do it? Would we offload any of that into Lambda if we were using a Lambda resolver or you still would want to do it at the VTL?

Marcia: Well, then, it's the question on who owns the data, and that's something, at least with AppSync, I'm still trying to figure out how to really architect my application, my graph qualifications, because I've been using GraphQL with microservices, and usually I do the filtering in the microservice because the microservice knows the data, knows who can see it, and I don't want to leak that information out. But with AppSync, at least applications and have been building, they are mostly contained into Dynamo tables and Lambdas. So I think when I'm coding this that AppSync is the owner of this data and, then I do the filtering in the resolvers. So I think it's always a question of who owns the data and who is able —where is the level that you want to leak the information out? I don't know if it's clear.

Jeremy: I actually I totally agree with you because I mean, that's always the problem you have with a lot of the security things where I mean, obviously, when you're using API Gateway and you're using Cognito or OAuth and you can send in, you can do the custom authorization, and then you get back a policy document and then you need to use that policy document, that can restrict certain higher levels of things like whether you have access to a particular endpoint. But if you want to take that information and then actually build logic within your application to say, "don't show this if a user isn't in this group" or whatever, you can go even further and do that at that level. But now you've got some of your security happening at this level, then another there, and I guess that maybe even begs the question: Where do you put your business logic? I mean, how much do you want to be putting business logic into VTL or is that something you still would want to keep out of AppSync?

Marcia: I think this is a really interesting question in general for serverless because when we are working with servers, we know that the server is the gatekeeper of data and [these are] the quite clear boundaries. But now we have the serverless world where there are all these kind of functions and different managed services that have access to the data, so how [do you] regulate that? That's something I think is a bigger question than AppSync. It's something I wonder myself every time I design a serverless application, like who owns this? Who has the power to access? Who can see it all and who can't?

Jeremy: Right. That might need to be a conversation for another day. So just a couple more technical questions that I have. So custom domains with API gateway, you could stick a nice little custom domain on it. You can't do that with AppSync.

Marcia: No, not out of the box, as you can do with API Gateway. So you need to go through the CloudFront distribution and do like Route 53 and hook up there the thingy, because in general, AppSync is thought in a way that nobody really will see your URL because it's an application to like, your client is connecting to your server, so you really don't care. So I think that's the thought when when they have not put that feature in. Maybe they put it in the future. I have never needed it, but you can do it if you go through for the distribution in CloudFormation and do all these kinds of things, then you can link the world that AppSync gives you to the one that you get them.

Jeremy: You just set it up as a custom origin or something like that.

Marcia: Something that, I have not done it so, but I have read the documentation is there if you need to do it. You just Google. I've seen custom domain, and it's the first thing that will appear. AWS information on how to do it.

Jeremy: And it's probably not necessary, like you said, with a normal, if it's your own app, maybe if you're exposing it to like a public GraphQL API, maybe you'd want to do that.

Marcia: Yeah, if you have Facebook or GitHub or something like that. Maybe you care about, most of the use cases at least I've been working with, and in general, people have been working in, it's just like you have this mobile app and you want to hook it to AppSync.

Jeremy: And most people aren't Facebook or GitHub, so you don't have to worry about it.

Marcia: Maybe here Facebook or GitHub, I don't know. Will you put it in AppSync? I don't know.

Jeremy: Probably not. Not if you're Microsoft or Google, probably. So last question, because this was something that I know has been asked before. So API Gateway handles stages, which is kind of a cool little feature. You can't do stages directly in AppSync, though, right? You just have to publish, like, a different version of it or different endpoint?

Marcia: Publish a different application that will have its own lifecycle. That's what I was saying when I was talking about the implementation to use the infrastructure as code, so then you can create multiple kind of stages, fake stages in a way that there are different versions, like different publish applications with the same configuration, just with maybe the name changed and some data sources changed and things like that, that's for each of the stages. So you have to fake it, in a way.

Jeremy: Awesome. All right, well, listen, this was fabulous. Thank you so much, Marcia, for being here and honestly, thank you for everything. Your FooBar videos and stuff like that are excellent. Great, great tools. If anybody's trying to learn serverless, definitely go check that out. So besides that, what else? How else can listeners get get ahold of you? I mean, you're pretty much out there, but...

Marcia: I'm very active [on] Twitter. So that's the place I write. So usually I'm there putting, some tweets, and also on Instagram. I use Instagram for conferences. I go there quite often, so I do a lot of live stories and share a lot of information as it comes out from the conference. So those are the two social networks I use besides YouTube. So you should find me there.

Jeremy: And that's @mavi888uy for Twitter and @foobar_codes for Instagram. And then you have your blog is marcia.dev and then if you go to YouTube, just search for FooBar serverless and you can't miss you.

Marcia: Yes, exactly. I picked the worst keyword in the world. FooBar.

Jeremy: But nobody ever uses that. What you talking about? Well, this has been awesome. I will get all that information in the show notes. Thank you so much.

Marcia: Thank you for having me.

Episode source