AWS Amplify and cloud-enabled apps

Nader, you’re a developer advocate for Amazon Web Services. I think developer advocate, at least for me, is kind of a new position, or it’s a burgeoning position - we’re starting to see them pop up all over the place. What does it mean to be a developer advocate for AWS? What’s that all entail?

Yeah, totally a burgeoning position. I’m starting to see – I don’t know if it’s just because I’m now a developer advocate that I’ve noticed that everyone’s Twitter profile says developer advocate now… Or if it’s always been that way.

Yes. Well, it’s kind of interesting, because a lot of our engineering friends and colleagues and people that we talk to on the shows - they’re all developer advocates now; a lot of them are moving into those positions… It’s something that we’re definitely noticing, and the question is how many can there possibly be…? Because at a certain point, you’ve gotta have some developers who aren’t advocates.

Not enough, not enough… We need more developer advocates.

I mean, you’re right… So the position, I guess I can talk about for a little bit…

Sure.

It’s basically in my opinion kind of like a new form of marketing. I think traditional marketing has not been, of course, working with how the industry has been moving, because a lot of developers - I guess they can’t appeal to the typical developer with the traditional marketing approach… So with the developer advocate - we have to understand how to not only build applications, but we have to understand how developers think, and I think the combination of us being developers as well as being out there, interacting with other developers, we provide a lot of value… Not only being able to talk about what we’re working on, but to bring feedback back to the teams that are building the tooling that we’re working on.

It’s kind of like a product manager as it is to the product, is developer advocate as it is to the software that gets created to be the product… That’s kind of how I see that. Because you’re sort of this middle person where you interface with end users, you have to provide some inroads and on-ramps, you have to give feedback to engineering teams, and even marketing in a lot of cases, or have a lot of relationships. You’re sort of this liaison to all these different parts.

[04:06] Yeah, I think that’s a good way to look at it… And there’s different types of this role I guess you could categorize as well. If you’ve seen people that are developer evangelists or even solutions architects in some of these bigger companies, they all kind of play a similar role… Similar, but different; with the developer advocate, we work closely with the engineering teams and the product and project managers, whereas the developer evangelists I feel like they kind of work closer with the broader sense of what’s being worked on in the company, and maybe closer – I would say that could typically be more of like a marketing role, but they’re also doing a lot of conferences, and stuff.

Then solutions architects would be people that are kind of working closely with customers, but they’re also writing documentation and blog posts and bringing feedback back to the teams.

It’s interesting to see a distinction between advocate, evangelist and architect… Solutions architect, at least.

So what’s dev rel then? The other one we hear is dev rel, like developer relations. Is that another name for the same thing, or is that a different thing altogether?

Yeah, I think it’s just another term for kind of – you could maybe say a comprehensive dev rel is maybe the developer advocates and the developer evangelists… So that’s just kind of like what dev rel is–

An umbrella term.

Yeah, and then in smaller companies dev rel might just be people that are doing all types of stuff, where they don’t really differentiate between the two.

So we also see you as one of the four members of React Native Training. In fact, I saw that, and I saw you’re the author of React Native in Action, and doing React Native Radio, and I thought you must be like a contractor with Amazon Web Services, because they seem to be doing a lot of stuff.

AWS is like a full-time job for you, and these are all side-gigs, or how does your career lay out?

Yeah, so before I started with AWS I was working as one of the founders (I guess I should say) of React Native Training, and we were doing consulting as well as training, but we were working with a lot of Fortune 500 companies and startups, or just companies in general… But Amazon was one of our clients, and we would go on-site and just have workshops with their engineers, showing them how to get up and running with React Native as quickly as possible.

So when I started with AWS, they allowed me to kind of continue my role there as kind of just part of the team, but not really doing any training on-site or anything like that anymore… So I’m kind of more just helping manage the blogs and the content creation and the lead generation there part-time, and then really full-time I’m with AWS. And I’m big into React Native, if you haven’t noticed.

I did a podcast, but it’s more of like a personal thing. The book, of course, is kind of just a book, so it doesn’t really have anything to do with them… And then just being involved in the community in general is something that I do on the side.

So AWS has long been the darling of cloud, the first in many ways, and therefore kind of the de facto STDIN the developer community, and yet in terms of open source and really what I would call developer relations (from my particular vantage point now; this is probably not a globalized view) it seems like Amazon has historically been – I wouldn’t say stand-offish, but just less warm to kind of the indie, open source, small business developers… Is that something that is just a misconception, or do you think that that’s perhaps historically true and changing? What’s your vantage point on that particular culture.

[07:45] Yeah, it’s definitely something I’ve heard before, and after kind of getting involved at AWS and seeing what’s going on and what actually happens, I think the culture at AWS and Amazon in general is different in the sense that you don’t see a lot of our developers going on Twitter and talking about “Hey, I just contributed to this project or I’ve built this project”, but in reality, because I think the culture is a little more – we just do stuff and we try not to go around, you know, I wouldn’t say bragging about it, but… The culture is a little different. But in reality, a lot of the people at AWS contribute to open source. For instance, we’ve contributed to MySQL, Linux, Apache, Hadoop, Apache’s Tomcat…

We’ve contributed back to a lot of the other projects that we’ve used, and then we’ve even created our own projects and they’re open source as well… Things like Apache MXNet blocks, AWS Amplify, which we’ll probably talk about in a little bit… We have a few dozen projects that we’ve created as well, and then we have a bunch of repos that are kind of like sample projects that are kind of more aimed at showing people how to use our stuff, so they’re a little more self-serving; I wouldn’t say they’re open source in the sense like we’re creating something for anyone to use in those projects, but we do have those types of projects as well.

It’s interesting you say that, because – I can’t remember who coined the phrase or the idea of how to be successful on the internet, but the general advice is do cool things and then tell people about it.

Exactly! And it works, it’s actually true.

It’s actually true. And the second part is just as important as the first, which is why people who are good at talking about what they do are often more successful on the internet… Because you have to tell people what you’re doing, and yet for some of us it’s very difficult, it feels boastful, and we are just naturally not going to go out there and tell people. But if you don’t do that, nobody knows, and there’s not success to be had.

So in certain ways, it sounds like - at least what you’re saying there is AWS has been doing open source things but not necessarily telling people about it, so maybe that’s why that stigma was attached for a while.

Is that an instructive thing, or is that just something that doesn’t happen? Is someone at AWS saying “Hey, we’ll do cool stuff, but just don’t tell anybody about it.”

[laughs]

No, there’s none of that, but it’s just kind of like… I guess once you start working in the culture, you just kind of go along sometimes what other people are doing… But I guess that’s where I’m a little different. You’ll see me on Twitter saying “Hey, I’ve built this. I’m awesome. Come look at it.” I’m not as humble as some of the people I work with… But I think maybe the tradeoff is I’m not as smart as those people, so I’m kind of like trying to find a way to compensate for that.

But the point that you’ve made earlier is pretty interesting. I saw a tweet by David Brunelle - he works with Starbucks - and he basically was talking about what you’ve just said; his tweet, the general gist of it was something about the most talented and the better engineers that he’s known aren’t the people that are out there speaking at conferences and writing blog posts and stuff like that, because they’re just nose down into their work, whereas a lot of times people see the people that are out there like me, that are out there tweeting and blogging and speaking, like that we’re smarter, but in reality a lot of the smarter people that he’s worked with were the people that aren’t out there.

So if you’re not out there doing that, you shouldn’t feel bad about it, but also, when you’re looking at hiring, try to not take that too much into consideration. Take it into consideration to an extent, but really – he had an interesting point. And obviously, a lot of people thought it was a thoughtful tweet because he had a lot of interaction and there was a lot of cool discussion there.

That’s interesting to say that they’re busy doing the work, because that’s often a good excuse to not be boastful or to be on Twitter, sharing all the different things… If you’re just too busy to do the “Hey, I’ve built this cool thing” because you’re just too busy doing work - that’s a good problem to have.

[11:54] It sort of reminds me of us, Adam, because we’re very good at telling what we do as we shine a light on other people’s stuff; that’s always been what we do, and we love doing that… So we’re very good at like “Hey, check out this cool thing that this person has done, or this team over here is working on”, and yet on our own stuff, especially I think Adam, yourself - for instance, you rebooted Founders Talk recently, and you just kind of put it out there and you went on vacation. You didn’t really tell anybody.

I mean, I put out an episode that said “Hey, it’s coming back.” Isn’t that enough? [laughter] You’re right though, I don’t think anybody has it perfectly down, but what am I supposed to do? Should I go from the rooftop, should I do a blog post, do a guest post on somebody else’s really popular blog? I guess you could do all those things, it just depends on what your goals are.

I guess I would just be happy if people found it and it was like “Sweet. He’s back”, and told their friend. That would be happiness for me. Sure, of course, if we got 10,000 new listeners, that’d be great too, but you know… I guess how far do you push the boundary of marketing, over saying what you do?

It is tough, isn’t it?

And sometimes a lot of people that are trying to find a balance there… It’s hard to go out there and do that type of stuff if you’re an introvert or if you’re just not used to it; it just feels weird. And sometimes it feels markety a little bit if you don’t have a voice that you kind of are comfortable speaking out with…

For me, it’s been really tough to go on Twitter and talk about personal things. I feel like I’m okay with talking about technical things, but when I talk about personal things… Not really like personal things being like “I had a fight with my wife” or something like that, but more like “Hey, I bought this cool thing on Amazon. Look at it.” You know, that type of stuff… Whereas I feel like people that are successful as far as generating large amounts of followers and stuff like that - they do a really good job of being personal, but also mixing technical there as well, of course.

Yeah. Well, here’s a case in point for you, Nader… AWS Amplify - this was not something that I had ever heard of; Adam, had you ever heard of AWS Amplify?

No.

Okay. And then, until you came onto our ping repo, which long-time listeners of the show are well aware that we have a repo on GitHub called Ping, where anybody can just come and give us ideas for shows. We used to also take news tips there; we don’t do that anymore. You can actually go on Changelog.com/submit and submit your news… But for show ideas, it’s Ping, and that’s been a place where we found lots of awesome shows.

Not very many people, but some will come on Ping and actually say “Hey, you should have me on the show.” But I think that’s a hard thing for a lot of people to do. And having said that, you came on Ping and said “Hey, here’s an awesome thing - AWS Amplify.” You’re getting the message out there, I had not heard of it, and you said “Hey, I’d be happy to come on the show and talk about it.” I’m just curious if that took some guts from you, if that was a natural thing – you’re like, “Hey, here’s a thing I can do…”, or if that was a thing where you had to overcome a little bit of a fear of rejection, or that kind of idea.

You know, I think I’ve gotten over the fear of rejection after being rejected so many times in my life, for different things… It’s kind of like, you just get to the point where if you try enough things, you get enough positive response that the negative response doesn’t mean anything anymore, and you just stop taking it personally… Because I used to take really – if I would send an email to someone and they didn’t respond even in time, or something, I would feel like “Oh, what did I say? I said something totally wrong.”

And of course, putting myself out there and submitting to that GitHub - of course, it took a few days to respond, so I kind of had a little bit of thought like “Maybe that wasn’t the correct way to go about this”, or something like that… But I think after a while you kind of get over it and you’re just like “Okay, people are good in general, and if you try to be a good person and whatever, then you shouldn’t have anything to worry about.” I don’t know if that makes a lot of sense, but that’s kind of my philosophy around that stuff.

I like to say that behind every no is a yes. You’re one step closer to the next yes. Because you can only get so many no’s, right?

Someone’s gotta say yes sometimes…

Somebody’s gotta say yes; it’s a numbers game, right?

[16:00] That’s right.

I do like how he ended his Ping issue here. He says “And I’m a fan of Changelog.” That’s a good end cap, I like that.

Yeah, flattery always helps. [laughs]

So I had submitted this idea to a couple different podcasts, and I think two - we decided to talk about certain things; we’re talking about a little bit different of a subject on this podcast… But I did get a response that said – all he responded with was “No, we’re not that type of podcast”, and I never understood what that meant, because I was like “What type of podcast are you?” I don’t know… But I won’t even say who it was, because it’s someone I really like, so…

Do they not do interviews? Is it not an interview show? Maybe that’s what they meant.

No, they do, actually… So that’s why I–

Okay. So yeah, who knows… [laughter] Well, it took us about a month, but we got back to you.

One thing I like about the way we approached a conversation like this - just to kind of give some preface here - is like, of course we’re gonna talk about AWS Amplify, and mobile development but I think it’s kind of interesting to sort of unravel some of the steps of like who you are and some of the roles you play, so we can sort of understand contextually who you are, and your position, and where you come from. Not so much to get your life story, but just to have some context.

Yeah, I really like it. I feel more comfortable also talking to you now, after going over some of this stuff… And I guess – do you want me to give you even more context? Just kind of a few more things about how I’ve gotten to where I am?

Please do.

So I’m in Portland right now, at the Chain React conference, but I work remotely from Jackson, Mississippi, and I’m actually one of the only developer people on the AWS team that does work remotely… But as a developer advocate, a lot of our work is done on our computer, of course, as a lot of people are these days, but specifically we’re writing blogs and we’re making videos and we’re writing documentation and we’re interacting with the developers… So we’re not working so closely with the engineering team that we need to be there all the time. I go there like once a month or once every two months.

But to go back even further, I started development at the age of 29, and I kind of was a self-taught developer. I moved to California to get my first dev job, in Los Angeles. I lived out there, worked with a couple of companies that kind of showed me the ropes, and I got my first glimpse of really hard-working engineers that were doing things that I didn’t know about, like listening to podcasts and going to conferences and going to meetups - things I really actually never knew about, coming from Mississippi… And then bringing that back to Mississippi, that knowledge and that type of work philosophy back with me.

I’ve kind of continued there and I’ve done a few different jobs locally, working with startups. Then when React Native came out, I kind of thought this was an awesome thing and I kind of went full-speed ahead with that… So that’s why I’m so involved with different things in React Native and kind of made that my specialty.

AWS Mobile is – you know, when you think about AWS, you don’t really think about front-end development, you think about typically back-end development. So it was interesting when I saw some of the projects that they’re working on with AWS Mobile, and the idea that what we’re doing is kind of like really interesting to me… Probably people don’t really get that at first, because again, when you think of AWS, you think of back-end development. But what we’re doing is we’re building a lot of tooling to help front-end developers kind of move further up the stack, and to increase their efficiency as far as like what they can do with their existing skill set and take the different things that they can do as developers to the next level without having them to learn a bunch of new things.

So we’re basically building tooling and building SDK’s that allow front-end developers to interact with managed services, so they can do a bunch of different things with JavaScript, or with iOS or Android native as well.

[20:04] I’m just gonna hop back to what you said - you were 29… That’s a relatively late coming to technology as a career… Was that something that was a barrier for you to overcome, your relatively late arrival into this space, or was that something that was kind of a non-factor for you?

Yeah, it was interesting, because most of the people that I was learning from were like 10 years younger than me literally, at my first job… But I loved it so much that I didn’t really care. I had done a bunch of things, I had some really terrible jobs actually growing up, so when I finally got to something that I was fairly good at – and I wasn’t naturally good at it; it was something I had to work at… But once I found out I can actually get paid to do this stuff that I was doing anyway, like, for free, on the side, in my spare time, it was enough motivation that I could kind of overlook the fact that I was a little older than a lot of the people. And it just made me work maybe a little harder to try to catch up with everyone, and stuff like that.

I wouldn’t say it was a barrier… I’ve seen people older than me get into it and still become successful.

Yeah, absolutely. So I’m just curious now, what were some of those terrible jobs you had? Give us a couple of your worst jobs.

So I was a host at a restaurant, I was a bartender at a restaurant, I was a manager at a restaurant, and I really disliked the restaurant industry at this point… [laughter] But I have total respect for the people that actually do good in restaurants, because it’s like the hardest job… I know it doesn’t sound like the hardest job, but it’s kind of like a combination of a lot of hard work, but also the environment that you’re in and the hours that you work.

For instance, sometimes I would be at work from like 8 AM until midnight, and it was just craziness, and I didn’t get paid very well. I was a real estate agent for a while, I also did importing and exporting for goods from China, apparel goods that were shipped to the United States and sold wholesale. I worked at my parents’ family business for a while… Those were kind of the main things I guess you would say…

That’s interesting that you were in restaurants too, because that is such a tough job… It’s inexplicably a tough job, because you may have a full shift, or even work a double that day, and you still have to roll silverware, or take care of condiments… All these extra-curricular stuff that’s not part of being a server or a part of being the staff, or front of the house staff, that you have to do extra. It’s like, once your job is over, you still have more job to do.

Yeah, that’s exactly right… And a lot of times you’re even like washing dishes at night and doing stuff that people that were supposed to come in that day didn’t do, and you can’t really leave until it’s all done, so you just jump in and do it.

Alright, Nader, so you pinged us to talk about AWS Amplify, which is a JavaScript library for front-end and mobile developers who are building cloud-enabled applications. Now, there’s a lot to unpack here, because I hadn’t heard of it, but that doesn’t mean it’s not popular and large. The breadth of this project - there’s so many pieces to it. Why don’t you give us the rundown and then we’ll dive into specific features of what all AWS Amplify is providing for people?

Yes, so it’s like a fairly new project. It’s an open source project as well, so you can kind of download the code and take a look at it if you like, and contribute back if you’d like… But it’s really more for just – I guess, to kind of talk about what it does… If you’re a front-end developer or you’re a JavaScript developer or you’re a native app developer in general and you wanna work with cloud-enabled services, with AWS or really with any cloud provider, getting connected to those different services and having them interact with each other has been typically not an easy thing to do… So we decided to create AWS Amplify to have like a single library with a consistent API, that allows front-end developers to do different things that they used to do – they used to be able to do some of this stuff, not all, but actually we’ve added new features… But to do a lot of this stuff - it was just really complicated, because the different SDK’s and different client-side libraries were not consistent; this was more of like a consistent API layer.

There’s different things you can do with this library - you can do things like authentication, you can do analytics, you can work with serverless functions, with lambda functions, you can work with GraphQL servers… So that means you can work with any GraphQL server, not just our personal GraphQL server, which we also have a managed GraphQL service called AWS AppSync, so you can interact with that as well. You can do storage with S3, push notifications, a bunch of other stuff as well.

So the bottom line is it’s kind of like a way for front-end developers to start interacting with cloud services… And it’s really complemented by a CLI. We have this command line interface that you can install to your terminal and spin up these cloud-enabled applications.

Of course, as a front-end developer, AWS to me was kind of a tough thing to wrap my head around; working in the console was brand new to me, and I thought it was pretty complicated at first. With the CLI you can just be in your terminal, in the environment that you’re used to being working in, and maybe you could be inside of a React, or a React Native, or Angular, or a Vue app, whatever you’re working on, and you can just spin up a new cloud application, and then you automatically have some basic features out of the box that are already spun up in the cloud, like analytics… Then you can add things like authentication, you can add a GraphQL API, you can add storage, you can add push notifications from the CLI, and then that gets pushed up to the AWS cloud or whatever you would call that, the console, to your account, and then you can just interact with that from the command line or from your application.

So there’s like an umbrella JavaScript module… npm install AWS Amplify first, and then what you’re saying is depending on the specific features that you want - you mentioned authentication, analytics, a GraphQL client - you can mix and match these, you can pull them in as necessary, using the CLI that gets installed… Or is it using npm?

You install the JavaScript library, and it has all of these different APIs… The AWS Amplify library has an auth class, it has an analytics class, and it has an API class. So you have all of that as part of the library, and then if you wanna actually create that service in your AWS account, from the CLI you can just say “Hey, I wanna add authentication.” It will spin up an authentication setup for you, and then you can just connect using the API that’s provided by Amplify.

[28:16] With Amplify we also have some JavaScript libraries that are implemented with first-class components… So you can either just use the vanilla JavaScript and kind of interact with these from JavaScript directly, using these different classes, or you can use some pre-configured components for Angular, React and React Native. That will kind of generate a bunch of pre-configured UI and functionality, and it’ll just help you get started quickly.

So we have this width authenticator higher order component and higher order component will basically add authentication to your app with like a single line of code… But the deal with that is it’s giving you a pre-configured set of decisions that are made for you around your UI, and stuff like that. So you end up probably in the production app ripping that out and just writing it from scratch, using just the regular JavaScript.

I see. So it’s kind of a nice starter; you can test the water, see how it works, but if you’re gonna wanna have your own specific things, then you’re gonna wanna use that auth class and build out the flows all yourself.

Totally, yeah. That’s right.

Okay. So the CLI - that’s where I misunderstood; I thought it was pulling in specific of the JavaScript bits, but it’s actually allowing you to turn off and turn on specific cloud services on the AWS side, that you’d normally go onto the console and say “Turn this on” or “Sign me up for this.” It’s triggering those for you.

Yeah, exactly. It’s more of like a flow that works for front-end developers that are used to working with npm and they’re using to working from the terminal in general… So instead of having to go and learn the AWS console, you can just spin up these services from your command line.

Very cool. And it’s front-end and mobile… So talk about the mobile side. You mentioned React Native - is that the only way to get these things into your mobile applications?

Yeah, so with Amplify we support React Native and web right now. We’re continuing to add other different integrations (I guess you’d say). So we’ve had a lot of people ask for iOS and Android natively as well, so we’re looking into that… But yeah, for right now, it’s based strictly for JavaScript. You can use this with Ionic or Angular as well… Anything that’s just a JavaScript-based application right now.

So while we’re talking React Native, and we know that you’re a huge advocate for having run the React Native Radio for a few years, undoubtedly you’ve seen Airbnb’s recent Medium post about their big bet on React Native in 2016, and now they’re ready to share their experiences and they’re basically ready to move on. I think all technologies go through this hype cycle where first it’s a brand new thing and people are afraid of it, but excited, but then all of a sudden everybody’s adopting it and now we’re all using it, and then the posts start to come out of the actual drawbacks, and “This didn’t work for that reason”, and we start to see the backlash… This is the very first I’ve seen of React Native being moved away from (especially) such a large internet company.

I’m curious just what your thoughts are on that, if you’re aware of that particular post, that situation at Airbnb, and why React Native perhaps didn’t fit in that case.

Yeah, I definitely am interested in that topic actually. I’ve totally read that blog post, and I have a really good understanding about that whole situation, because Airbnb has been such a great contributor to the React Native ecosystem over the years, and they’ve had a lot of great people that worked on the Airbnb app that were part of the React Native community, that were really involved with a lot of conferences and stuff like that.

It’s interesting – I would say the issues that they ran into were around bringing in an existing application that was built natively, and integrating React Native. I think if I have read correctly, 85% or so of their app was native, and only a small percentage was React Native to begin with… I think that they brought in React Native, they definitely tried to make it work…

[32:22] Some of the issues that they ran into were just issues that had not been solved at the moment with React Native, and I think they just got fed up and tired with trying to get things to play together when they were having all these issues over the years… And they were such early adopters they have probably seen even more issues than if you picked it up today, or maybe even a year from now… You would see less issues over time.

I read a lot about that - maybe there’s some culture there with some of their native iOS developers where they gave it a shot and they were just like “You know, we’ve given it a shot. Let’s just not deal with it anymore”, because maybe they did see these issues, and as native developers, they didn’t have to run into these issues before…

But I think generally, around the same time that they released that blog post, Facebook actually also released a blog post talking about the re-engineering of React Native, and they made three major changes. The first is that threading model. They basically are changing the threading model; instead of each UI update needing to perform on three different threads, it will be possible to call synchronously into JavaScript on any thread for high-priority updates, and it will keep the low priority work off of the main threads, to maintain good responsiveness and good performance.

They’re also incorporating async rendering capabilities into React Native, which is gonna basically allow multiple rendering priorities, and it will simplify the asynchronous data handling. There were some issues around that that they were having…

And then also they’re changing the way the bridge works. The native bridge is really – if you’re bringing in React Native into a brownfield app, the bridge is a major part of that, because you’re writing a lot of code that passes in between native and JavaScript, and you’re passing in a lot of data probably from your existing native app into the JavaScript side. They’re simplifying it and making it faster… I don’t know what that looks like in actual implementation, but that’s kind of the messaging that they’ve given.

I’m really interested to see what’s gonna happen after they release this newly-architected version, to see if that really kind of solves some of the problems… And I would say, as someone that works a lot with big companies that are using React Native, with React Native Training, we work with a lot of these companies that are bringing in React Native right now… And this year alone, we’ve seen like a 300% increase in companies reaching out for training, even now.

Companies like Microsoft, companies like Salesforce, American Express, Visa, even Amazon, have all reached out to us this year, including a bunch of other smaller to medium-sized companies.

When we see big companies like that adopting React Native, I think what you’re seeing is yes, there’s gonna be situations where it doesn’t work, but overall, I think the value proposition with React Native, or something like React Native - maybe it’s Flutter as well - is you’re still able to ship multiple platforms with somewhat of a similar, single codebase, and you’re still able to save money and be efficient. There’s always gonna be tradeoffs with anything, and I think the tradeoff with React Native right now is you do have those issues, especially with upgrading (that’s kind of a painful process), but also integrating with brownfield existing native apps; there’s some issues still there.

[36:03] What’s interesting about that series that they did is they actually did a four-part series, so it wasn’t just like “Hey, here’s three paragraphs. We’re sunsetting it.” They actually were pretty responsible about their positioning, because considering Airbnb - great engieering team, a lot of clout in the space, so what they do has a lot of ramifications to other people’s outlook on React Native… So they took that responsibly and did a four-part series.

At the same time, some stats from that post was 63% of their engineers would have chosen React again, given the chance, and 74% would consider React Native for a new project. So it wasn’t like all bad, it was just like it didn’t work for them, in their particular situations.

Yeah. A lot of those moving on posts are kind of like hit pieces, where they’re just tearing down this thing that they’ve been using, and Airbnb’s post, like you said, Adam, was nothing like that… In fact, very thoughtful, very detailed; as you said, multiple-part series, so much respect to them for actually laying out their experience, and then everybody else can come alongside and say “Okay, am I like them? Is this my experience that I’m gonna have, or am I in a different scenario?” It was very thoughtful.

Yeah, totally. And for them to write five pages of a blog… As someone that writes a lot, I could say that that guy probably spent at least a week putting that together. It’s awesome that they did that; it’s actually super-insightful as well.

Absolutely. You know it’s long when you have to think about “Do I have the time to read this?” You don’t think how long it took him to write it… [laughs] It’s like “Do I really wanna read five parts…?”

It’s very cool that AWS Amplify can work with React Native; as you said, it can work with Ionic, you can use it with Angular, you can use it with Vue, React of course. Kind of wherever you are in your front-end app, you can pull it in. Of course, if you can use all those things, I’m sure you can use it with vanilla JavaScript. The question is can you use it with other clouds?

I noticed in the readme that it’s built in such a way that that is possible, but it sounds like that’s not – that’s vaporware; you guys want that to be a thing, but actually only works with AWS. Is that a good read?

Yeah, it’s basically our priority to make it work as well as possible with AWS, and everything else kind of takes a backseat, because a lot of our customers that are working with all of our services through JavaScript applications are asking us for different features and stuff like that, and we always prioritize whatever the customer actually wants first.

But we also have a completely open GitHub repo, so you can submit issues, and anything that is doable, we’re gonna try to prioritize it, and if it makes sense, we’re gonna try to implement it. But we have things that work already that are with only AWS; again, our GraphQL client… So if you’ve ever worked with Apollo or URQL, we have our own version of GraphQL client, that works with not only ours, but GraphCool, or works with Hasura, or if you build your own GraphQL database server, it works well with that.

[40:14] Internationalization works well with anything. We have a few different other APIs that already kind of work with any different service provider, and we’re continuing to iterate on that.

Yeah, I think that’s important, because when I look at these services that you’re providing, authentication specifically, I think “Okay, this is a very integral part of my application, a GraphQL client, of course, storage, there you have it…” Certain things are easier to replace - analytics, push notifications - but when I think about like these are core aspects of what I am building, there’s a certain twinge of vendor lock in with AWS as the cloud; it wouldn’t be like a show stopper necessarily, and the pragmatists would say “Well, you’re using AWS, so what’s the problem here?” But just the ability to say “Yeah, well, I am using them, but if that relationship goes south, I don’t have to completely rewrite everything in order to go to a different back-end vendor.”

So I think it’s definitely important to provide those options, and I like that you guys are building it in such a way that it’s pluggable for those custom back-ends, especially you have the GraphQL one; like you said, it works with pretty much anything at this point… I’m curious if that’s something that you all will tackle, or you’re hoping that a community comes by, or maybe even you’re hoping that Microsoft funds them to write the Azure plug for these things. What are your thoughts on that?

So it’s totally a combination of community and our developers contributing to this project, but I think the contributions from the community – we have pull requests, of course, but we have a lot of man-power (I guess you’d say) behind this project, implementing the features that people are asking for in the issues. So again, most of the actual work, I would say, is done within the team, but we do have a very healthy number of people submitting pull requests and issues as well, that are part of the community.

And again, I would say that we try to probably prioritize issues that are with customers before we prioritize anything else. So if we have a customer that’s having issues maybe working with their S3 bucket or their serverless lambda function, their serverless application, we’ll probably tackle that before we’ll add a new feature that works with another cloud provider.

Is there like a generic lambda connection here, or functions-as-a-service type of a thing in this? I’m seeing interactions, I’m seeing “Create conversational bots”, so I’m assuming it’s using those kinds of back-ends, but is there a serverless wrapper inside this toolset?

Yes, so the API category works really well and really easily with serverless. You pass in the API name, and if you have a path, you could pass that in, and then you can just call GET, POST, PUT, DELETE things like that on that resource.

Talk a little bit about this interactions bit. I’m just going through kind of the feature list here; we’ve mentioned analytics, authentication, push notifications, interactions – it says “Create conversational bots powered by deep learning technologies. Can you tell us more about that?

Yes, that’s a really interesting category. We’ve just added that actually a few weeks ago, and I’ve just posted a blog actually on TylerMcGinnis.com - he’s one of my friends, he’s big into the React community - on how to do this.

The idea behind this is a lot of where you’re seeing some applications go, or around conversations, and you’re seeing things like Alexa, but you’re also seeing things within applications where you’re able to kind of have these conversations with whatever, you know? And of course, at AWS we have the Lex service, which allows you to create these conversational bots with voice or with text… So what we’ve done is with Amplify we’ve implemented a category that just makes it really easy to interact with your service.

[44:17] With the AWS Mobile CLI, you can spin up a new bot and then you can interact with it using a couple of different components from the Amplify library. We have a chatbot component which is a pre-configured component that already has all of the UI and the actual code written to handle the back and forth… Or you can use the Interactions category, which gives you direct access. What you would end up doing is you create your bot, you import that interactions category and then you start sending messages to the bot.

The bots, basically – the way that they work is you have a trigger message that kind of triggers the bot. If you have a bot that wants to, for instance, book you a hotel reservation, you might have a few different triggers, things like “Book a hotel” or “I want to take a trip” or whatever; so you’d have a list of these triggers, and if you can get something from the user that matches closely, then that bot gets triggered.

Then you can do a couple of things with that bot - you can send that trigger through a lambda function and do more complex things, or you can actually just send back a list of utterances that you wanna then say to the user.

Say that the bot of booking a hotel gets triggered - then you maybe have like four different questions that you have the user. So you would say things like “What city? What number of people are gonna be staying in the room?”, so on and so forth. Then you capture that data and then you do stuff with it.

What you can do with that data normally would be you have some other application or some other service that you’re gonna be hitting with that data, and then you return a response back to the user.

That’s awesome. That’s a very easy way to get chatbots going. I just have a meta question about chatbots, and Adam, maybe I can pull you in on this as well… Remember a couple years ago when everybody was saying chat is the new UI, and chatbots are going to take over your world, and all these things? Specifically Facebook was saying that… It was 2016 – I don’t know if it was two years ago or one year ago, but the round of conferences, it was Facebook… What’s Facebook’s called? Thumbs Up – no, what’s it called? [laughs]

WhatsApp?

No, Facebook’s developer conference, what’s it called?

F8.

Yeah, F8, and then like Build, and then Google I/O, and then WWDC… In that timeframe, chatbots were the rage; everybody was gonna have chat, conversational UIs, “This is the next thing.” It’s two years later now - or maybe it’s only a year, if my memory is not serving me right, but… I’m not trying to knock chatbots here, I’m just thinking bigger picture - it seems like that didn’t really take hold. Or do we see that as a thing that’s happening?

You could see this happen in blockchain technology over the last year as well, and then with AI before that… I think what happens is there’s a ton of hype around something, and people expect too much of it at an early stage, and what you end up seeing is people pile on to an idea, and then they don’t get the expected outcome from the hype, so it kind of falls back to the wayside… But people are slowly actually improving the technologies around these things, and then later on they are fruitful.

I think that’s what you saw with artificial intelligence two years ago, and now it’s starting to pay dividends. I think you saw that with chatbots, where now you’re actually seeing more of that come into play; it’s not as big a deal as you would have thought it would be, but it’s still starting to play a role with Alexa and different areas that you’re seeing.

Blockchain technology - I don’t really know where that is, but I think that we’re at the beginning of the downturn of the initial hype cycle, and then that’s gonna slowly build back up.

[48:04] Yeah, things kind of quiet down and people are just busy building… And really, it’s tools like these and it’s services – a lot of it is tooling to put into us, developer’s hands, and allow us to more easily play with these things, and build things, and start with a toy app, or a toy service, and then think “Okay, I can use this here”, and start to kind of – there’s a groundswell of actual use cases that happen slowly over time… And by the time it actually happens, I guess it’s like we’ve moved on; we’re excited about something else. But the reality of it is it definitely improves things in people’s lives.

Maybe a question for this might be how did this happen prior to Amplify? Did you have to cobble together your own ways to interact with or take advantage of the various AWS features? Lex being a brand new thing… You wouldn’t wanna go and make your own way, you’d want a framework like Amplify to help you get there. How did people deal with AWS services before on the front-end?

Yeah, that’s a good question, and I think the main answer would be just using the regular AWS JavaScript SDK, which is something that we’ve already had for a while. So I would kind of take a step back and talk about what we’re doing in general, as like a philosophy, all my team and AWS Mobile… The things that we’re accomplishing with Amplify could have been accomplished, again, with the regular JavaScript SDK; it would just have been much harder.

I think to use the JavaScript SDK as a front-end developer, you could have probably gotten all this stuff accomplished, but we’re building really more of like an ecosystem around tooling not only for connecting, but also for creating these services. When you see things like Firebase, or for us it’s AWS AppSync, or these other managed services (like Auth0) that offer an easy way to get up and running with authentication…

What we’re really moving towards, in my opinion, as far as like software engineering in general, is especially for front-end developers - you’re seeing these front-end developers being able to access more and more complex functionality as a service. So instead of having to spend the time and effort to kind of understand the entire working of an authentication flow on the server and on the client, and build that out and make it secure, you’re betting on the fact that all these other people that are out there doing that and spending millions and billions of dollars even bringing a managed service to life that as a front-end developer you can then just subscribe to - I think we’re seeing a lot more of that. With AWS Mobile - we’re kind of trying to Amplify that… [laughs] We’re trying to bring that to the forefront with this Amplify library, along with the CLI.

So with an existing skill set of understanding how to work with just APIs in general, you can kind of be a JavaScript developer and build out a full stack application with only your existing JavaScript knowledge. So that means you can not only create authentication and analytics and push notifications, but now we’ve added this AWS AppSync service, which is a managed GraphQL service which is basically a managed database. So you end up being able to work with a single GraphQL API through the Amplify JavaScript SDK, and have not only all these other service, but – of course, the database is the integral service that you need for an application; we’ve added that integral part, and we’re gonna be iterating on all this stuff… And I think hopefully people are starting to catch on and see “Hey, as a front-end developer, I don’t have to learn how all of this complex functionality works on the back-end… I can just pay for this service.”

And again, with the type of services we’re talking about, you could categorize them as serverless. And with serverless, the idea is you’re basically trading capital expense for variable expense. Instead of paying for something or building something and not using it until you get the users, you’re subscribing to something and you don’t really pay for it until you get a bunch of users.

[52:12] With a startup - or really with a company in general - once you get those users, you’re kind of good to go anyway, for the most part… Or at least you can then jump off a cliff if it doesn’t work… But you’re getting to the point where “Oh, we have users. We can probably afford to pay for this now”, and that’s when your actual bill comes in.

I think I heard the marker come out there, did you say “Trading capital expense for variable expense”? That was very smooth; I like that. [laughs]

Well, it’s actually the only way I can really – because it’s true; you end up building something yourself, and you spend time, and time is money, or you pay a developer to build out this service, and again, that’s time, and that’s capital. It’s a capital expense.

So the way I look at it is “Should I go ahead and pay someone to build this, even though I don’t know if it’s gonna work or not? Or should I instead just subscribe to this service that does it for me?” And then say it does work out, we can go back and build it later if we’d like, from scratch, or we can continue to kind of use this service and pay for whatever that service costs.

That’s what I was thinking… This gives the ability for someone to either be a one or two-person team, to put together an idea, they have the capability, they can leverage these services, and let’s say whatever it is, it’s successful and it proves itself - well then, if they wanted to and they actually did prove their idea and they got product-market fit, and maybe even paying customers, or capital, or investing, or whatever to take them to that next step, they can begin to trade off “Well hey, I don’t really need to have this managed GraphQL server, because we would rather do it this way. Let’s bring that one in-house.” Is that what you’re trying to say?

Yes, exactly. That’s the way I look at it, that’s the philosophy that I have about all this stuff.

In a lot of cases, to put it quite bluntly – sure, these people may build apps and continue to use these services, but in a lot of cases it seems like the AWS infrastructure is putting a big bet on people’s applications and their success, because for you to get paid, it needs to have a fairly decent adoption or great usage, and that’s when you get paid. So you’re actually putting all the capital in the infrastructure and the ability and the plumbing and the accessibility of it, hoping that more people use it so that they can get to the first step faster, and maybe they keep using it, maybe they don’t.

Yeah, exactly. And it allows for more experimentation, it allows for more different trial and error, it allows you to fail faster, and that’s kind of what goes on in a startup environment. You don’t wanna build out something that costs $100,000 if you’re not sure if it’s gonna work, but if you know that you’re only gonna probably spend a fraction of that paying a front-end developer to implement it and it doesn’t work, you’re not really – you haven’t lost as must, but you’ve been able to try that thing and see if it works. So I kind of think it allows not only cost savings, but it allows more innovation and experimentation.

At the bottom of the page for AWS Mobile I see “Trusted by category-defining applications, huge brand names like Netflix, Tinder, Yelp, Airbnb, Periscope, Etsy” - these are huge names. The last two I’m not that familiar with - Easy Taxi and hike Messenger - but what kind of applications within these organizations are being powered by… Is it Amplify, or is it these services for mobile?

So I can’t really go into exactly what each customer is using, but some of the most popular services that are being–

Hypothesize, you know…? It’s not Netflix, it’s CinemaFlix. [laughter]

Just guess.

You know, we have a lot of people – our platform is growing in adoption quickly. We have a lot of people picking up a lot of these different tools and running with them and actually building and shipping things… That’s why we’re doubling down and we’re continuing to grow the teams around this. We’re even hiring (if you’re listening) on all of our teams.

So we’re doing a lot of things that are being used by companies, and a lot of the tooling that we build at AWS Mobile, a lot of these companies are using.

[56:19] You’re powering a lot of things being used by companies. That’s pretty vague. I like it though.

I mean, I’m sorry… [laughter]

Is there anything you could share about some example applications out there that are pretty well-defined, or anything that you can share? Maybe not these ones in particular, but something else.

Yeah, okay, I can talk about some of the stuff that different companies – you mentioned Airbnb… Basically, the company runs all of its IT infrastructure on AWS, and they use over 1,300 Amazon EC2 instances, they use Amazon EMR, they use S3.

Then Lyft - Lyft is another big startup, as well as Pinterest… They both are on AWS. Lyft is using a lot of EC2 Spot instances, and Spot instances are basically kind of a lower cost EC2 instance that doesn’t stay around – it’s not as consistently there and it can’t be depended on to kind of run a normal application, but you can do things like testing, and you get basically a big discount on the instance by using that. Pinterest - so they’re using AWS to run their website, they use S3 to ingest and store their data…

But a lot of these companies are using just traditional AWS services. What you’re seeing with AWS mobile is we’re really providing integration from client-side applications into some of these services, and then with the introduction of our CLI, to spin up a new application. Then with the AWS AppSync, that’s kind of like our first main – or not really our first, but it’s one of our first main services that are specifically… Like, I wouldn’t say mobile-only, but they’re part of our organization.

Where is a good place you send people to to get started? I think you can get started with React, you can get started with web… What’s the one you prefer people to go to first?

I would probably just go to the docs and read just the regular JavaScript implementations, and then if you are a fan of whatever framework, we have sections on those different frameworks.

I have a repo on my personal GitHub - it’s dabit3, and repo is awesome-aws-amplify. And if you’ve ever seen one of these Awesome repos for any other framework, it’s pretty much the same thing. We just kind of aggregate all the different links, and stuff like that… And it’s open source, of course, since it’s on GitHub; you can send a PR if you wanna add something, or if you wanna make a fix on something we already have there.

Alright, awesome. We will link up Awesome-aws-amplify in the…

We like awesome lists… [laughter]

There’s also an awesome-aws-appsync if anyone’s interested.

That’s kind of awesome.

You had to go there.

I had to go there, sorry. [laughter] I was hoping for more laughter… I’m sure the listeners are like, “Adam, you’re lame. Please end the show”, and I’ll go ahead and do that.

Nader, it was really awesome having you on here. I love the enthusiasm you have.

Yeah, totally. It was fun to be here, and it was really nice meeting both of you.

Thank you very much.