May 1, 2020
Selling During a Recession: Q&A with Bridget Gleason and Chris Grams
Tidelift's Bridget Gleason and Chris Grams answered questions from the community about selling during a recession.
In episode 32 of JAMstack Radio, Brian meets with Nader Dabit, developer advocate for AWS Mobile, which is a team within AWS that focuses on solutions for mobile developers to discuss developer tools such as Device Farm, AWS Amplify, and AWS Appsync.
About the Guests
Nader Dabit is Developer Advocate for AWS Mobile, a team within AWS that focuses on solutions for mobile developers, where he writes blog posts, talks to developers to get an idea of how they’re using some of the products that AWS Mobile is working on, and speaks at conferences & meet ups. He is also the author of React Native in Action.
Brian Douglas: Welcome to another installment of JAMstack radio. On the line I've got Nader Dabit.
Nader Dabit: Hey Brian. Thanks for having me on today.
Brian: Cool. You've made a recent transition to Amazon, working there. Do you want to explain what you're doing with AWS?
Nader: Yes. I work with AWS Mobile, which is a team within AWS that focuses on solutions for mobile developers. But also a lot of the stuff that we're working on is around PWAs as well, and really generally applicable to web development in general. Primarily on our team we have a few different projects that I'm focused on.
One of them is Device Farm, one of them is AWS Amplify, and the other is AWS AppSync. I think we're going to cover some of those later, but my role there is a developer advocate. Generally the role that is a developer advocate, at least at AWS, involves writing blog posts, talking to developers and getting an idea of how they're using some of the products that we're working on. And speaking at conferences and speaking at meet ups, and stuff like that.
Brian: Awesome. I know you mentioned that you're in the mobile team specifically, I know your experience. We know each other from React Native Radio. I was on your podcast years ago. Actually, I got the idea of JAMstack Radio, the "radio" portion from that actual podcast directly. So, inside baseball right there.
You mentioned progressive web apps as part of your focus there, which is interesting. Do you want to talk more about how someone might use AWS or AppSync or one of those tools to do a progressive web app?
Nader: AWS Amplify and AWS AppSync could both be applied in that scenario. One of the things that you think about a lot of times is offline capabilities with PWAs. We offer a GraphQL client that works with AWS AppSync. If you've never heard of AppSync, AppSync is a managed GraphQL service. It's a way to spin up a real-world GraphQL API. It has things that are already built in, like alternate authentication authorization scalability.
Basically it is a way to get up and running with GraphQL without having to build a server yourself. We have a GraphQL client that interacts with the GraphQL server that has offline capabilities built into it. So if you've ever worked with the Apollo client, the API is very similar, and you provide an optimistic update through UI. And as long as that optimistic update is given to the update function, then everything works seamlessly to the client.
They don't ever really know whether or not they're offline. They don't see any different experience in the application. As soon as you come back online the data gets sent to the API and it just works without them knowing.
Another thing that we've recently launched that would go within the PWA category is code splitting. Or, I wouldn't say code splitting, I would really say tree shaking with some of our APIs that you can import. Before when you worked with Amplify, you would end up importing the entire library.
In some cases if you only wanted a few different portions to work within the app, now we have a way to only input the code that you need so you end up with smaller bundle sizes. And then real time, a lot of PWAs have real time capabilities built in. With GraphQL it's more of a GraphQL thing with subscriptions where you can build real-time applications using some of the stuff that we have.
Brian: When you talk about code splitting, are you guys using Webhack under the hood? Or did you guys build your own version of that through one of these products?
Nader: Yeah, I said code splitting. I meant tree shaking. We've rebuilt a way to import the components that you would be using without importing unnecessary code.
Brian: OK. Before we go further into that, I do want to take a step back and explain Amplify and AppSync. You touched a little bit on AppSync and some things you could do. But I'm not sure what Amplify is yet. Do you want to talk about that?
If you've ever needed to do things in your application like push notifications, if you have ever needed to work with storage, like with S3. We have a way to interact with chat bots. We have the GraphQL client and about a dozen different features right now.
Brian: Cool. So we just talked about Amplify, or you just explained Amplify pretty well. Can you talk about how these other two products you mentioned before, which I believe was Device Farm, how that works? And the ecosystem of AWS mobile?
Nader: Device Farm is literally a room with a bunch of real devices that you can just implement different tests on from wherever you are virtually. If you've ever built an Android application, you know that depending on the operating system and depending on the device and depending on a bunch of different factors, you can have different things happen.
And a lot of times a lot of the bugs that come along with Android are dependent on some of these quirky use cases.
With Device Farm you can just use your test suite and deploy it across a bunch of different real world devices. Do things like record the screen, you can batch a bunch of different devices, you don't have to use all of them you can pick and choose what you'd like to do. And you can deploy tests across all of these different devices and get valuable data back and save money. In the sense that you're not having to go and buy and test on all these devices, you're renting them, I guess you would say. You're using them as a service.
Brian: Yeah. That's really cool. I know a couple other large name companies. One that comes to mind, I'm sure you used Firebase prior to your time at Amazon as well. I never used their whole mobile version to test mobile apps, but it sounds familiar to that. I'm not sure if that comparison is valid.
But that's pretty cool that this is a thing that Amazon provides within their AWS suite. With that being said, is this truly a part of the AWS suite? Like if I sign up for Amplify or AWS Mobile, is it the same bill at the end of the day?
Nader: Oh yeah. It's all part of the same thing. And it's interesting that you mentioned Firebase, because a lot of people have compared AppSync to Firebase.
With Firebase you have this ability to just spin up a real world server that's already implemented, and it's managed for you, and it's really nice to get up and running with.
Because before that came out a lot of times people were building local versions of Mongo or whatever type of SQL database they're working with. It introduced this new paradigm. With AppSync you're able to do that, but maybe take it a little further because you're not stuck to a certain database implementation.
You end up having this single GraphQL layer that's a single endpoint, but you can then use any type of data source that you like. Right now first class data sources that we support are DynamoDB which is a no SQL database. ElasticSearch, you can hit serverless functions as a first class datasource.
We have HTTP in points. You can basically send a query or a mutation and it'll send that to an existing API that you have built somewhere else. Theoretically, and what we're actually seeing in real world use cases, people are able to build entire applications with a single endpoint using GraphQL and using an abstraction like AppSync.
And what we're seeing, the real philosophy behind some of the stuff that we're working on at AWS Mobile, is we're seeing this movement of higher and higher levels of abstraction, I guess you'd say. With developers being able to be more and more efficient with their existing skill set.
For instance, a front-end developer can theoretically, and in real world now we've seen this happening and if you look at some of the startups they're doing this. If you have a front-end developer that never coded back-end before that's able to implement all of the things that you would need in a real world application, like push notifications, like authentication, like storage and all of these different things that normally would be pretty sophisticated to write on the back end.
But just taking advantage of a managed service, you end up trading off that capital expense of paying and building for something for more of a variable expense.
You end up not having to pay a lot of money until you accrue all of those users. And you're also able to iterate much faster, so if you have an idea you can spin it up and test it out without wasting a lot of money on building stuff out.
Brian: The use case that I hear all the time is I believe Instagram back in the day was built on S3 to host their images. Instagram was so far ahead of the game when they were hosting their images somewhere else besides paid-for servers, and actually going there and paying for space in some warehouse.
It's revolutionized everything that we've done since then. And it's funny to see so many new companies come up in San Francisco specifically. We see all these scooter companies that are being bought by Uber and Lyft and stuff like that. Those are companies that started, and they may have been around maybe six months prior, whatever. But I mean, six months to acquisition? That's insane.
I like learning how to do front-end stuff, just generally. Because it was always a weakness for me for so long, but now I don't have to worry about all that other stuff. Which is awesome.
Nader: Yeah, I fully agree. I was in Santa Monica a couple of weeks ago and I saw those scooters for the first time in an area where I would actually to be able to take advantage of them, and I ended up renting a scooter. I was flying up and down the boardwalk between Santa Monica and Venice Beach and it was the best time I've had in so long.
Those scooters are pretty awesome. I know some people don't like them, but I enjoyed them that day. I never had to live in a city where they're everywhere. Maybe they would be annoying. I don't know. I kind of like them.
Brian: But it's a testament to the scooter business. They can focus on actual hardware, and the fact of having scooters. And all the tech side of it could be hosted and maintained somewhere else. You could also throw together a quick dev team to grow something like that together. The interface between users and scooters.
They also have these individuals that go around the city and pick up the scooters. I live in the part of Oakland where it's further away from downtown, but people will ride a scooter all the way to my neighborhood, which is like 59th and downtown being 10th and 11th around there.
People will ride a scooter 50 blocks because you can do it in 20 minutes on a scooter and pay $5-6 bucks for the privilege. I think Amazon is doing a really good job of continuing to provide value to bring people back to AWS. I paid sixty two cents last month for my S3 bill.
But everything else I do I fall under the free tier. So AppSync is something that I would seriously take into consideration for our next project for sure.
Nader: Yeah. I agree with your whole general idea that you just portrayed, because it is really true. You're seeing, especially now with the price of developers going up so fast. It's so expensive now to get a real team that knows what they're doing.
If you're able to be able to just know that you can use the service, that not only is it going to work, but the people that have been building it are specialists in that area and they've thought of all the different use cases. And you know it's going to be secure. And if you're working with a cloud provider, not particularly AWS, but there are other ones out there too. You know that it's probably going to be scalable as well.
You end up being able to look at the big picture and you're able to take advantage of it.
You're just saving money, but you're also being able to experiment again quicker. Because for certain situations back in the day, you have to have one idea and you can only build that one idea out. If it doesn't work, you fail.
But now you might be able to try out a dozen different ideas because you're able to maybe do that cheaper. And if you have that same amount of money you can just spread it out into a bunch of different areas without having to place all of your bets on a single idea.
Brian: I wanted to ask about this new chat bot example. This article showed up on Tyler McGinnis's blog, I think you had written it, walking through building a chat bot using some of these services that we talked about. Do you want to talk about that article as well, and the process of building a real life application using these services?
Nader: Totally. The idea was with Amplify, I mentioned we have all these different categories that you can use. And one of them that was just added is the interactions category. And then we also have a chat bot component that is a React component that just spits out an entire UI along with the different functionality that you would need to implement a chat bot.
But a lot of applications that are being built now are having voice interaction, or they're having some type of interaction where you're able to ask questions and get answers from the user. We have a service at AWS called Amazon Lex.
Amazon Lex allows you to build these different chat bots, and you can do stuff with them that takes the user response and maybe sends it to a lambda function, and then you have another API or you have whatever service that you're going to send that response to, and then you can bring the final result back to the user. Basically the interactions category that we added to Amplify allows you to do all of that.
In that blog post I just walk through from the beginning to the end how to build a basic chat bot. Then we take that a little further to add the response into a lambda function so you can see how that works. From there you can then really build almost anything, because you have the whole top to bottom beginning to finish process of how to build a chat bot.
Brian: Cool. Yeah. So you guys don't get into natural language processing towards the end?
Nader: We didn't add that in that post, but I do have another post that's talking about building AI and applications with GraphQL. What we did in that example app that I built in that blog post was we ended up using a GraphQL query and sending the query through a lambda function that then interacts with a bunch of different services, and one of them is a natural language processing.
So I think in that bot we take the user input, it's like a translation application. So you take the user input and then the user gets to choose what language they would like it translated into. We send that information to the lambda function since it gets translated, then the translation gets synthesized to speech, and then we choose the voice based on the language.
Because we have a few dozen different voices you can choose. So we match that together and then we take that translation, which is an MP3, and we store it in S3 and then we return the link to the client. So the user, once they get the translation back, they just play the audio on their device.
It was something that would probably have taken a lot of work to do if you think about it, a couple of years ago. It's something you can implement in 15 to 30 minutes depending on your experience with React and all this stuff. We've built it using React Native.
Brian: OK cool. I'll definitely check that out. I'm very interested more into chat bots and machine learning. It's sort of some things I've been trying to research but haven't really done much about it. I appreciate you going through that article, and I just had one more question. I was curious about the AWS CLI. Is any of that anything you touch? Or anything that you know about the work around that?
Nader: Not particularly in the AWS CLI. I've used it, I don't really work in that team or with that actual CLI. We have our own CLI called the AWS Mobile CLI. And the AWS Mobile CLI is similar to the AWS CLI, but you can do things like spinning up actual real serverless applications from the command line.
For instance, as a front-end developer, I'm not used to working in the AWS console like many people that might be front-end developers. So it was a nice way for me to get started with AWS. Because you basically install the CLI into your NPM globally, like you normally would with any global package.
And then you can just say, AWS Mobile EndNet, and then it initializes an application and not only do you have some configuration locally, but it actually creates an application in your AWS console.
And then from there, from the terminal you can add services locally, and then push them up to the cloud without ever leaving your terminal.
You can add things like the AppSync GraphQL server, you can add authentication, you can add analytics. You can add a bunch of different things just from your command line. For me, it was a nice entry point into AWS.
Brian: It's common. I know Azure has their CLI as well and a couple of their infrastructure as a service platforms are going that route. It's great for tutorials because if you're going to get super lost in the actual AWS console, which in the last two years since I've been using it has gotten better and better literally every 3 months.
So hats off to that team for sure, because I remember the first time I ever used it 5 years ago it was just mind numbing where everything was and how everything connected. So definitely check that out listeners, if you haven't been on the console in a while. But also check out the CLI.
So Nader, this is getting towards the tail end of our conversation. Anything else you wanted to mention that AWS is working on, or that you are a part of?
Nader: No, not really. I would just say that if you're interested in GraphQL in general and you want to get a first look at it without having to worry about building your server, check out AppSync and ping me on Twitter if you have any questions. My name is @dabit3 on Twitter and I love to be on there answering questions.
Brian: Cool. We do have one more section which is picks. I didn't see you update anything in the show notes, which is fine. I'm fine to go first and provide my picks while you think about your picks. These are things that keep you going, things that keep you jamming at work or after work.
My pick is I quit coffee last week. It was an accidental thing. I just got so busy, and I'm ramping up to having my second child. Back when I first started programming was when I was having my first child. That was almost 5 years ago.
And that's when I started drinking coffee was after my son was born. I mention that because now it's ironic that now I'm off coffee, but for some reason I feel way more energetic. I have so much more energy. Which rolls into my next pick, which I'm not sure if it's either not drinking coffee or it's because I'm eating healthier.
I've been doing the whole chia seeds in coconut milk for breakfast for the past three days, at least. I did maybe one day last week. And I definitely found my energy level is way higher than normal for sure. And I used to spend a lot of late nights drinking lots of espressos and coffees and coding through the night.
And I can do the same with just having a healthier life choice and food. Who'd have thought that a healthier diet would give you more energy? So those are my two picks and I think I'll pass it over to you, Nader.
Nader: How long after you stopped drinking coffee did your energy actually come to be?
Brian: I didn't even notice it. Again, coffee was more accidental. I just forgot to buy coffee. I was just doing so many meetings and traveling that I wasn't grabbing a coffee. I was just going through the day. And then I was like, "Let me just not have a coffee today." I did switch to green tea instead.
But it might have been maybe day three. But at least in the last six months I've been making it a point to not work late nights, and to wake up at a normal time in the morning. That's another thing. But that was like six months ago. I was still tired up until then.
Nader: I've always wanted to try to stop drinking coffee, but I never do it. And every time I talk to someone that's done it I hear that it's good. But I think I need to have a week where I don't need to get anything done. Because I just feel like I would be depressed that whole week. Truly.
And then my second pick is this cotton candy maker that I just bought. It's called the Nostalgia Retro Hard Candy Cotton Candy Maker, and it was like $30 dollars online. You can find it in a few different places online. And what you basically can do is you can stick any type of candy in the machine and it will make cotton candy out of it.
So that means Jolly Ranchers or Warheads, those are the things that I'm going to be trying when I get this in the mail. But it's pretty cool if you have kids, it's probably a really fun thing to do. I'm looking forward to doing this with my kids.
Brian: I think they just sold another cotton candy maker. I think I'll be replacing my coffee intake with cotton candy. Cool. I really appreciate that pick. That's awesome. Thanks for coming on to talk about AWS and AWS Mobile, and all the other stuff that Amazon is working on infrastructure wise. Listeners, keep spreading the jam.