The Changelog: Software Development, Open Source - AWS Amplify and cloud-enabled apps (Interview)

Episode Date: July 25, 2018

We talk with Nader Dabit, Developer Advocate for Amazon Web Services, about the role of DevRel and what's involved in this "dream job", frontend and mobile developers using AWS Amplify to build cloud-enabled applications, how GraphQL, React, and others fit in, and the direction of React Native.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at rollbar.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is sponsored by our friends at Rollbar. How important is it for you to catch errors before your users do? What if you could resolve those errors in minutes and then deploy with confidence? That's exactly what Rollbar enables for software teams. One of the most frustrating things we all deal with is errors. Most teams either A, rely on their users to report errors,

or B, use log files and lists of errors to debug problems. That's such a waste of time. Instantly know what's broken and why with Rollbar. Reduce time wasted debugging and automatically capture errors alongside rich diagnostic data to help you defeat impactful errors. You can integrate Rollbar into your existing workflow. It integrates with your source code repository and deployment system to give you deep insights into exactly what changes caused each error. Give Rollbar a try today at no cost to you. From ChangeLog Media, you're listening to the ChangeLog, a podcast featuring the hackers, leaders, and innovators of software development.

I'm your host, Adam Stachowiak, Editor-in-Chief of ChangeLog. Today on the show, Jared and I are talking to Nader Dabit. Nader is currently a developer advocate for Amazon Web Services. We talked about the role of DevRel, what is involved in this, in quotes, dream job, front end and mobile developers using AWS Amplify to build cloud enabled applications, how GraphQL, React and others fit in and the direction of React Native. So, Nata, 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 noticed that everyone's Twitter profile says developer advocate now or if it's always been that way. Well, it's kind of interesting because a lot of our engineering friends and colleagues and people that we've talked to on the shows, they're all developer advocates now. A lot of them are moving into those positions. And so it's something that we're definitely noticing. And the question is, how many can there possibly be? Because at a certain point you

got to have some developers who aren't advocates but uh not enough not enough we need more developer advocates i mean you're right like uh it's it's so like the position i guess i can talk about for a little bit is this sure you know it's basically in my opinion it's 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, they don't, I guess they don't, they can't appeal to the typical developer with the traditional marketing approach, I guess. So like 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 kind of 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 the product is developer advocate as it is to the software that gets created to be the product. It'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. Yeah, I think that's a good way to look at it. And there's different types of this role, I guess you could kind of categorize as well. So 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.

So like with the developer advocate, we work closely with the engineering teams and the product and project managers. Whereas the developer evangelist, 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. And 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 DevRel then? So the other one we hear is DevRel, 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 a, you could like maybe say a comprehensive DevRel is maybe the developer advocates and the developer evangelists. So that's kind of like just what DevRel is. Yeah. And then like in smaller companies,

DevRel 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 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 you seem to be doing a lot of stuff. Is AWS like a full time job for you? And these are all side gigs or how does your how does your career lay out? Yeah. So before I started with AWS, I was working as one of the founders, I guess you'd say,

of React Native Training. We were doing consulting as well as training, but we were working with a lot of Fortune 500 companies and startups and 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. So, yeah, I do the podcast, but it's more of like a personal thing. The book, of course, is kind of just, you know, a book, so it doesn't really have anything

to do with them. And then, you know, just being involved in the community in general, it's kind of something that I do on the side. So AWS has long been the darling of clouds and the first in many ways and therefore kind of the de facto standard in 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 standoffish, 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 cultural thing? i mean it's definitely um it's definitely something i've heard before and after kind of getting uh involved at aws and seeing what's what's going on and like what actually happens i think the culture aws and amazon in general is different in the 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 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, like, you know, I guess, I wouldn't say bragging about it, but, you know, we're just really, 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 Tomcat. We've contributed back to a lot of the other projects that we've used, and 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 like 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 like 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. Like, and the second part is just as important as the first, which is why, you know, 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 it's for some of us, that's very difficult. It feels boastful, right? 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. And so in a certain way, 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. And so maybe that's why that that stigma was attached for a while. Is that an instructive thing or is that something that just doesn't happen? Like is someone at AWS saying, hey, you know, we'll do cool stuff, but just don't tell anybody

about it. No, no, there's none of that. I mean, but it's just kind of like I guess once you like start working in the culture, like you kind of go along with, I guess, 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 built this. Like, I'm awesome. Come look at it.

You know where I'm not like as humble, I guess, 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, you know, compensate for that. But the point that you made earlier is pretty interesting. I saw a tweet by David Brunel. He works with the Starbucks. He basically was talking about, you know, what you just said. And his tweet was 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 their nose down into their work. Whereas a lot of times people, they 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, you know, we're the people that aren't out there. So if you're not out there doing that, like, you know, you shouldn't feel bad about it. But you should also, when you're looking at hiring, like try to not take that too much into consideration. Take it into consideration to an extent. But really, you know, it into an consideration to an extent but really um you know he had an interesting point and obviously people a lot of people um thought it was a a thoughtful uh tweet because he had a lot of interaction and there was a lot of cool

discussion there that's interesting to to say that they're busy doing the work because that's often you know a good excuse to to not you know be boastful or to uh be on twitter sharing all the different things like if you're just too busy to do the hey i've built this cool thing or whatever like because you're just too busy doing work that's it's a good problem to have and some of that reminds me of us because adam because we we're very good at telling like what we do is we shine the light on other people's stuff like that's always been what we do and we love doing that and 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, like 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 not enough? You're right, though. I mean, you know, I don't think anybody has it like perfectly down. But like, what am I supposed to do? Should I like go from the rooftop? Should I do a blog post or 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 was like, sweet, it's back and like told their friend. That would be happiness for me. Sure. Of course. You know, 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 like marketing, overseeing what you do?

It is tough, isn't it? And sometimes a lot of people that are trying to kind of find, you know, find the balance there. It's it's 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 marketing a little bit if you don't have a voice that you kind of are comfortable speaking out with. And for me, it's been really tough to go on Twitter and talk about personal things like I'm OK. I feel like I'm OK with talking about technical things. But when I, when I talk about personal things, not really like personal things being like,

you know, like, um, I had a fight with my wife or something like that, but more like, Hey, I bought this cool thing, like on, on Amazon, like, look at it. Like, you know, that type of stuff. Whereas I feel like people, um, that are successful as far as generating like large amounts of followers and stuff like that they they do a really good job of being personal and but also mixing technical there as well yeah well here's a here's a case in point for you natter so um aws amplify this was not something that i had ever heard of adam had you heard of aws amplify no okay and then until you came on to 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 for show for shows. We used to also take news tips there. We don't do that anymore. You can actually go on change.com slash 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. So just curious if that took some guts from you, if that was a natural thing, you're like, Hey, here's a, here's a thing I can

do. Or if that was a thing where you had to like 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 uh positive response that the negative response doesn't mean anything anymore and you stop taking it personally because i used to take really like if i would if i would like send an email to someone and they didn't respond like even in time or something i would feel like oh like what did i say i said something totally wrong and like even um you know of, like putting myself out there and submitting that GitHub.

Of course, I could. 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 like I think after a while you kind of get over it and you're just like, OK, like, you know, people are good in general. And if you try to be a good person and 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 right like you're one step closer to the next yes because you can only get so many no's right someone's got to say

yes somebody's got to see it's a numbers game right's right. I do like how he ended his ping issue here. He says, and I'm a fan of changelog. Like, that's a good end cap. I like that. Flattery always helps. So I had submitted this idea to a couple of different podcasts. And I think, too, 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? Like, I don't know. But I won't even say who it was because it's like someone I really like. Right. Do they not do interviews?

I mean, is it not an interview show? No. Maybe that's what they meant. I don't know. No, they do, actually. Okay. Do they not do interviews? I mean, is it not an interview show? No. Maybe that's what they do. I don't know. No, they do, actually. Okay. That's why I said that. Who knows?

Well, it took us about a month, but we got back to you. One thing I like about the way we approach a conversation like this, just to kind of give some preface here, is like, of course, we're going to talk about AWS Amplify and, you know, mobile development. But I think it's kind of interesting to sort of unravel some of the steps of, like, you know, who you are and some of the roles you play. So we can sort of understand

contextually, like 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 like, I really like it. I feel more comfortable also talking to you now after, you know, going over some of this stuff. Um, 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 or 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. So I go there like, you know, once a month or once every two months. But I got 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, lived out there, worked with a couple of companies that kind of showed me the ropes. And I got my first glimpse of like really hardworking, uh, engineers that were doing things that I didn't know about, like podcasts and conference, listen to podcasts and going to conferences and going to meetups, things I like really actually never knew about coming from Mississippi. And, um, um, and then bringing that back to Mississippi, that knowledge and that like work that, uh, that type of, uh, work philosophy back with me. I've kind of continued there, and I've done a few different jobs locally working with startups.

And 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. And then 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 is 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 SDKs

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. I just kind of hop back to what you said. You were 29. That's that's a relatively late coming to technology as a career. Was that something that was a barrier for you to overcome? Was your relatively late arrival into this space or was that something that was kind

of a non-factor for you? It was. Yeah, it was interesting because most of the people that I was learning from were like 10 years younger than me literally right at my first job so um but i loved it so much that i didn't really care and i like once uh once i found i'd done a bunch of things i had like some really terrible jobs actually growing up and stuff so when i finally got something that i was uh fairly good at and i wasn't like naturally good at 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 kind of like enough motivation that I

could kind of overlook the fact that I was like you know a little older than a lot of the people and I and it just made me work maybe a little harder to try to catch up with everyone and stuff like that so I wouldn't say it was a barrier. I've seen people older than me kind of get into it and still become successful. Absolutely. So just curious now, what were some of those terrible jobs you had? Give us a couple of your worst. 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 dislike the restaurant industry at this point. 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. So, for instance, sometimes I would be at work from like 8 a.m. until like 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 that were apparel goods that were shipped to the united states and sold wholesale um that's that's worked in my family uh my parents family business for a while that's kind of the main things i guess you would say that's interesting to that you're in restaurants too because that is such a tough job i mean it's inexplicably it's supposed to be a tough job because like you may have a full shift or even work a double that day and you still have to, you know, roll silverware or take care of condiments, like all these extracurricular stuff that's like not part of being a server or part of being the staff or front of the house staff that you have to do extra. It's like once your job's over, you still have more job to do. Yep, that's exactly right. And a lot of times you're even like washing dishes at night and doing stuff that your people that like it's 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. This episode is brought to you by DigitalOcean. Thank you. to spend in your first 60 days. Try it free. Once again, head to do.co.changelog. All right, 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.

I mean, this is 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. Yeah, 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'd 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 like a front end developer, or you're a JavaScript developer, or you're a native app developer in general, and you want to work with cloud enabled services with AWS, or with really with any cloud provider, getting like

connected to those different services and having them interact with each other has been typically like 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 a bunch of 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 um to do a lot of this stuff it was just really complicated because the different sdks and different client-side libraries were not consistent so this is more of like a consistent api layer uh but different things you can do with this library so 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, you know, 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. So we have this command line interface that you can install to your terminal and spin up these cloud-enabled applications. So, 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 React Native or Angular or 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. And then you can add things like authentication, you can add a GraphQL API, you can add things like authentication you can add a graphql api you can add storage you can add push notifications like from the cli and then that gets pushed up to the uh to the aws cloud uh whatever you would call that the console uh to your account and then you can just interact with that from the command line or from your application? So it is a, there's like an umbrella JavaScript module, npm install AWS Amplify first.

And then what you're saying is, depending on specific features that you want, like you mentioned authentication, analytics, 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? So you install the JavaScript library, and it has all these different ways.

It has all these different APIs. So like the AWS Amplify library has an auth class. It has like an analytics class and has an API class. So you have all of that as part of the library. And then if you want to actually create that service in your AWS account from the CLI, you can just say, hey, I want to add authentication. It'll spin up an authentication setup for you. And then you can just connect using the API that that's provided by Amplify.

So 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'll kind of generate a bunch of pre-configured UI and functionality. And it'll just help you kind of get started quickly so we have like this with authenticator howard component and how order component will basically add authentication to your app with like a single line of code but the the uh the deal with that is it's it's giving you like a pre-configured set of decisions

that are made for you around your ui stuff like that. So you end up probably in the production app, ripping that out and just writing it from scratch using, you know, just the regular JavaScript. I see. So it's kind of a nice starter, test the water, see how it works. But if you're going to want to, you know, have your own specific things, then you're going to want to use that auth class and build out the flows all yourself. Totally. Yeah, that's right. Okay. So the 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, like that you would normally go into the console and say, turn this on or sign me up for this. It's triggering those for you. Yeah, exactly. And it's kind of like it's more of like a flow that works for front end developers that are used to working with NPM and they're used to working, you know, from the terminal in general. So you can kind of 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? Yes. 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. So 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 everyone's adopting it. 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 which this is this is the very first i've seen of react native being moved away from especially such a large you know internet company so curious just what your thoughts are on if you if you're aware of that particular post that situation at airbnb and um know, why React Native perhaps didn't fit in that case. Yeah, definitely. I'm interested in that topic, actually. And I've totally read that blog post and I have a really good understanding about like 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. And yeah, it's interesting. I would say like the issues that they ran into were around bringing in a, you know, an existing application that was built natively and integrating React Native. I think if I had read correctly, like 85% or so of their app was native and only like a small percentage was React Native to begin with. And I think that, you know, they brought in React Native. They definitely tried to make it work. Some of the issues that they ran into were just issues that haven't 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, you know, all these issues over the years. And they were such early adopters, they have probably seen even more issues than if you would pick it up,

picked it up today, or maybe even a year from now, you would see, you know, less issues over, over time. And, you know, and, and have we read, I read a lot of into that about maybe there is, you know, some culture there with some of their native iOS developers where they, they gave it a shot and they're just like, you know, like we've, we've given it a shot. Let's like, 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 like generally, you know, around the same time that they released that blog post, Facebook actually also released a blog post talking about the reengineering of React Native. And they made three major changes. And the first is the threading model. So they're basically changing the threading model. Instead of each UI update needing to perform on three different threads, it'll be possible to call synchronously into JavaScript on any thread for high-priority updates. And it'll keep the low priority work off of the main threads to maintain,

you know, good, I guess, responsiveness and good performance. They're also incorporating async rendering capabilities into React Native, which is going to basically allow multiple rendering priorities. And it'll simplify the asynchronous data handling. And there were some issues around that, I believe, that they were having. And then they're also finally 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 kind of uh that passes in between native and javascript and you're passing in a lot of data probably from your existing native native app into the javascript side they're um they're simplifying it and making it faster i don't

know what that looks like in in actual um implementation but that's kind of the messaging that they've given i'm really interested to see what's going to happen after they release this new, newly architected version to see if that really kind of solves some of the problems. And I would say like, as someone that works a lot with big companies that are using React Native, we work with,

with React Native training. You know, 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 just this year, including a bunch of other smaller to medium-sized companies. So when you see big companies like that adopting React Native, I think what you're seeing is, yes, there's going to 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, a single code base,

and you're still able to save money and be efficient, there's always going to be trade-offs with anything. And I think the trade-off 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 are some issues still there.

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. Yes. We're sunsetting it. They actually was pretty responsible about their position because considering Airbnb, great engineering team, a lot of cloud in the space. So what they do has a lot of ramifications to other people's outlook on React Native. And so they took that responsibly and did a four-part series. At the same time, and 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. A lot of those moving on posts are kind of like hit pieces, you know, where they're, they're just tearing down this thing that they've been, they've been using. And, and Airbnb is post, like you said, Adam was nothing like that. In fact, very thoughtful, very detailed, as you said, multiple part series. So, you know, much respect to them for like actually laying out their, their experience. And then everybody else can come alongside and say,

okay, am I like them? Is this my experience that I'm going to have or am I in a different scenario? So 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. So that's awesome that they did that. It's actually super insightful as well. You know, it's long when you got to think about, do I have the time to read this? Then you think how long it took him to write it. It's like, do I really want to read five parts? So I have some pretty awesome news to share.

We are now partnered with Algolia. If you've ever searched Hacker News, Teespring, Medium, Twitch, or even Product Hunt, then you've experienced the results of Algolia's search API. And as we expand our content, we knew that one day we'd have to either roll our own search solution on top of Postgres, or we could partner up with Algolia. And I'm happy to report that phase one of our search is now powered by algolia we're able to fine-tune our indexing gain insights from search patterns and analytics we can create custom query rules to influence ranking behavior as well as improve our search experience by adding synonyms and alternative corrections to queries sure we could build search ourselves but that would mean

we would be busy doing that instead of shipping shows like you're listening to right now. Huge thanks to our friends at Algolia for working with us. Check the show notes for a link to get started for free or learn more by heading to algolia.com. So 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.

You 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 Vue. You 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? And I noticed in the read me that it's built in such a way that that is possible. But it sounds like that's not like that's vaporware. That's like you guys want that to be a thing. But actually, this is only works with AWS. Is that is that a good read? Yeah, it's basically our priority to make it work as well as possible with AWS, and everything else is kind of like, you know, 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, you know, whatever the customer actually wants first. But we also have, you know, a completely open GitHub repo. So you can submit issues and anything that is doable, we're going to try to prioritize it. And if it makes sense, we're going to try to implement it. But like, you know, for we have things that work, you know, already that aren't, you know,

with only AWS, again, our GraphQL client. So if you've ever worked with Apollo or Urkel, we have our own version of a GraphQL client that works with not only ours, but like GraphQL or works with Hasura or if you build your own GraphQL database server, it works well with that. Internationalization works 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 like very integral part of my application. 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, you know, with AWS as the cloud that wouldn't be like a showstopper necessarily.

And the pragmatist would say, well, you're using AWS, so what's the problem here? But just the ability to say, yeah, well, you're using it at WS, so what's the problem here? But just the ability to say, yeah, well, I am using them, but if that relationship goes south, you know, I don't have to completely rewrite everything in order to go to a different backend vendor. And so I think it's definitely important to provide those options even. And I like that you guys are building in such a way that it's pluggable for those custom backends, especially you have the GraphQL one that, like you said, works with pretty much anything at this point. And so I'm curious if that's like something that y'all will tackle or you're hoping that

a community comes by or maybe even like you're hoping that Microsoft funds them to write the Azure plug, you know, for these things. What are your thoughts on that? So it's totally a combination of community and our own developers, you know, contributing to this project. But I think the contributions from the community, we have pull requests, of course, but we have, you know, a lot of manpower, I guess you'd say, behind this project, implementing the features that people are asking for in the issues. So, you know, again, most of the actual work, I would say,

is done, you know, 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, like, you know, 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 a generic Lambda connection here, like functions as a service type of a thing in this i'm seeing interactions i'm

seeing like create conversational bots i'm assuming assuming is using those kind of backends but is there is there like a serverless wrapper inside this tool set yes so the api category works really really well and really easily with serverless. So you end up having you pass in the API name. And if you have a path, you can pass that in. And then you can just call get posts, but delete things like that on on that resource. Talk a little bit about this interactions, but I'm just going through kind of a feature list here. We mentioned analytics, authentication authentication push notifications interactions it says create conversational bots powered by

deep learning technologies can you tell us more about that yes so that's a really interesting category we just added that actually a few weeks ago and i just posted a blog actually on tyler mcginnis.com he's one of my friends he's like big into the React community, on how to do this. So like, you know, the idea behind this is a lot of where you're seeing some applications go 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 have or 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. So with the AWS mobile CLI, you can spin up like a new bot. And then you can interact with it using a couple of different components from the Amplify library. We have a chat bot component, which is a pre-configured component that already has all 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. So 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.

And the bots basically, the way that they work is you have a trigger message that kind of triggers the bot. So if you have a bot that wants to, for instance, like book you a hotel reservation, you might have a few different triggers that say that are things like book a hotel or I want to take a trip or whatever. So you would have a list of these triggers. And if you can get something from the user that matches closely, then that bot gets triggered. And 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 like a list of utterances that you want to then say to the user. So say that the bot of booking a hotel gets

triggered. Then you maybe have like four different questions that you ask the user. So you would say things like what city, what number of people are going to be staying in the room, so on and so forth. And then you capture that data and then you do stuff with it. So what you can do with that data normally would be you have some other application or some other service that you're going to 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. And I just have a meta question about chatbots. And Adam, maybe I can pull you in on this as well.

Remember a couple of years ago when everyone was saying like chat is the new UI and like chatbots are going to take over your world and all these things, specifically Facebook. Facebook was saying that it was like 2016. I don't know if it was two years ago or one year ago but like you know the round of conferences like the it was facebook what's facebook's called um thumbs up no what's it called what's up no facebook's uh developer conference what's it called uh yeah f8 and then like build and then google io and and then wwdc you know like that time time frame and chat bots were the rage. Like everybody was going to have chat conversational UIs.

This is the next thing. And 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 chat bots here. I'm just thinking like larger, bigger picture. It seems like that didn't really take hold. Like, is that really, do we see that as a thing that's happening? I mean, you can see this happen in, 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 then people expect too much of it at an early stage. And what you end up seeing is like people, they pile on the 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. And I think that's what you saw with artificial intelligence, uh, two years ago, and now it's starting to pay dividends. And I think you saw that with chat bots 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, right? But it's still starting to play a role with Alexa

and different areas that you're seeing. And then you're seeing with blockchain technology, I don't really know where that is, but I think we're at the beginning of the downturn of the initial hype cycle and then that's going to slowly build back up yeah i think it's kind of quiet down and people are just busy building and really it's tools like these and it's services and it's tooling a lot of it's tooling to put into our us developers hands and allow us to 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 less like we've moved on. Like we're excited about something else, but the reality of it is definitely like improves things in people's lives. Maybe a question for this might be, how did this happen prior to Amplify? You know, did you have to cobble together your own ways to interact with or take advantage of the various AWS features? Like Lex being a brand new thing, like you wouldn't want to like go and make your own way. You'd want something like a framework like Amplify to help you get there. Like how do do people deal with AWS services before in 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 on 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. And 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. And what you're seeing, like when you see things like Firebase or for us, it's AWS AppSync or these other managed services like AltZero that offer 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 whatever 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. And at AWS Mobile, we're kind of trying to amplify that,

I guess you'd say. But we're trying to bring that to the forefront with this Amplify library along with the CLR. 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 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 the single GraphQL API through the Amplify JavaScript SDK and have not only all these other services, but of course, the database is the integral service that you need for an application. We've added that integral part, and we're going to 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, you know, 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, like you could

categorize them as serverless. And what serverless the idea is you pay for, you're basically trading capital expense for variable expense. So instead of paying for something and not, 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. And 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 like then jump off a cliff if it doesn't work. But like, you know, you're you're getting to the point where, oh, like we have users like we could probably afford to pay for this now. And then that's when your actual bill comes in. I think I heard the marketer come out there. Do you say trading capital expense for variable expense? That was very smooth.

I like that. Well, I mean, it's actually the only way I can really. I mean, because it i mean it's actually the only way i can really i mean because it's like it's true it's like you know you end up building uh something yourself and you spend time and time is money or you pay a developer to build out the service and that's again that's time and you know that's capital and and that's a capital expense so like 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 going to work or not? Or should I instead just subscribe to the 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 just pay, you know, for whatever that service costs. That's what I was thinking of, like 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 is successful and approves 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 you know well hey i don't really need to have this managed graphical server because we would rather do it this way let's bring that one in house is that

what you're trying to say that's exactly yeah that's kind of the way that i'll look at it and that's kind of the that's the philosophy that that like i have about all this stuff and yeah and a lot of cases i mean, 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, you know, putting all the capital and 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. Maybe they keep using it. Maybe they don't. Yeah, exactly. And, you know, it allows for more experimentation. It allows for more different trial and error.

It allows you to fail faster, you know, and that's kind of what goes on in a startup environment. You don't want to build out something that costs $100,000 if you're not sure if it's going to work. But if you know that you're only going to probably spend, you know, a fraction of that, you know, paying a front-end developer to implement it and it doesn't work, you're not really, you know, you haven't lost as much,

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 allows more innovation and experimentation. So 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... I hypothesize, you know. It's not Netflix. It's, you know, CinemaFlix. 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. And we're even hiring, if you're listening, on all of our teams. So, like, you know, 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. You're powering a lot of things being used by companies. That's pretty vague. I like it, though. I know. I'm sorry.

Is there anything you could share about, you know, 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. I mean, OK, I can talk about some of the stuff that, you know, that different companies, you mentioned Airbnb, basically, the company runs all of its IT infrastructure on AWS. And they use over 1300 Amazon EC2 instances, they use Amazon EMR, they use S3. And then with with Lyft, Lyft is another big startup, as well as Pinterest, they both, you know, are on AWS. So 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 dependent 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, so like a lot of these companies are using just traditional AWS services, which you're seeing with AWS Mobile is we're really providing like integration from client side applications into some of these services. And then with the introduction of our CLI, you know, to spin up new applications. And then with the AWS AppSync, that's kind of like our first main, oh, not really

our first, but it's one of our first main services that are specifically, you know, mobile only, like I wouldn't say mobile only, but they're part of our organization. Where's a good place you send people to, to get started? What's the, I think you can get started with React. You can get started with the web. What's the one you prefer people to go to first? Yeah. So just, 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, you know, we have sections on those different frameworks. I have a repo on my personal GitHub. It's Dabit3 and on GitHub. And the 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 want to add something or if you want to make a fix or something on something we already have there. All right. Awesome. We will link up awesome. Hit up this Amplify. We like awesome lists.

Oh, yeah. Yeah. There's also an awesome AWS AppSync if anyone's interested there, too. That's kind of awesome. You had to go there. I had to go there. Sorry. I was hoping for more laughter.

I'm sure the listeners are like, Adam, you're lame, pleasing the show. And I'll go ahead and do that. 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.

All right. Thank you for tuning in to this episode of The Change Log. If you enjoyed the show, do us a favor. Go on iTunes. Leave us a rating. Leave us a review. Go on Overcast and favorite it. Tweet a link to it. do us a favor. Go on iTunes, leave us a rating, leave us a review. Go on Overcast and favorite it. Tweet a link to it. Share it with a friend.

And of course, thank you to our sponsors Rollbar, DigitalOcean, and Algolia. Also, thanks to Fastly, our bandwidth partner. Head to fastly.com to learn more. And we catch our errors before our users do here at Changelog because of Rollbar. Check them out at rollbar.com and we're hosted on

Linode Cloud Services. Head to linode.com slash changelog. Check them out at rollbar.com. And we're hosted on Linode cloud services at linode.com slash changelog. Check them out, support this show. This episode is hosted by myself, Adam Stachowiak and Jared Santo. Editing and mastering is by Tim Smith. Music is by Breakmaster Cylinder. And you can find more shows just like this at changelog.com or wherever you subscribe to podcasts. Thanks for tuning in. We'll see you next week.