DEV Community

Serverless Chats

Episode #28: Amplifying Serverless with Nader Dabit

About Nader Dabit:

Nader Dabit is a Developer Advocate at AWS Mobile working with projects like AWS AppSync and AWS Amplify. He is also the author of React Native in Action, & the editor of React Native Training & OpenGraphQL.


Transcript:

Jeremy: Hi, everyone. I'm Jeremy Daly, and you're listening to Serverless Chats. This week I'm chatting with, Nader Dabit. Hi, Nader, thanks for joining me.

Nader: Hey, thanks for having me.

Jeremy: You are a Senior Developer Advocate at Amazon Web Services. Why don't you tell the listeners a bit about yourself and your background, and what you do as a Senior Developer Advocate?

Nader: Yeah, sure. Before I joined AWS, I was basically a front-end engineer, mainly a mobile engineer for the last, I guess four or five years before joining AWS. I kind of come from a traditionally front-end background, but the team that I work on is the mobile team, but we cover Amplify, we cover AppSync, we also cover Device Farm and the Amplify Console. And yeah, we have a couple of developer advocates, I'm one of them. And our role is very kind of lenient in the sense that we don't really have a traditional role as someone might think of maybe a developer evangelist or something.

I think it's really team dependent on what that role actually means. But to our manager, it's a way for us to have a lot of leeway in what we do, so we can write code. Most of the stuff we do is open source so we can contribute to the open source, we can speak, we can write docs, we can write blog posts. Whatever we feel is going to contribute the most to moving everything that we're working on forward, we're able to attack that and work with that.

Jeremy: Awesome. So, speaking of things that you're trying to move forward, you mentioned AWS Amplify. Which is this really cool project that Amazon is working on. Why don't you give the listeners a 30,000 foot overview of what exactly that is?

Nader: Sure. The Amplify was first, I guess, introduced as a client SDK for web and for React Native that basically allowed you to interact with things like API Gateway, things like AWS AppSync, Cognito, much easier I guess, than some of the old way. Before you were using probably the AWS JavaScript SDK, we just added improvements that were really meant for interacting with these services from client apps. The Client was first introduced, that started game gaining steam pretty quickly.

We then introduced the CLI at the... I think the next reinvents. I think it was actually, I'm not sure exactly when the CLI was released, but it was really after to the Client. And the CLI is something that basically allows you to create AWS resources in a similar fashion as you would do with something like CloudFormation or SAM or even something like the Serverless Framework.

But it gives just a different approach, so instead of having to maybe do it in the way that you're used to doing it, maybe writing some CloudFormation or maybe writing some templates with JSON or YMAL, you can just go to the command line and create an update categories versus kind of having to know what's on with AWS.

If you're coming to AWS as a newcomer, it makes a little more sense based on the feedback that we've gotten to use Amplify, because they can say, "Hey, I want an API," and in the background we'll spin up an API Gateway and point with some configuration around a proxy to pass the event into a Lambda and we'll also generate the Lambda. It's kind of an easy entry point for people, but it also is a very helpful way to generate a couple of things at once that kind of tie together, so the CLI is another part of it.

Then there's the Console, which is something that was introduced, that re:Invent 2018, and the Console is a hosting and CI/CD platform that allows you to just kind of connect to a get-repo, and then we do the build and we deploy to CloudFront with S3. It's a really nice way to deploy your web apps. We also have a lot of stuff that's been added over the last year to improve that. I would say that's the main focus, those three things, the Command Line Interface, the hosting platform and the client libraries.

Jeremy: The purpose though of these three tools sort of working together is to build mobile applications, or web applications using something like React Native or just React, or actually view an angular, like there's plugins for all that. The point though is that rather than you having to go out and use something like SAM or build all these things out individually with CloudFormation, that this is just sort of giving you a unified way to create both the front-end and the backend, right?

Nader: Yeah. I mean, we have a lot of people that are actually... there's two ways to kind of look at it, I guess. You can use the client only and still use CloudFormation and SAM and Serverless Framework and we have a ton of people actually doing that. Or you can kind of buy into the whole framework and then use the CLI as your resource creation platform of choice. You can kind of go at it both ways.

But yeah, the idea though is to build these full stack applications and to kind of, we have a couple of main focus points. One of them is around developer experience and the other is just around developer velocity. And I guess that could, maybe tied to developer experience. We want to be able to allow you to create things, and configure things, and deploy and try things out, experiment quicker than maybe you would have been able to in the past.

Jeremy: I mean, I get that you can sort of break these things up and you can use them individually. But I mean, really what you're building is sort of a philosophy around a full stack development, right?

Nader: Right, right. We think that what we're doing is a little different than anything that's kind of been out there before, I think. And we don't really have something to compare it to, but we talk about it in a couple of different ways. One of the things that we talk about is this idea of a full stack serverless development, where you're a developer, or you're a team, or you're a startup, or you're a company and you want to be able to enable a developer or a team of developers to build the front-end and the back end, versus having the traditional maybe engineering team where you have a backend developer and then you have a front-end developer.

We're looking at it like, what if a developer could just be looked at as a full stack developer like we've seen forever. But instead of the traditional full stack developer where the backend developer might be in charge of creating servers and creating a database and patching and dealing with all of the different backend resources, we could take the serverless philosophy, use that and then apply the front-end developers and merge that together and enable a single developer to build out these full stack apps, or a team.

Jeremy: Yeah. And I definitely love that idea because I do think there's a huge growth in front-end developers that need the capabilities of the backend, whether it's simple crowd apps or something like that, or something more complex. But serverless has always to me, seemed like a really easy entry point into that backend or full stack experience. But it's still hard, right? There's a lot of stuff that you have to do.

I mean, especially if you're doing CloudFormation, even if you're using something like the Serverless Framework, which makes these things really easy, there's still some barriers there and some things that you need to learn. What I really like about the way that the framework works is that you use CLI, you can create these resources, you create the front-end, create the backend. Those things are sort of tied together, but you definitely take a very opinionated approach to it.

Nader: Right, right. We definitely do. I mean, for us to be doing the amount of things that we are doing and for us to be enabling some of this stuff, we do take an opinionated approach. But when you're building with Amplify on the CLI, all we're really doing is generating CloudFormation. All that CloudFormation is available in this Amplify folder and we keep two versions of your cloud configuration. We have kind of a development version and the deployed version, that's kind of what your current backend looks like in the cloud, what it's looking like in your account.

We have the backend and we have the current cloud backend. In the backend folder you're doing your development, you're deploying. And then once the deployment is successful, we're tying that into the current cloud backend folder. You a dev and a deployed version, but really all we're doing in those folders is generating that CloudFormation. We're not really, I guess doing anything new, we're not creating any new services as far as the CLI is concerned. We're just kind of using the existing things that are out there. Just a new abstraction on top of them.

Jeremy: And I think when you're doing the level of abstraction that you are doing, you have to take an opinionated approach. But there's ways to eject. You said you're just, let's say I go through this process, I'm a new dev or maybe I'm an experienced dev and I just want to get something up running or something up and running very, very quickly. I can use the Amplify framework in the CLI, use the Console, it all works together get something up and running. But then if I have to go above and beyond that, if there's something that the framework doesn't do, how do I keep what I've done but then keep building on top of that?

Nader: I guess there's a couple of ways to do that. Of course, Amplify being just a abstraction on top of an existing abstraction is going to be either... because also we're fairly new, we're going to be a little bit behind or a lot bond depending on what you're trying to build the current feature set of something like confirmation. Once you start building with Amplify, you might run into a situation where you need something that we just don't offer.

You can either create your own CloudFormation within the Amplify project, then you can run Amplify Push, and this will kind of allow you to take what the CLI offers you and add to that maybe your existing knowledge of CloudFormation. Or you can just eject completely out of the Amplify workflow, and if you have something and you need to, I don't know, maybe take this to the next level or whatever you see Amplify limiting you for whatever reason, you can completely just take that and move that to whatever other framework that you'd like to use.

Jeremy: Going back to the opinionated approach too, I mean, in terms of what the roadmap looks like for this, because obviously you're adding a lot of features and we can talk a little bit more about that later. But is this something where you see, just keep adding feature after feature or is it something where you feel there is a target market for this, and that as long as you cover a certain percentage of use cases that probably is going to be the philosophy that you stick with?

Nader: Definitely target market, there is a target market for this. We're growing super quickly, I think we had a 400% increase in community contributions around content this year, 2019. Super big increase in downloads and usage and all that stuff. And we're seeing a couple of different types of developers, where we're seeing the traditional AWS developer, someone that's been using and building with AWS for a while that is building maybe these full stack apps.

They're not just building the infrastructure, they're actually building a mobile app or a web app. To them this is the easiest or the fastest way to do certain things, so they're taking that approach versus... or maybe they're just adding it to their toolbox. This is just another option they have. And you look at the app that you're going to build and you decide, "Should I use Serverless Framework?" These are all great options, I think.

The other developer that we're actually really excited about, it's kind of this new generation of cloud developers that we are seeing enter the space via Amplify. A front-end developer or even a developer that's using something that you could kind of put in the bucket of competitor for Amplify that was scared to use AWS is coming to Amplify. Seeing that we have this great user experience and seeing how easy it is to add authentication and API and kind of deploy this on this scalable infrastructure is something they've never been able to do before. They get super excited about it, and then they tell their friends.

We're seeing this new generation of traditionally front-end developers kind of moving towards the framework. We're seeing the traditional AWS developers add it to their toolbox. And then startups are really excited about it. We just did a big week of events and in New York, a three day Amplify week. Busier, we had more people show up there's standing room only. A lot of startups where there, they're really looking for the most efficient way to build in this day and age of expensive developers and also the average.

If you're a startup and you want to go and hire a mobile developer and then you want to hire a cloud developer, you might want to hire a dev ops. You start adding all these things, starts adding up. What would we have today if you kind of choose the right abstractions? You have things like React Native on the front-end where you can write a single code base and deploy across iOS, Android and maybe even web. And then you look at something like Amplify, and if that front-end developer or that mobile developer can learn how to use Amplify, that might be enough for them to actually ship Version 1 without having to spend a million bucks, right?

Jeremy: Right.

Nader: The startups are super excited about it because of the efficiency and the cost savings of what they're able to build, and they're building on the same infrastructure that Netflix is building on, so that excites them as well. Because if they're like, "Oh, I don't have to just build a flimsy V1 or V0 that we have to rewrite, we're actually building on something that can scale. I think those are the three biggest buckets of developers that are pretty excited about Amplify.

Jeremy: And I love the sort of serverless for startups concept too because it's just one of those things where you're like you build that first version, you can always add onto it, but you just immediately have that scale. You have that reliability back there. And then again, not to hammer on the opinionated thing, but there are a lot of decisions that you need to make even with serverless when you're planning your backends and figuring out exactly how they're going to work. And you still have to think about scaling and think about how your systems are going to behave underload even if the backend scales for you.

There's still some decisions you need to make around there and Amplify basically makes most of those decisions for you. Which is I think really handy, especially for people who are not cloud experts, because that in and of itself might need to be a PhD just to figure out how some of these things need to work. I think that's great. You mentioned this idea of sort of there's on ramp to building these tools for production that they can get that view on out there. Are you seeing a lot of people using it to build PLCs or are they building Version 1 that actually goes into production and is out there as a full on production application?

Nader: Oh, totally both. I mean, we definitely see both. I would say the people that would be, if you're a massive corporation or you're a big company and you have a big team of established engineers, you might use Amplify to build that prototype and then move to something that is along the lines of you're basically existing development process, I guess. But if you're any company I guess, and you kind of do want to build something, there's really no reason to I think at this point, eject out of Amplify for any reason unless you really find the current way to get around some of the things that we don't support too cumbersome or whatever.

But I mean, going back to this weekend in New York, we had about a half dozen companies that had already shipped their Version 1, and they were there to talk about what their next steps are and then maybe just show us their apps. Like a really, really cool dating app that was just... they have a dozen people or so at that company and they're using Amplify and they've already shipped V1. It was was really cool to see to that type of stuff. We're definitely seeing a little bit of both.

Jeremy: That's amazing. All right, so let's get into the framework itself. All these things work together. You mentioned the framework and the CLI and the Console itself. But just the framework, the development experience. I'd like to talk about what that workflow is sort of the tool chains that you have in place. Maybe we start with sort of the basic thing here. You go to the Console, you type in Amplify, right? Just to get started, right? How do you get started with this?

Nader: There's a couple of different ways. If you do go to the AWS Console and you type in Amplify, we have a feature, I'm sorry, we have a service I guess in the Console and you'll have two different links that you can click there. One is going to take you to the Amplify Console, which is the service, but the other link is actually going to take you to our open source framework landing page, which has all of this stuff around the open source projects, which are the Client and the CLI. To get started you could go to the AWS Console, you'll find us there. You could just google it and the first thing that pops up is going to be the framework landing page for the open source.

If someone's just getting started, typically they'll find us through whatever means of a blog post, or maybe a reference, or just searching I guess on Google. And typically they'll then decide which platform that they want to see the information for their docs. And we really have four main buckets I guess, you could say of developers. We have as far as the platform on the front-end is concerned, we have native iOS, native Android. We just released new clients Amplify, native Amplify for iOS and Android on the Client, was just released actually in re:Invent this year. We're excited about that.

There's a native iOS, native Android, there's cross-platform, which is kind of React Native and we're also investigating other frameworks like Flutter. And then we have just web, and the web is growing crazy too because our team is AWS Mobile, but when we introduced this framework with JavaScript support, we thought React Native was going to be the fastest growing segment there, but web has actually been the fastest growing. And React Native is growing too, but just the sheer number of web developers just outnumbers that number of React Native developers, so it's kind of crazy.

React view, Angular, Ionic, all of those are the different frameworks that we support. We're looking at spells hopefully in the next, in the near future. Typically, you would kind of choose which framework you're interested in. And then we have a tutorial to get started where you create the Amplify project within whatever framework that you're working with, say for instance, React Native. Then you can add authentication and we have this two-liner that allows you to add a real production ready authentication flow in your app and two lines of code.

And that usually is really the light bulb moment where people are like, "Wow, this is awesome. We're excited about it, let's learn more." And then they'll go from there to maybe a Lambda function and an API Gateway. Maybe they'll look at GraphQL without sync or maybe a S3 with storage, just kind of playing around from there. Or they'll investigate based on the app that they want to build. Like, do we have the feature set that they want, or not?

Jeremy: Right. That was a lot of information. Basically, really the best way to get started is download the CLI, is what you're saying, right? That's really what you want to do the most work with?

Nader: I guess there's two types of, if you want to get the whole experience, yeah, do the CLI. If you already have some AWS stuff you want to connect to, just look at the Client docs.

Jeremy: All right. Then you've got the CLI, you said you pick your sort of the front-end of choice, whether that be React Native, or Web or something like that. And by the way, just in terms of, I can see Web being very popular because even a bank that I use got rid of their mobile app in favor of just using a mobile site. And I think it's just because they didn't want to maintain all those different versions. I do think that, especially with iPhones and Android and things like that, that the Web, the mobile web versions-

Nader: The web platforms

Jeremy: Yeah, exactly, will be very popular. All right, you start that, you get that sort of going there, you mentioned the components, right? Let's talk about components for a second. Because this is kind of cool. You and I talked about this in the past. Some of these components just add sort of features to the front-end that allow you to connect to backend resources. But some of these actually create, like you add them to your project and it actually will create front-end and backend resources, right?

Nader: Well it's kind of, we have this category or we have this set of components that are UI components, user interface components. And for those we have framework support. We have just the raw JavaScript library, which means you can just use this with any JavaScript project. And then in addition to that, you can install additional framework components. If you're using React or Vue, then you can NPM install these additional components. And yeah, they're kind of a hybrid between front and backend in the sense that they are going to scaffold out some UI for you. We're going to scaffold out for the authentication for example, a sign in, sign out, sign up flow along with things around multifactor authentication and all that stuff.

Nader: And from there you configure that, but it is opinionated in the sense that we're just assuming when you're using this component that we're going to be communicating with the Cognito backend that you've configured locally in your project. But yeah, we have those framework specific components for things like authentication, chatbots, images, feeder galleries and stuff. And they're a good entry point for people just getting started because you can just write a couple of lines of code and see something that looks really nice and that is ready to roll.

Jeremy: All right. Then you have sort of a tool chain here as well where you add those category components and then you just type ad hosting and it will just add it to the Console, or add it to the in fly Console.

Nader: Yeah. The tool chain is its own category within the CLI. We talk about the CLI either as a CLI or as a "CLI tool." And yeah, it does quite a few things. I mean, for instance, with GraphQL, if you've ever written GraphQL and you've called a GraphQL API from your Client application or from anywhere, you have to have the GraphQL operation definitions. And with the rest you call a rest endpoint, but with GraphQL, you pass in this AST, which is the GraphQL AST which contains the GraphQL operation.

You typically would have to just write all that code yourself. But the CLI tool chain, one of the things that it does, it'll look inside of your GraphQL schema and then it'll just generate all that code for you and then we'll create a folder and then drop it in. That's one of the things we call that GraphQL cogeneration. We also do Lambda function generation. If you want to have a Lambda trigger for S3 or for Cognito or whatever, we can give you a boilerplate to start with.

We also have a lot of other Lambda boilerplate generation for things like an express API running on Lambda or maybe even a DynamoDB CRUD app. If you want to get started with that, there's just boilerplate that you typically have to write over and over. And we're kind of giving you a starting point and then from there you can update that. And that's mainly, I would say what the CLI tool chain is there for.

Jeremy: Awesome. And then one of the other library components that was added recently was sort of this AI/ML that does sentiment analysis?

Nader: Right, right. We added the support both on the backend on the CLI, I guess, and on the Client for this new category that we call it Predictions. And Predictions is pretty cool because it basically just is taking advantage of all of the powerful stuff that's already there in AWS. And it wasn't a lot of work to get it working for us because all we were basically doing is kind of, if you have an identity pool within your project or if you want to create one, of course you could just run Amplify at auth and create one.

All we're doing is granting permissions to interact with those different AI and ML services within that identity pool. That part was pretty simple. And then on the Client we have added a couple of different methods I guess you could say around this new Predictions category. And from there you can work with recognition, you can work with Polly, you can work with Transcribe, you can work with many of the AWS or Amazon, forgot, depending on which service it is that the Amazon or AWS part, but yeah, all of these different ML and AI categories.

And I demoed this for the first time at an event in New York, actually this week again back to that event. And people were just blown away and it's been one of our fastest growing categories too. Because, it's just really simple to do and a lot of people are interested in this stuff. People are building apps around medical data and stuff with a lot of the text transcription and reading text off of a documents. People are pretty excited about this entry point because it's kind of easier in my opinion, to get up and running with than if you walk through the AWS Console and try to figure a way to actually integrate this into your app.

Jeremy: Well, I mean, it just goes back to this idea of making it super simple and easy to do this integration because, again, it's not hard necessarily to set up these things via the Console. But if you want to put the infrastructure as code and get the right CloudFormation in place and then connect everything together, and then you've got the UI piece of it that ties in, I mean, it's just a much better experience.

Let's talk a little bit more about some of these other features that are being added because your team, or the mobile team there is adding features to Amplify at an incredible pace. And one of the coolest things that came out lately was at re:Invent you announced the Amplify DataStore. I spoke with Chris Burns about this and I think, I forget his exact quote, but I think he said it was just awesome, but that I should talk to somebody else to give me the details on it. I'm talking to you, so tell us about the Amplified DataStore because this is pretty cool.

Nader: It's the culmination of almost two years of work from our team. And Richard Threlkeld, and Michael Herbenick, and Manuel Iglesias, a bunch of the people on the team have been either thinking about or talking about or working on this. Those are the ones that actually do the actual real work, by the way. And if you're on Twitter, it'd be worth to follow if you're interested in this stuff because they talk about this stuff.

DataStore is kind of, when we first launched the GraphQL support for AppSync on the Client, we had a library out there that allowed you to interact with the AppSync. And we ended up having two available options actually. We had one from Amplify and then we had one from a separate SDK that was kind of a fork of the Apollo SDK, which is a popular GraphQL library.

One of the things that Apollo had built in was this cache. And the Apollo Cache allowed you to work with some of that data in memory locally. Instead of having to query from the backend, you could query from that cache. And then we enhanced that by adding offline support. But the limitations that we started running into with that was that we had a lot of developers that started treating the cache as a store, and they wanted to do more complex queries on the store. They wanted to do things like query-based on some type of predicate. They wanted to maybe have more complex stuff than we could basically support, because we were working with someone else's implementation that we didn't really have control over.

Also, a couple of times there were breaking changes and stuff that they would implement that we would have to kind of go back and figure out what was going on, and it just wasn't the best experience. The Amplify DataStore is the next generation or the next version of that, but it has just a bunch of new features that we didn't have before. And I think the idea around it is, it's basically a single source of truth. It's a store that you write to locally from your front-end app. If you're on React, you would just write to the store and you don't have to actually from then worry about writing to your backend, the backend and the Client all sync together from this DataStore.

The way it works, I guess, if you talking about from the very start, if you're a user the way it would look like this you, you come online with your mobile or web app and from there it's kind of, imagine a new build or a new view of the app. The user has no data right on their app, so we make that initial fetch to data store via DataStore to whatever database you're working with. We get that initial set of data. Maybe you get like a thousand rows of data from DynamoDB. We keep the last sync time stamp on the Client at that point. We know when you fetch that data from there, we then have an observer that's set up that will then get any new data that's sent to that database and send it back to the Client.

You have that new data coming in. It's kind of like if you've ever worked with GraphQL, a GraphQL subscription running in the background, you could think of that. Or maybe if you've worked with Pub/Sub or something like that, WebSocket. But that's kind of all set up for you. Whenever anyone makes updates, that data comes back and it's stored for you locally. Also if you go offline and then come back online, we use that last sync time stamp to then fetch from what we kind of call it the delta table or the change table. And instead of fetching the entire data set, we actually just fetch the death between when you went off long last and went and when you came on last.

When we fetched that small set of data, you're getting a more efficient update to your local device. But also when you're offline you can actually write to your store locally and everything works. We make the optimistic update in the DataStore, you can have all of that updated data. Like if you've ever used Twitter or Facebook or even Instagram offline, you can still like stuff and all of that. It feels right, it feels like it's working, it's not going to break. And then when you come back online we send that new data back to the data database via the DataStore and you have the conflict resolution and the conflicts detection also built in, and we do a lot of that stuff.

We have a couple of different ways of doing conflict resolution. That you have the option of implementing, we have auto merge is the default and that's kind of the new conflict detection that we built in. And we kind of are taking the GraphQL schema and then the types that are whatever data that you're sending up. And we have a really enhanced version of conflict resolution that will make sure that even if two people write the same piece of data to the data database, maybe there's a field or there's a type that has three different fields and I change one field and someone else changed another field, instead of kind of like taking the last rider wins approach, we'll kind of merge those two objects. And that way the data is still up to date with both of our changes. But the user doesn't have to do anything and you actually as a developer don't have to write any code to make that work, it just works.

Jeremy: And I think what is really cool about this and also just so it doesn't get lost, is the fact that sort of traditional approach was you would sync your local cache or sync your local store with the database, and even if there's some pushes and things happening. But there was sort of a management locally on the Client where you said, "Okay, well this is in the cache, this is on the web, or this is online.

Nader: Right, right. We keep up with two sets of data, right? The local data and then the data that you have-

Jeremy: Right, right. And what this does is you just interact with the DataStore, right? You don't even care about the web. You just basically say, "Here's the DataStore, here's my source of truth. I'll interact with this and then Amplify will take care of syncing all that data to the cloud. All of my updates will get pushed. All of the updates that'll get pushed to me, that all just automatically happens. I think it's such a huge increase or a much better user experience, only have to deal with that one particular thing.

Nader: Right. That's exactly right. You're totally on point with that. You're writing to the local DataStore. You're no longer having to deal with interacting with the API yourself. But you still can, for whatever reason if you want to do something on the server or if you still want to do something on the client, you can. And then another thing that's kind of a big part of this is that we've added this query language to the data store itself.

You can call queries based on different predicate. You could say, "I would like to query the data based on, if this field is as this, or if this field is that." And you can actually chain different arguments into that query. You could say, "I want to query all of the to dos that are done, that are created by this person or something like that. And now you're just querying from that local DataStore and you're not actually having to send multiple requests to your backend. You're actually maybe, saying, of course the latency is going to be much faster. But even you might even save some money because you're sending less requests.

Jeremy: All right. If somebody took a look at Amplify maybe a year ago, there was a lot of cool features in there. I think the project had a ton of promise back then, but over the course of the last year or so, over the course of probably just the last few months so much has been added to it beyond just the DataStore. And these were things like the ability to do local mocking, more authorization support. You added the ability to do or to connect to Aurora Serverless, simplified all apps, that whole Delta deploys.

There's just been a ton of different things, instant cache validation, and I think that all has to do with really there being a good merger between, or a unification between the framework and the Console, which I think was a little bit disconnected a year ago or so. And that has kind of come together. Are there any of these updates that have happened over the last couple of months or so that you think really if people looked at it in the past are things that would be really game changers for them to look at the framework again?

Nader: Totally, the multiple authorization types, the local mocking and testing, the backend visitability and the Console, the machine learning stuff that we've added. A lot of these things are the things that I hear a lot of good feedback from our customers. But our roadmap is pretty much set by what people say that they want. We're not saying, "Oh, this would be cool to add or that would be cool to add." We're actually being like, "Okay, let's look today what people ask for, and tomorrow." And we're taking all of this feedback and we're prioritizing our roadmap based on what people ask for.

We're customer driven. And I know you always hear about AWS and Amazon being customer focused or whatever. I mean our team, that's all we really are. That's the main thing that care about, it's what people are asking for. Of course, we're always investigating other improvements that we feel our engineering team as engineers would think would be additional enhancements, but everything that we've basically done is based on that feedback.

A lot of the stuff that we do release is super, super popular and we get a lot of good feedback. Just because we've had people say that they wanted that stuff anyway, we just go and build it. We have a pretty transparent process around it, which is pretty different than... I think I've actually seen some parts of AWS now doing this. But we have our process open in the GitHub repo. You can look for RFCs or you can create your own RFC. And there you can actually talk about what you want and you can be in the discussion around what we're actually about to add. If you see something or if you have an idea, you can actually maybe get it implemented. It's pretty cool and a lot of people will get excited when they're in that discussion.

Jeremy: That's awesome. All right, I want to move on to a slightly different topic because you do a lot of work with GraphQL, obviously. And I'm a huge fan of the one table design strategy or single table design strategy for DynamoDB. And you wrote a post recently where you took, I think it was the example that was on the best practices article or whatever it is on the AWS site. And there was actually 17 different access patterns that you basically showed people how to do that in GraphQL, straight GraphQL, right? Like Lambda resolvers obviously I think people like to fall back on that. Sometimes they might think it's a little bit easier, but you set this whole thing up all through GraphQL. Do you want to tell us a little bit about that?

Nader: Yeah. And this is another feature that we added. That post was enabled by another couple of new features that we just added this year. Via the GraphQL Transform library, which is part of the Amplify CLI, you could say, you have the ability to use custom indexes and define custom keys and indexes using the graph Guild Transform library. And I think one of the things that a lot of people coming to Amplify have as a question or concern is, when they're done with their hello world project or when they're actually building their production app, they're stuck because they don't know how to take what they have and add a lot of this more sophisticated data access patterns that they might want.

And that post was just a direct response in addressing of some of those questions, some of those asked. And we put that also in the docs, so it's in the docs now, you can kind of go there and see that. If you have a business idea and you're wondering, "How can I model my database, and how can I leverage Amplify at the same time? How can I actually build this? Going and reading through that might give you some good ideas. Even if you're not using the exact the data set or whatever that we're kind of talking about there, of course, it's probably going to be something different, but you can use the ideas there and probably get some good ideas.

Jeremy: That's awesome. All right, well listen, Nader. It was great to have you here. Thank you so much for joining me. If people want to find out more about you and Amplify, how do they do that?

Nader: Yes, thank you so much for having me. Actually, I'm a huge fan of this podcast and I've looked up to pretty much all the people that you've had on here so far. It's been pretty cool to be here. If you want to find me on the social media, @dabit3, D-A-B-I-T and the number three. And then if you want to follow Amplify, we're also on Twitter @AWSAmplify. Definitely check us out if you're interested in this stuff.

Jeremy: And the Amplify site on AWS is aws.amazon.com/amplify, right?

Nader: Right.

Jeremy: And you have your blog, we mentioned your blog. What's your blog if people want to read all those articles you do?

Nader: Right, right. I used to be on Medium and I still have articles there, dabit3, but I've actually moved my blog to dev.to, so you can get a D-E-V dot T-O. That's dev.to/dabit3. And I'm pretty much dabit3, across all of the different social media and stuff. And also on GitHub, I have 270 repos on GitHub and I'm guessing that maybe there are 70 to a 100 of them are Amplify stuff. So dabit3 on GitHub also.

Jeremy: Awesome. All right, well, I will get all that into the show notes. Thanks again.

Nader: Thanks for having me.

Episode source