Megan Schemmel: Welcome to This Old App, a podcast about learning, coding, smashing stuff together, breaking things apart, startups, failing, winning, and any other buzzwords we can think of.
Don VanDemark: hey Randy. So for Chasms we've been doing a lot of uh, work with Firebase and and and the Firebase database system and and you've had to educate me on on the difference between Firebase and the Firebase uh database system. So figured we'd have a talk today about Firebase in general and everything it entails. So, um, you will walk us through it.
Randy Burgess: Yeah where to start. Let's go back with what I've been using for years like for the last seven eight years, I've used Heroku for the majority of projects, clients, what have you and
Don VanDemark: love Heroku
Randy Burgess: I mean, it's a terrific interface. It's basically for those that don't know you have Amazon Web Services, which is a huge mix of various computing services that you can piece together to get your project done and you don't have to. Handle the hardware piece at all for getting that stuff ramped up.
Whereas back in the day. You may have had a a rack and a server um room or as I had at one point. I had a bunch of computers under a big desk. Then my greater that to a closet and then put air conditioning in the closet all that good stuff. And so we might the world is moved to this cloud based system where companies like Amazon web services have all these small pieces that you can you can link together to create a hosting environment for various apps and Heroku came along and when I when AWS.
First came out it was not easy to get up and running on that platform because they were learning as they went along how to make it work on the back end and they were kind of like here's a very simple and undocumented or not. Well documented API for you to use that has changed significantly, but Heroku came in and said, this is a terrific tool that people should use and we're going to build.
We're gonna have tracked the complexity out of it. And then you're going to pay us a little Mark up on on that. So I've used for years A lot of it was based on Rails that really really succeeded because rails was hot at a point in time and the rails Community embraced it and then they they opened up the the code bases the build packs for their server.
They're dying. To utilize python which your team is using and node and some others. So it's it's been a terrific, you know way to develop and to not have to hire back in devops people. So now over time Amazon realized hey, we're losing this whole chunk of change to um Heroku that, you know, we should make our stuff easier to use.
And at the same time Google was building their Cloud to compete with Amazon web services. So around that to three years ago two different companies emerged that said we're going to build a haku's on top of AWS and Google Cloud, maybe Rackspace and they were I think the parse was one of them. And Firebase was another and there's others out there.
But these are the only two that are as significant branding and the usage that I have paid closer attention to parsh got bought by Facebook and then shut down instantly. So as more of an equal higher like we want to hire the infrastructure people for Facebook's back in more than we want to actually.
Run a business that people can use like a Heroku clone on a cloud provider. But Firebase was bought by Google and what has happened over the last two to three years has been that Google has gone all-in on making this the most uncool like experience I've ever had Varane working with Google stuff because my experience working with Google has been.
Pretty good on email. I'm good on calendar and pretty much like well if I ever have a problem, I'm never going to get any support and having them ditched Google Reader over the years and maybe Google notes. I can't remember like they've ditched so many things I've used that. I've never really trusted Google as I need to I want to invest in Google products as an infrastructure for something but having worked with Firebase having taught some Firebase to my students and then actually embracing some of the Firebase features and the utilize and paying attention to the community.
That Google has actually built around Firebase. I'm starting like I've got a much different opinion about this. That's the that's the background Firebase. Um, that's where that's the the sentiments I have about it. Um, I guess I can talk now about what it actually has when you can actually do it.
So the first piece that I find valuable is they have an authentication piece and this is comparable to um, if anyone has used anything like auth0 or storm watch was one that just got bought up. I think uh Amazon has one called Cognito is the Amazon version and what this is is basically a single table of users that you can authenticate with with email password one-time passwords where the code is sent by text.
Um, you can connect it to so that you can sign people in with. Uh, Google and Facebook and Twitter and GitHub and all these other providers. It's essentially a One Stop Shop for I want to store my users and their credentials in one spot. It haven't managed by a single and a single place on a single service and then have that authentication work.
With the other things I may use on Firebase and that's really attractive when you think about how putting user data on your database is a risk in both security compliance now is a bigger issue. Being able to keep the stuff secure you have this issue of I just want to outsource authentication to a better service and have it taken care of by the professionals. And so that is one piece of Firebase that I have been I've taken a lot of time to learn and get better at and. Um, I would say is a definitely a service that is of high value on the Firebase platform and it's not that expensive.
I think you get 50,000 users right now without any costs being incurred which is pretty crazy good and the the setup is not overly complex. Um least from my. My background I didn't I there's some things about it that I was getting done with Rails that um is a little bit different but it hasn't been overly complex that it's maybe too frustrated is not as easy, but it's also um better than hosting my users and authentication on my database using Devise.
I think that's. It's fine, but it's just a huge risk. I don't want to keep owning on my on the apps and stuff I build so that's authentication.
What most people the next feature is databases, data stores. And that is what I think most people this is how most people get introduced to Firebase is there are two different databases now on Firebase. One is called the Real-Time Database. That's been around for a couple of years. When I teach the curriculum that I taught at Northwestern we taught students almost within the first four to five weeks of this is how you connect to a data store in the back end and it actually the connections keeps listening for changes and then you can update real time.
That's a real time part. So essentially it's connecting by a web socket or some kind of fast long polling. And if you have a database and you're listening to a snapshot of data, whatever that snapshot is, and then all of a sudden someone inserts or record into that snapshot all your page, if it's built correctly, will update automatically because it recedes this callback that says, hey this what you're listening to, what you're watching, changed, which if you did this with a Postgres on the back end on a different service, you'd have to keep on hitting Postgres to see like hey, did you have new data for me? So that my students like I when I first now the trick is is that the Real-Time Database is strictly a big JSON object.
That's all it is like. There's nothing else to its structure, to its um schemas, to its power. Like it's got a simply as a humongous JSON data store and it comes with this real-time connection. Now that may sound attractive if you've worked with JSON as an API, but when you talk about persistence much different story.
Because if you come from a relational database background like I do, like both of us do, I think you start to realize like whoa, like, how do I handle relationships with this? Right? How do I do queries with this? How do I do like, how does indexing work. And you learn really quick that JSON was not meant for persistence.
Don VanDemark: I I think you ran into a couple of of queries you were trying to reproduce and I ran into a couple I was trying to reproduce and we're banging our heads against the wall and we end up pulling data and then manipulating the data out of once the data is pulled which goes against all the principles we're taught which is manipulate the data as close to the data sources you can yeah.
Randy Burgess: Yeah, it's it's just I think it feels to me like when Firebase was built there like well, what's wrong with JSON as data, as a persistence layer what's wrong? Like what could go wrong? And it took some time to figure out. Wow. This is just not right, like the way you do indexing to do queries against it on multiple attributes or multiple columns is almost like you have to create a combined column to then represent the two so then when you make updates you have to update the. It's crazy town in terms of how you really want to handle data.
So what has emerged from this without quite the dramatic way I introduced it. Um was that Google has launched a second data store called Firestore and. It's really now... Firestore is essentially what we know, um Couchdb and Mongodb to be which is documents stored as the documents and collections and documents and collections and you can have relationships between those collection documents and stuff, which is much more relational but it also empowers you to have indexes that are reasonable, query on multiple columns or attributes. Um, anything that Mongo gives you it, Firestore is giving you that same power and that same structure which to me is more reasonable. Now, I don't what I what I haven't figured out and this is what people need to keep in the back of their mind, is the both of these data stores are priced based on scaling.
They don't, like Google Firebase doesn't really want to charge you for much if you aren't doing if you're just developing and you don't have a big use case, but what they are hoping is that you build something viral that takes off and then they can start to bill you because in theory that usage is translating to revenue and your side and then infrastructure payments on the other side,
Don VanDemark: right
Randy Burgess: and so they have they they give you good documentation on this is what you'll end up paying. They have a calculator that you could say I'm using this much but when you're building something brand new and if you don't have a lot of experience, it's kind of hard to know what will I end up paying for this and there's some horror stories out there where Firebase made some corrections to their um, tracking and analytics and all of a sudden they start charging people a thousand dollars a month and they got caught in this scenario where people did no idea they were going to get you know billed this but let's just say if you have an authentication store of 50,000 users and you build a viral system where you have thousands of people connected at once to using your product, your hosting costs are going to go up like right the free the free lunch goes away once you start getting into those kind of numbers and that's just natural to expect that. So but it's important for people to use the both of these stores with the knowledge of what it costs once you start getting into thousands of reads and writes and multiple gigs or a terabyte of data like this stuff does cost money. So just keep that in mind if you're going to build on these things that this is a as long as you're building on it you're going to not pay much at all.
But if you get down the road you're gonna, you need to consider what you're scaling cost will be now. Even then a thousand dollars a month doesn't sound like a lot to me for a business but for a start up, you know, that's you're talkin 12 grand a year, you know, that's still something to to recognize
Don VanDemark: for sure.
Randy Burgess: Um any questions from you on the store data stores are stuff that you've noticed.
Don VanDemark: No, the only thing I've noticed really, I mean that there is. The ease of use of setup is fine. Um, I don't think it's all that hard necessarily to set up a Postgres database. Um, so I don't know that that much easier, but the um, I've had more problems than than revelations that it's easy to work with.
Uh, like I said, we I had one I had one query I was trying to create where um, it was I needed everything ordered in a certain way. Um, and it really based on the the googling I did it's like, yeah, we're gonna kind of give you everything in a JSON object and since it's an object, objects are ordered you use arrays for that. So no, you're not getting it in the order you want it so like I said, it was more of yeah you go pull all the data you want and then you're responsible for ordering it which is just so completely um, backwards from what we're used to that that it actually blew my mind for bit and I'm like, I don't even know how to do that because I'm used to getting data ordered.
So, uh, it took just a little bit of work to figure out how to order the array but after that it was fine, but you know,
Randy Burgess: and and that that is a big issue with how you price these things because cloud firestore does charge you based on volume of what you transmit back and forth but the difference with Cloud firestore for what you're talkin about is that with Firestore you can limit what you get back and real-time
Don VanDemark: you can real time to that. There are there calls you can make to limit but it, there was no way I figured that I could structure the query to limit based on what I needed unless it was going to do some ordering for me first. So if it's not going to do any ordering, I can't limit it I have to pull everything and then limit and that that that plays right to what you're saying.
Randy Burgess: Well the other the other nastiness on the real-time is that if there are scenarios like let's say you have a blog post and you have a user it's much more efficient. To take the entire user profile and store it on the blog post object so that you don't have to query both to get the data for both or you get there's no joins, really so you have to so they actually recommend you do this crazy, awful, um denormalization, where you're storing the entire user profile on the blog post.
Because they you should you only want to be doing one query to get all that information. I'm like that and that's nutso, like I'm not I'm not trying to be the dry the DRY-est person out there on the don't repeat yourself scale, but putting an entire user profile on a blog post to make the query work better is just nutso to me.
Don VanDemark: And and of course we were both were both a little old school. So maybe maybe our brains aren't as elastic to seeing the possibilities as as uh, as we should be but I I think you've certainly done enough work with with it to have a feeling for if it's performing the way you want. I'm having trouble seeing that it could ever perform the way I want.
Randy Burgess: Yeah, and I like the so the the big gap for me on this whole database on Firebase thing is would it be wouldn't it be nice if there was cloud postgres? Like that's what I would love because, I've already figured out how to really make postgres and migrations work in um the Node world for me, but it just doesn't seem to be what Google wants to add right now to this, um set of tools so but there's nothing like I know people hate Mongo there's definitely old school folks seem to hate Mongo more than the newer newer folks. But I'm I'm I'm happy to use whatever we can use to get the job done and so that's what we're using on Firebase.
So that's the like authentication and database have been what I've been the most focused on but the next items are things that I haven't used yet because just because I've used other tools that are getting the job done. But this is what you can also do with it.
Um, the next item is storage. So if you're if anyone's familiar with Amazon S3, the simple storage solution, they've had for years which is also typically fronted by Cloudfront which is another Amazon service that essentially acts as a content delivery Network, a CDN, that how these work is if you have a let's say you have a logo for your company on your website. With Amazon S3, you would take that logo file and put it on Amazon simple storage, which simply is a directory online that you get to say, hey the world can see this file or only this app can see this file or only this person and it's simply a storage thing. There's I mean simple storage and that's all it really does.
And then Cloudfront sits on the front of that and says, all right, I'm going to take this logo, it's if it's available for the public, I'm going to push it to a server in Japan and a server and Argentina and a server in in the Eastern Europe and a server in Africa so that when someone hits your webpage and they need to get that heavier file of the image, they actually ask for it closer to their home server.
Sure, and that's how a content delivery network works. So storage in this case is, Firebase Storage is the answer to Amazon's Cloudfront and S3. And the idea is if you're building an app that has a number of assets whether it's fonts or images or whatever you can store all of these things in there and get that same benefit.
Don VanDemark: right?
Randy Burgess: And I haven't used it yet. I've used Netilfy a lot in the last year and I love I think they've done a tremendous job with that service. But this is where you can do Firebase store like in one spot. Um, actually I'm actually mixing up two surfaces Firebase Hosting is the Netlify clone.
Firebase storage is the S3 clone and the cloudfront clone, right? So so actually you have two different services on Firebase that can do everything I just talked about.
Don VanDemark: I want to stop you there and I probably just stopped you on a big pontification. But is that is that not part I'm having problems with the the the branding of Firebase because I I find I find it hard to talk about all the Firebase things and understand which thing I'm talkin about. Um, and you just worked worked your way through it as well. Um, do you find it difficult in conversation to talk about the right thing because the branding is, uh, all Firebase all the time and you have to insert the I guess adjectives to or I guess the services themselves to get the right one out
Randy Burgess: and it's a little bit. I mean the Firebase, Firebase that is core was Real Time Database write all this other stuff was like the reason is still called Firebase is branding but everyone knew Firebase to be with the Real Time Database was and that's what you were talkin about. So, now, yeah, it is harder to talk to people about it and not confuse are you talking about our RTDB or are you talkin about all this other stuff they got going now
Don VanDemark: right?
Randy Burgess: But but I guess it's harder from if you aren't in in the dashboard a ton, then yeah, it's going to be harder to talk about it in these broke broken up services, but once you're in it it fades, okay, that's the problem.
If you if you're trying to unboard people that is a complexity. I think. So, I would say that the of the most important services the the let this last one is where you start to get more power, and that is Firebase Functions. So we talked in the past about serverless functions And what is this whole deal with the term serverless and all that good stuff.
And so what it what ser, what Firebase functions is, is the same thing that Amazon Lambda gives you and Netlify functions and some other services that just let you essentially write a in theory a single function, piece of code, push it up to the Internet with a single API call and allow it to take some input and then return some output.
So if if you've used Express or really, uh rails or however python Django does it. If you were to take a single route, connected to a single controller, and have that controller do some magic and then send a response back that single line of work of request work done response is essentially what a function is a serverless function is acting like on the internet except that all you know, is that you'd have this function you pushed it up there to a server.
And then you wash your hands with all other responsibilities. You don't have to worry about where it's hosted, if it's kept alive, um, if that server if that function is spread around through, in this kind of content delivery network sort of way the load balancing the all that stuff you don't have to worry about any of that infrastructure.
And so the the nice thing is if you've liked with amazon web services their several functions, and you've used this with a the Alexa stuff, to me. It's in, at least from my early experience, the Lambda is strictly in a proprietary approach that Amazon came up with for how Lambda functions should be built.
But what I've seen in Firebase Functions that if you know how to use express like node Express.js, basically building, they simply built their functions to work very much in either, they're using Express or it's an Express like format, um or chain of events or schema or whatever you want to call it.
So I found that I was able to get Firebase Functions working like boom and it took me a good chunk of time to figure out how Amazon wantss to set up Lambda and I don't know if you've looked at Firebase Functions, but what's been your experience with the Lambda stuff.
Don VanDemark: So the lab does stuff. Um, it struggles I struggle with it from the setup. Um, so anything on AWS I usually struggle with setting up because I I find that I find all the permissions and roles and all that, um confusing. Um, and initially when I was doing it with the Alexa stuff and this is this probably its own episode. Um, they initially the way you got the information there.
Uh into the Lambda function was you either copy and paste it into their dashboard or you zipped up a folder and uploaded it. That was the two ways to get it in. Um, they have put in a command line interface finally to where you can just uh say A S K deploy and it'll send it up for you, but. Um until until just recently that's it's been a pain.
Um, but but yeah that the the fact that serverless function certainly, um helped and not having to set up a Heroku instance just to host Alexa stuff
Randy Burgess: now, I will I'll say I got something to work on Firebase Functions that I now deeply believe should not be done. Which is I took um an entire Express site with , it had HTML templates, handlebar templates, had multiple routes, um had a just your typical kind of something that we have hosting on Heroku and I loaded it into Firebase Functions and I ran a website from Firebase Functions not for like a bunch of people but as a prototype, and I really found that I was pushing the limits for what Firebase Functions are meant to be. Functions are meant to be like single pieces of work or microservices, you may want to call it that takes in is kind of handling one route and one response doing one piece of work, and if you set up an Express site your kind of dealing with multiple routes and multiple pages and or maybe you're doing a single page app and but I didn't find I found it to be clunky, I was commonly fighting against what Firebase Functions thought it was supposed to do versus what I wanted to do.
So I wouldn't recommend people do that. It's possible. I got it to work, but it just didn't look like this is not what Firebase Functions is not supposed to replace a dyno, it's not supposed to replace a host and if you set up an Express.js, or Django, or Rails type of back-end that's not what a serverless function to be, I mean a dyno, a dyno kind of is tha,t but it's not this more it is and and
Don VanDemark: you essentially tried to put a web server framework and Express on a serverless thing, a serverless function.
Randy Burgess: But I did it. I mean it's kind of like riding a bike without handlebars or first time, you're like, this is great as your mom's heart beat starts fluttering in with fear. And so that's what I felt is just like I did it. It's cool. I wish I could like, you know, give a high-five but then this is a bad idea and so I am not going to do it anymore. But it and I am hoping down the road that maybe Firebase adds a service that lets you do that but I think the idea is that you don't need to especially if you're doing single page apps, there's only one point of request kind going in.
So that covers the features that I've used so far. There are some others that like they just released at their local conference or there, uh annual conference machine learning kit, ML Kit and. I haven't like I really haven't gone too deep into machine learning but this is the first um, friendlier interface based machine learning software development system that I've seen and now it's actually a kind of a first state like a first-level client or a package on the Firebase service list.
So you know, I think we'll start to see more companies that have the ability just to start plugging and playing machine learning versus all the infrastructure you had to set up before. So that's going to be interesting to see. They have a number of things that I am going to be using with a project soon that I just haven't used, Crashlytics is one, Performance Based tools is another and then test, device testing which is actually what I'm kind of excited to see.
Instead of having to buy four or five Android phones, in theory you're able to test on devices through Firebase. So I'm going to those are some additional tools. I have tons of other stuff that I really haven't had a chance to get into but looks really attractive for you know, what someone using Firebase will possibly need to use.
But the, I think the the one last point I'll make about Firebase that I think shows me the investment Google's making into this is the community around it and that in not so much more of Google, for the first time that I can remember, is hiring people strictly to be there for support, public support and video and tutorial creation.
So they have a woman named Jen Person who is really good with interviews and being kind of at the forefront of the personality of the Firebase community and I feel like they've had her on consistently to kind of be a face for, if you're trying to learn stuff, let's talk about this in non-technical terms, which always helps a code, a service reach the developer crowd that's kind of moving up in the world. So, I feel like having people like that is a great boost. They have another guy. I can't
Don VanDemark: hold on that for just a second. What did you say her name was? Jen in other words general or generic person. Are you sure that she's a real person? She's not just part of the Google AI.
Randy Burgess: That much I can't tell you and I don't I what's sad is I'm like, I don't know, I mean think about this she seems to be a real person. Um, And her Twitter feed is filled with cats. And I don't know if I like cats or dogs. So we'll have enough.
Don VanDemark: AI is a cat person for sure. But
Randy Burgess: when Jen person when Jen person starts making appointment calls for you, you know, we've been duped the whole time and
Don VanDemark: I'm sure Jen is a very nice uh person um, we're just we're just having fun at the expense of her name.
Randy Burgess: There is a pert. There's another individual. Let me find the I see if I can find this person's name. Basically, they hired a there's a guy in he was going on fire on StackOverflow and answering like every single Firebase question that was popping up and he actually answered one for me within, within like a few hours in the asking it and they hired him. Um, his name is Frank, Frank van Peffelen. So I think people just call him Puf. And so what they have is an employee at Firebase that is kind of their um, their official StackOverflow answer guy. And he just goes and answers stuff. Now he answered one of my questions with I think you're over optimizing and you don't need to think about this, which I call I was like, oh, no do not ever say that to me, I think about everything, that's my job.
He was right. Like I didn't I don't have an app that needs that scale. But when I ask questions, I asked questions for two years down the road sometimes and so I just wanted an answer from him. Is this inefficient? And does this make a certain number of calls?
I don't want to make but that I didn't like his answer because I didn't like someone telling me you don't need to worry about this performance issue, but the bottom line is that actually had someone out Google answer a question within an hour. And that's to me insane. Like I have never asked a Google infrastructure question and ever got an answer from Google.
Don VanDemark: That's certainly a change.
Randy Burgess: That's that's just in Crazy Town talk. Does that someone I Googled actually answer a question for you. So that that is to me another indication that oh, maybe they're understanding that the Amazon way of cloud services and development is not necessarily going to work as well as what the the Firebase method and then there are probably three or four additional people in the Firebase team that are routinely creating videos and tutorials that I found really valuable like the YouTube Firebase channel is outstanding tons of great data. It's aged well, so you can watch stuff that's a year to two years old and you're not thinking of this is way out of date and you can learn a lot from just what Google is pushing out there.
So I feel like if you know, you know, the risk is always at Google says, oh we're spending way too much on this there's not enough people signing up and then they digital just like Facebook did to Parse, but I'm hoping that's not the case because I think that these tools make it possible so that a small team can get a whole lot done.
And that's what I'm hoping that Firebase, which is what Heroku did for us and I'm hoping that Firebase makes it even more. So because Heroku stopped at providing services beyond the dynos and workers and just said everyone all these other companies come in and bringing these services in and it's still a lot to manage to some degree.
Whereas having it all under the roof of Google in some ways makes it easier. And so I'm I'm liking where Firebase is going. I have more faith in it now as compared to any Google service that I've ever used and I feel like they're doing better and better on the documentation and the support side which I've never seen out of a Google product.
So that's that's my long-winded rant rant on services and prospects for Firebase.
Don VanDemark: Well cool. Um, I I think I think obviously we're going to continue to use it where you continue to grow in it. I'm the. The interesting thing you said there about the community is something and not even the community so to speak but the company dev support is more a correct term for um, I'm finding the same thing with Amazon.
Um, and there are there Alexa, uh, dev evangelists and their Alexa Dev Team. Um, they put out some outstanding work. Um, I've seen a few of the Firebase of videos and those are great videos the difference I'm seeing right now is and I'm not saying I guess I am saying one's better than the other but it's personal preference, um on the Amazon Alexis side, they're doing twitch livestreams of working through building a skill, which has been uh just a revelation because you see that these people that know how things work you start to see their struggles and where they go. Oh, yeah, we got to do this to solve that problem and you're like, no. I've been trying to solve that forever and and now I see that they struggle with it and they struggle to remember it.
So, um, yeah, so certainly uh, I I'm really really complementary of the uh, Alexa dev evangelist team.
Randy Burgess: Yeah. I feel like that kind of goes for all these companies that want to provide cloud services like you're not going to make scale if you don't teach people how to use your stuff. Like you can hope that there's going to be a slew of developers that just love to dig in and learn everything from scratch with you know, trial and error, but end of the day, you got a lot of companies and a lot of startups are very small teams and they need to get these services running fast and the point of least resistance of what people going are going to move to. I mean, if you think about why we're using Firebase with Chasms, it's some of its because I honestly we would have like double the amount of stuff done right now if we used Heroku and Postgres.
Um, I it's just so easy to me and so in some ways we're going against the grain on startup talk of, go with what's easiest get something out there, ramp it up. We've been using this as a platform to learn the new way of develop sure that's an investment on that's an investment on our part to stay relevant with technology skills, to not be stuck in our ways.
And when we've had this discussion already where I was like, screw this I'm going to go back to Heroku and Postgres and you talk me out of it. So, you know, the the using doing it the old school way is still a temptation constantly, but after working on it through a weekend, I'm like, okay, I feel less in the dark, I feel more comfortable, and I feel better for learning it, but if you were to have a 360 review on my productivity the last couple months you would be hard-pressed to say, wow, you got a lot done compared to what you already knew how to do.
Don VanDemark: This is all been. This is all been about making the investment to learn because we're not trying to ramp out a company out there to get you know, VC funding or anything. We're doing this at least 50% to learn and then 50% or the business.
Randy Burgess: So, so anyway, that is Firebase. I think it's a great system and people should give it a look. It's its production level quality and getting better. And the real in Google's pushing it hard. So I think it's worth a consideration for teams looking to reduce their devops count of employees and get things wrapped up in the cloud,
Don VanDemark: right? Cool. Well, that's that's really cool. And and I think completely completely differently as as I said, I think we're going to do another one of these episodes on on Amazon because Alexa, because we both we both uh dealt with that and I've been dealing with it more recently. Um, and and it's it's similar and it's also different in that you don't have to write a lick of code to get an Alexa skill done.
So, um, there's there's lots of interesting things going on there. So and I think we've also got a got one more project that I'm going to work on this weekend, um that belongs in this whole family of things we're doing I'm going to be trying to put out a video on um, explaining GDPR to non-technical people.
Um, And that's that's all that GDP are being the new European Union, uh regulations on privacy. So that should get out there. I'm hoping early next week as well.
Randy Burgess: Awesome. All right, we can talk next week
Don VanDemark: sounds good. Thanks later.
Megan Schemmel: Thanks for listening to This Old App.
Notes and previous episodes can be found on our website at https://www.thisoldapp.online.
Reviews on Apple and iTunes are always appreciated and help promote the show
For questions, comments, or things you would like to hear on future shows, please email us at firstname.lastname@example.org
Show music is Guns Blazing by Fab Claxton, music licensed by pond5.
Voiceover work by MeganVoices.com.
You'll hear from us soon!