MLA 013 Tech Stack for Customer-Facing Machine Learning Products

You are listening to machine learning applied, and in this episode we're gonna talk about Tech Stack. Now, I know I've talked Tech Stack a lot in the past, but we're gonna get a little bit more specific at this time and we're gonna cover a broader spectrum. We're gonna talk about client mobile, server database and job server. Job server being your machine learning server. And I'm gonna make very specific technology recommendations in this episode, and it's intended for people who really don't have an opinion, maybe one way or another, or aren't using some specific web front end framework or cloud hosting provider. If you have your tried and true tech stack and you like what you like and you're using what you're using, you can go ahead and skip this episode. But if you'd like some recommendations on where to start building out a machine learning customer facing product, then this'll be an a good episode for you. So this episode assumes that we're talking about a customer facing machine learning product. If you're gonna be developing machine learning for a research project where you have a stakeholder who wants to know the predictions based on some data set, or they want to see some charts and graphs or some reports, and then what you do is you develop your machine learning model. You'd train it on your workstation or do your own thing for parallelizing your machine learning training across multiple servers or workstations. And then you'd get results back, be they reports or predictions, and hand that back to your stakeholder. That's not what this episode about. This is about a customer facing machine learning product where you have a web front end, a website or a mobile app, and uh, you have customers signing up on your website and so on. Here I will talk about the technologies I use personally and that I find valuable and, and prefer over their competition. So the full tech stack goes like this. You have a server, we call this your app server, and this is the server that sort of is the, the brain of the operations. It is the CEO of your, of your product. It communicates with the web front end, the mobile front end, and then your job server being your machine learning server. So it's the central hub, your app server, and then you'll have various clients. So you have your website, we call that a client, and you have your mobile app that's also a client. And then finally you have your job server or your machine learning server, and then various components that glue all these parts together. For example, communication between the. App server and the job servers is often done by way of a job queue like RabbitMQ. But there are other solutions that we'll talk about in this episode. Now, here's the stack I usually go with. Let's start with the client. You're gonna have a website and or a mobile app. The client framework that I prefer is called React, R-E-A-C-T, by Facebook. It's a fantastic JavaScript framework for web development and mobile app development, and when I landed on React after a very long. Career in web development. It was night and day from its predecessors. So I started with raw JavaScript and then I moved on to jQuery built front ends. Then I moved on to backbone JS and then angular js. And these were all felt like sort of incremental improvements, but when I moved to React it was night and day. It was just that the framework handholds you so effectively. Without reducing any flexibility. So you have as much power, if not more power than alternative frameworks without any lack in flexibility. And another aspect of react in the way it's composable structured, the way everything is nested, they call this sort of functional programming paradigms, is it forces you to follow good practice. So it's quite difficult to do bad practice, react. And especially if you're using state management libraries like flux based libraries, one is called Redux. The one I use specifically is called Easy Peasy. It makes developing a web front end, just it's almost difficult to do things wrong the way that the framework encourages you. To nest components in this composable structure that follows functional programming paradigms. It's very difficult to, to mess things up, to create spaghetti code. It's obviously possible. It's and, and, and done fairly frequently, but by comparison of its predecessor history, it encourages best practices that feel good. Another aspect of React is that it's just, it's just the most popular web front end framework out there, and so you're very likely to find good resources, tutorials, documentation, job opportunities, employees, libraries, widgets, et cetera. A popular competitor client framework out there is called View VUE, and it's really up and coming. It's really hot amongst certain web developers who swear up and down on view overreact all day every day. But there's this JavaScript survey that goes around yearly called the state of JavaScript, as well as a comparable one for CSS called the State of CSS. And if you look at that survey still in 2020, uh, react is dominating the the workforce. So if you don't already have a client framework that you use, be it View or Angular, et cetera, then I highly recommend React. Choose React for your client framework. And another reason I recommend it, the the probably the biggest reason to recommend React in my personal opinion is that it has a sister project called React. Native React native compiles native mobile apps using a, a fair amount of shared code in your React project. Now, that's not completely true. React native sort of has its own component library that it expects you to abide by so that it can effectively transpile from JavaScript down to native iOS and Android code. You can't just use. Any old React code you'd be using on your web front end. However, the fact that they're both in React and JavaScript means that there's a large amount of shared code that you can do between your web property and your mobile property, and you don't have to learn native iOS development and native Android development. Native iOS development would be objective C or Swift. So those are two programming languages, and you'd have to. Pick one over the other. Very likely most people go with Swift when they're developing native iOS. Most people go with Swift when they're developing native iOS clients, and Android has any number of programming languages you could choose from as well. Java being the traditional programming language. But using React native allows you to write all your code in one programming language, that programming language is JavaScript, and share a fair amount of component code between your web app and your. And your mobile app. So it allows you to save a lot of time, both in headspace of needing to know multiple programming languages and programming environments, but also in literal code that's shared between the various properties, your website, your Android app, and your iOS app. So React plus React Native for your front end. Now for your backend, your app server, you can use any number of server frameworks out there. There are very popular ones out there. Node js is a very popular choice and naturally so because one, if you're writing your website, iOS and Android app in JavaScript by way of React and React native, you'd naturally want to write your server code on JavaScript as well. One language to rule them all. So node js allows you to write JavaScript ran as a server on this V eight engine, but the second benefit of node js is it has very strong concurrency support. It's really good at parallelization of client requests to the server. Where previously server side languages and frameworks struggled with this concept, namely Python, PHP, and Ruby on Rails had trouble with, uh, first class parallelization support. Nowadays, almost all of these frameworks have parallelization or concurrency, we call it concurrency, is being able to handle multiple web requests and IO requests at the same time in an efficient manner. Now all these languages and frameworks have concurrency support in one way or another, but it's typically not first class, it's second class. It's, it's sort of bandaid patched on and difficult to manage. I myself use Python for my servers generally. Because I'm writing so much machine learning code in Python, I'd like to sort of be very good at one language and its libraries. So I tend to keep my server side code on Python by way of fast API, which I'll talk about in a bit. But Python servers not having first class concurrency support, it makes dealing with concurrency something you have to always keep in mind. It's not automatic. It's not by the very nature of the language or the framework you're dealing with. So if you're gonna write your server from scratch, I would recommend node js and the express framework. Express JS sits on top of node js. Node js is literally just JavaScript on the server. On this V eight engine allows you to run JavaScript on the server where Express JS sits on top of Node. That provides helper utilities for writing rest APIs. It's very rare that you would just write a node js server. You would typically use a framework that sits on top of node js and a very popular one is called Express js. Now what about other languages? There's Ruby and Ruby on Rails, of course. Very popular. I'm sure you've heard of them. I would say it's. Probably falling out of favor due to its competition. Um, Python, of course, has all sorts of web frameworks. Uh, one is called Flask, another is Django, and another is fast API. So let's talk about these for a little bit. Django is probably the most well-known Python web framework, and Django does everything for you. Nuts and bolts. It's sort of the ruby on rails of Python, and typically this. Also includes, uh, database setup and a object relational mapper. So ORM or object relational mapping is the concept that you write your code in a Python way using this Python, API that maps your object method calls and data setters and getters to SQL code. To database access code. And so it makes marshaling data to and from the database much easier by way of Python than having to know SQL code so that you can write direct SQL queries. So Django, DJ A NGO. Provides an ORM and it also provides, um, a templating library so that you can write your web front end code directly marshaled from the Django server to the client. Now I'm gonna just move past Django because it really is intended to do everything for you beginning to end. It's, it's intended to set up the database structure for you, run the app server, and render the client. Render the client. In other words, using a separate React web front end. Sort of going against the grain. Jango hasn't traditionally been intended for rest use cases where you have your own separate web front end and mobile app front ends interacting with your app server as if they are two completely independent components of the architecture. Django is an all-in-one. Where both the server and the client are managed by the framework. That's not a very common way to build products these days. Nowadays we like our properties to be separate. We want a front end team managing their front end code separately using whatever frameworks and libraries they like, and then the app server team managing their rest server in whatever way they like, and then the database guys doing the database stuff, et cetera. So what became popular for REST servers on Python backends was flask. F-L-A-S-K Flask is a rest first, uh, API server. It's intended for REST APIs and therefore assuming that you would write your client separate from the flask server, that that's not an all-in-one managed package. Now, a small note for that to function, what you'll have to do is enable cores. CORS enable cores so that it can receive web requests from a separate client that's not being delivered by the server itself. In other words, the web front end exists somewhere else, whether it's being hosted on something like Netlify or AWS S3 plus CloudFront, it's not the same domain serving the client as the domain serving the server. So Flask was really popular for a very long time, and I used Flask exclusively for a very, very long time. But there is something better out there that I, I highly recommend. It's called Fast, API Fast, API. And what makes Fast API, in my opinion, better than Flask is its. It's first class support for concurrency. Remember, one of the reasons I said node js is a great server backend tool, is that it has first class concurrency support something that's traditionally lacked in Python and Ruby and PHP backends. Well fast. API does a lot of legwork in order that the framework can provide first class concurrency support on par with node js style code writing. So if you want concurrency in flask or Django, and that concurrency involves both io, whether that's marshaling data to and from your, your database by way of SQL Alchemy or some other ORM and requests to the client, your React front end or your React native mobile apps. Doing that in flask or jango is, I would say an absolute nightmare personally. But doing it in fast API is baked into the framework. That's what it's for, is to provide this first class concurrency support. But beyond that fast API has become a lot more popular in recent times in the last few years. And as a result, there's just so much more zeitgeist behind Fast API. There's a lot more steam in the community, like pushing it forward. More third party tools for authentication. Uh, user account management communication with various APIs. File management database, connectivity with concurrency, et cetera. So what happened is I was using Flask up until about a year ago and I just felt like the Python Server framework world was dying. 'cause I wasn't seeing a lot of new stuff happening in flask. And a lot of these libraries that I was using on flask had had like their last commit. Two or three years ago, even though they're the defacto libraries to use in flask. So I thought I had made a mistake by using Python on the server and that I, I should have gone with my gut and used node js on the server. But it turns out that everybody had moved on to fast API and I just didn't notice. So as soon as I switched over to FAST API, then I realized a lot of these libraries have a lot more steam behind them. They have recent commits, lots of contributed. Lots of open GitHub tickets and all these things. So if you're gonna go Python on your server, then I would recommend Fast API rather than Flask or Jango. And then of course, there's a whole bunch of other server programming languages you can use server languages and frameworks. Uh, one very popular one with consideration is Go, go Lang, GO. It is in the, in the same vein that node js is sort of obsessive about. Concurrency Go is even more obsessive. Go lets you milk the most screaming to the metal performance and concurrency that you could possibly get out of your server code. It's almost like writing your server code in C, but with a layer on top that makes it easier than writing in C. So any of the Go Server programmers that I know. Or they just swear by it. They say all the node JS people. Oh, they don't know what they're missing out on and so on. So my recommendation is if you're gonna write your own custom app server, well, I personally would recommend you pick one of three languages. One is JavaScript, AKA node js. And the reason you might wanna choose node js for your backend is if you are already writing your front end code in JavaScript, which you are. Uh. On React and React. Native. React for the web front end and react native for your mobile apps. Well, you already know the programming language, JavaScript and Node js has this really powerful concurrency support and a very. Very strong communities. It is probably the most popular backend language out there, so you will be able to find any library you could possibly imagine and uh, any number of frameworks supporting whatever use case you may have. But the most popular framework out there being express js. So Node is usually my first go-to language for a backend express being my first go-to framework for the backend that I recommend to people who don't know what they want to put on their backend. One, because you already know the language, and two, because it just has such powerful support, performance, and concurrency. There's just no going wrong with Node. You just can't go wrong. Uh, if you are a total gearhead and you just wanna milk the ultimate screaming performance possible out of your server, then I recommend going with Go Golan. But if you prefer to keep everything in Python, because all your machine learning code is Python as well, which is a very valid use case, uh, then I would recommend going with Fast API Fast, API on Python. And one big reason to go this route is that. Whatever tooling you're using in your machine learning stack, that's not machine learning related directly. For example, celery as your job server library, if you're gonna be using celery to wrap around rabbit MQ for handling your. Your jobs on your machine learning server, well then you might as well just recycle that knowledge on your server server and use celery over there as well. So there's a lot of tooling that will be common between your machine learning server and your app server. There won't be too much overlap, but whatever overlap there is, you'll be happy that you're able to use a lot of that shared knowledge between your app server and your machine learning server. It's kind of like the argument of using React and React native, because there's so much overlap between the two. They're obviously very different. A, a mobile app is very different than a website, but with the amount of shared code and knowledge between the two, there's, there's just a huge benefit. So that's the argument that can be made for using Python as your server. How about database? Now you're gonna be wanting to store your data somewhere. Uh, I personally recommend Postgres. Very popular options out there are MySQL or my SQL, uh, Postgres, MongoDB, and SQL Server by Microsoft. Um. Typically what I see people doing is they use SQL Server or SQL server by Microsoft if they're using the Microsoft Tech stack. So that tech stack will have on their app server, on their server backend will typically be asp.net or C sharp using the microsoft.net framework, and then they'll use SQL Server as their server. But outside of Microsoft Shops, I don't see SQL Server use that frequently. It's really sort of the, the driving, uh, database for the Microsoft shops outside of the Microsoft shops. The, the, the three most popular that I see are MongoDB, my SQL and Postgres. And in my opinion, the, the, the best option is just Postgres, almost hands down, almost. No matter what the circumstances, that's a, a very bold, probably inflammatory statement that could get me into some trouble. But I have used MongoDB and my SQL in the past, and I just find the benefits of Postgres, uh, flying colors. Uh, MongoDB real quick is what's called a NoSQL database. You don't write SQL Code. SQL or SQL is the language of relational database management systems, RDBMSs and in RDBMSs the the traditional database of the last 2050 years, like my SQL SQL server. Postgres, everything is stored in tables, and then everything in tables is stored in rows and then columns. So it's almost like a giant spreadsheet with multiple sheets. Okay. And then the way you combine all the various rows across your tables is using the SQL query language. And this provides you with immense flexibility and power. You're listening to a data science slash Machine learning podcast. I probably don't need to be telling you any of this stuff. I'm sure you know all of this stuff, but SQL and SQL based RDBMSs are just extremely versatile, flexible, and powerful. What they lack, I'd say. Intuitiveness is ease of use. Unless you are a data scientist or have studied RDBMSs and NoSQL, it takes quite a lot. There's a heavy learning curve to using SQL effectively, making sure you're getting the right performance with your primary keys and indexes, and proper utilization of foreign keys and aggregate. Functions and all these things. What MongoDB and other NoSQL databases provide for you is that their data is stored in tree structure, just like a JSON object would be a JavaScript object. JS ON object. MongoDB stores this data in hierarchical structure, which is very intuitive, very obvious. So if you are a JavaScript developer writing React front end code, node JS server code. You're just used to that sort of lifestyle, then MongoDB is the obvious choice from an intuition perspective. You want a user, well, you fetch that user and that comes with the username, the address, the password, et cetera, and then the address gets broken down into street number, street name, city, zip code, et cetera. Everything is stored hierarchically where if you were to try to do this with SQL Code, you would have to join your tables in, in such and such a fashion. So in my opinion, I think MongoDB and NoSQL databases got really popular because of their intuitive use. That's obviously not the primary reason that companies choose NoSQL databases in the wild. A major reason is the performance gain that can be had if your data is truly conceptually hierarchical in nature. There are times where this is the case, and that using a NoSQL database and the tricks they're in, such as MapReduce and such and stuff like this, give you, uh, performance gains on very, very large data. You know, terabytes of data, but you'd really have to know when and why you'd. Want no SQL in these cases, you really have to motivate the reasoning behind choosing no sql. In other words, what I'm trying to say is if you don't know that you need to be using no SQL databases, you probably shouldn't be using no SQL databases. You should probably be using RD BMS as like my L and Postgres. If you definitely know you want no SQL because of some technicality or another, then of course. Go with a NoSQL database like MongoDB, but I would say nine times outta 10. That's not the case. People typically choose NoSQL for the wrong reason. That reason being that it is intuitive to use by comparison to our DBSs. And that will bite you in the butt down the future. It will, it will bite you. It has bitten me many times on past projects I've worked on that have NoSQL databases, which turned out, wished they had been on RD BMSs, but it was too late and moving over would be too difficult. So nine times outta 10, pick an R-D-B-M-S. Those one times outta 10, where you definitely know you need a NoSQL database. Of course, pick a NoSQL database. And so that really leaves us to the two main open source database contenders being my SQL and Postgres. And I'm not gonna get too much into the hairy details here, but I'm just gonna say I prefer Postgres. Postgres to me, is more powerful and has a stronger zeitgeist in the modern open source development crowd. I, I, I really think it is. It's becoming more popular over time in the open source community because of the, just the features. It has, it's just so feature rich. There's so much more you can do with Postgres than you realize, and I learn new things every single day. One thing, for example, is that you can actually effectively replace having a job queue by just using Postgres. In other words, you can use Postgres as your database, uh, that your server communicates with. You can also use a table in that Postgres database that effectively acts as your job queue server, and therefore you don't need RabbitMQ or celery or SQS or any of these technologies. There is a tool. In Postgres that allows you to lock a read and update operation so that if one server is reading that row in that job table, it will be invisible to other servers which may be trying to read rows from that table as well. And then, uh, server a can mark a job as complete when it has finished and so on. I won't describe how this technically works. It's actually on my blog on oc develop.com. You can find. Uh, how to actually do this if you're interested in it. And another thing that Postgres can very nicely replace is high performance, real time shallow data, which is typically achieved by way of Redis. Redis is a very popular tool for session management across your servers and real time. Pub sub, what's called pub sub is publish and subscribe. So that one server is subscribing to notifications from the Redis server. So let's say you have a chat room, Redis would be a very popular tool for use in a chat room where a server is subscribed to the Redis server. Your app server subscribed to the Reds server. And if a user sends a message, sends a chat that is published to Redis and any of the app servers that are subscribed to Redis will then get that push notification and then they can send it down the wire to the client. So Redis is great for session management for stuff that needs to stay in memory over the lifecycle. Of a server which may come online or offline, or scale up and down, or there may be multiple, uh, versions of the same server in a horizontally scaled stack. Redis is great for maintaining data that needs to be present in memory for all those servers to be able to access. It's great for real time communication between servers, but one benefit that Postgres offers over my SQL and other RDBMSs is it has this functionality built in as well. So Postgres is a fantastic solution for your R-D-B-M-S. You can actually get away with replacing a lot of components of a tech stack by just using Postgres features. And then eventually, let's say down the line, you really need a dedicated pub sub and session management tool. Then you switch. That part to Redis. Okay? And I also really need a dedicated job queue. So you switch that part out of Postgres to RabbitMQ and so on. So I recommend Postgres for your RG BMS. So what we have here is we have your client is on React and React native. That's your browser and your mobile apps, your server, let's just say you're either gonna choose Node, if you wanna stick to the JavaScript and popularity ecosystem, and you're gonna choose Fast, API If you wanna stick to the Python ecosystem. And then for your database, use Postgres. And then some of these, like I said, these, these more auxiliary utilities for session management and in memory data management, you might want to use Redis. And then for your job queue, you might want to use Rabbit. Mq, but you can get away with a lot of this stuff by just using Postgres. So all you have is Postgres fast, API, and React. Okay. Now what about the machine learning server? Well, I'm actually gonna, this episode's getting long, so I'm gonna punt that till the next episode. The machine learning server will probably exist on GCP or AWS, either on AWS batch, if your machine learning jobs. Don't need to be constantly accessible. Batch is great for fire and forget jobs. Some maybe you need to run a a machine learning job once a day or twice a day, or three times a day. You'd use AWS batch. If you wanted your machine learning model to constantly be available, you might run it on SageMaker. SageMaker allows you to run your model on a rest endpoint so you can send it data and it will send you predictions. Any number of competing platforms like, uh, Paperspace Gradient and cortex.dev. Um, like I said, I'm gonna save these conversations for the next episode and we'll, we'll just talk about your app stack here. Now I'm gonna do something you're not gonna like, because I put in all this effort into describing a manually programmed. Tech stack the traditional way. I would say the last, um, 10 years people have been do going this route. Prior to that, people went the, the all in one monolithic route, which would've been Django and Ruby on Rails, Django and Ruby on Rails is full server, full database, full client, all in one package. Then we moved into non monolithic stacks. We call this microservices or services architecture or something where each component is separately handled. That's what I discussed in this episode. You have your React front end, your Fast, API backend, and your Postgres database. Well, we're moving into a new era. What's called serverless, and I recommend serverless. I recommend you scrap everything I just said about your fast API backend and your Postgres database and go serverless. And what is serverless? Serverless architectures, um, as provided by various companies. There are serverless frameworks provided by Google, by AWS and by third party. Providers. What they do is they abstract away from you the server itself. Now, traditionally what you do is you write your code in fast, API or node js. Ideally, what you'll do is you'll write it in a darker container. From the last episode. That way your packaged up code and environment, be it Ubuntu or Debian or whatever is all in one and it's, it's reusable in various locations. So you write your fast API server code, you wrap the whole thing in a Docker container by way of a docker file, and then you send that up to EC2. Specifically E-C-S-A-W-S-E-C-S Elastic Container Services, that allows you to deploy that project. Now on EC2 using this ECS tool set, it'll allow you to spin up a Docker container on their EC2 instances and run this in the cloud, and it will work exactly as it worked on your local dev environment. Now, what's the problem with that? There are various problems. One is gonna be scalability. Now, if you weren't using ECS. You would be manually deploying this to EC2, which is just manual server management on AWS. If you weren't using ECS, you'd be handling this manually. Scaling is just gonna be an absolute nightmare. You have to manually handle your own scaling architecture, and that was one of the big benefits that ECS provides is that it handles auto scaling of your docker containers for you, but even then, sort of. ECS handles the auto scaling of the architecture of, of spinning up and down server instances themselves. But is your code capable of this type of horizontal scaling? Is your fast API code smart enough to be able to handle multiple. Duplications of itself horizontally across multiple servers. Maybe, maybe not. It depends on how effectively the framework itself handles that for you and how smartly you did your end of the bargain as a programmer using that framework. So that's the scalability concern. Another concern is authentication. This is a huge, huge issue. Authentication, user, user account management. If you want to add users. To your app, what you have to do is you, you build in all these authentication routes on your fast API backend, and then these routes then marshal, you know, user registrations to the database and then pull users outta the database and send it to the client and so on. You have to be extremely security conscious. You have to hash your user's passwords. You need your server to be ultra hardened so that your database can never get hacked, and you likely need to have a rotating secret key on your server for, for this hashing process because if you are server secret key, ever got exposed, hackers would presumably. Be able to access your database or be able to access various components of your server that you definitely do not want exposed. So managing your own dedicated fast API server means you need to manage your own security, and there is so much more to security than you could. Ever imagine, unless you're a security expert. And, and then a final aspect of security is when you have these various services in your architecture. So we have the front end, the database, and the the app server separated rather than all managed in a monolithic server framework like Ruby on Rails. Or Jango, which would handle the cookie management of client authentication to the server for you. Well, in order to perform authentication with separate domain client and server, uh, you need to use something called Jot jw. T and the jot is basically what allows your client to authenticate to your server to maintain an authentication so that a user can communicate with their own user account on the server. Where do you store that? Jot on the client. You don't store it in local storage. That's the wrong way to do it. You store it in an HTTP only cookie. Oh my gosh. There's like all this stuff. There's, there's so much stuff. That you did not realize you were getting yourself into when you decided you were gonna make an app, a customer facing project. So that's where serverless comes in. Serverless architectures are frameworks provided by AWS and Google and others. So the AWS serverless architecture is called Amplify. Amplify and the popular GCP or Google Cloud platform, serverless architecture is called Firebase, but let's go with Amplify. What happens is you create your front end on React and React Native, and Amplify has a React plugin and you go on to AWS and you set up your Amplify environment and. It gives you a public key and you pop that public key into your React front end, and then what Amplify does for you is it provides user authentication out of the box so that users can register, sign in, activate their accounts from an activation email, and do a forgot password and get a one-time email with all that stuff. That's stuff you'd normally have to build yourself if you're gonna write your own fast. API server. And Amplify and Firebase provide interaction with the database directly by way of the client. So you wire up your components in React such that they hook into tables that marshal data to and from a database managed by these serverless architectures directly from the client. In other words, by using a serverless architecture, you can get away with. Not having a server whatsoever you, you literally do everything from your React client. That being said, this sort of setup assumes that you're gonna be using the most common types of rest requests scenarios, the most common types of table structure setups. More likely than not, you'll probably have some custom code, uh, that you want to run. It's very rare that you can get away with an entirely server free architecture using client only code by way of firebase or amplify. So what you usually do. Is you start with your client, you build, amplify or firebase into your client, um, for all the basic necessities. And as soon as you feel the need for custom code, then you kick off to another component of the serverless architecture. On the AWS side, this is called Lambda. And on the GCP side, this is called cloud functions, and going with AWS again, Lambda allows you to write. A single Python function or a single node js function, you'll write a single Python function and deploy that to Lambda for some specific Edge case server scenario. Some specific custom code that you need where Amplify is not enough. You write your Python code, deploy it to Lambda, and now Lambda exposes. A rest endpoint that you can call directly from your React client. And when you call that rest endpoint, only that one Python function is called and then the response is sent back to you Now. Two things happen here. One is you don't have this entire server code base for everything under the sun, including authentication and just almost these unnecessary boilerplate routes. Most of that is handled for you by AWS Amplify, but it allows you to have the flexibility for custom code as the case may present itself. So for your custom code, you deploy single functions to the Lambda backend. But one thing Lambda does for you that is more difficult to achieve by way of the traditional docker on ECS slash EC two setup is that Lambda will scale that one function for you as needed. So if your app becomes super popular and you end up getting a million people hitting it. Just all the time, and they're hitting that Lambda function. Well, if you were to try to scale, scale your ECS cluster, there's a lot you'd have to keep in mind, both AWS side, architecture side, and code side. Lambda just does that all automatically for you. It knows when it needs to scale, and it knows when it doesn't need to scale or when it needs to scale down. Furthermore, as long as that lambda function is not being called, you are not being charged. Let that sink in. That's one big issue with running a server, a dedicated server on ECS or EC2, is that you'll constantly be charged simply for the server. Existing Lambda does not charge you for. The server function calls, unless they are being called, you're charged by the amount of compute seconds where these server routes are being called and and computing stuff. So we have amplify. Which is an AWS product for, uh, setting up client only sort of stacks, like it includes a server and includes a database, but all that stuff is managed for you automatically by AWS. And then if you want some custom code, uh, you, you write Lambda functions and the Google equivalent to this stack G uh, GCPS equivalent is firebase instead of amplify. Firebase is the all in one solution where all you need is a client. And then if you do want server code, custom server routes, uh, you use what's called Google Cloud functions. And by the way, amplify uses various serverless AWS offerings under the hood. So it is sort of an all-in-one package, but the components within Amplify are, are all. AWS serverless components. So for example, if you did not want to use the all-in-one Amplify package, but you just wanted the serverless authentication, user authentication, registration, forgot password, all that stuff, so you didn't have to worry about security on your server, you could use AWS Kognito, C-O-G-N-I-T-O. That is the authentication component, the serverless authentication component used by the Amplify Stack under the hood, specifically for serverless authentication. I. This episode got really long and I haven't even yet talked about your machine learning job server, which nature of this podcast is probably the thing you're the most interested in. I'll talk about that in the next episode. There are serverless machine learning deployment solutions Right off the bat, the most popular and well-known one is called SageMaker on AWS and a very powerful up and coming open source. One is called. Cortex and another popular one is Paperspace Gradient, but I'll talk about those projects in the next episode. But let's, but let's recap what we talked about in this episode. You're gonna create a customer facing product. It's gonna have various components to it. It's gonna have your machine learning part, that will be your machine learning server. Next episode, it's gonna have your app server or your just server. Server, your main server. It's gonna have a database and a client. Now, on the client side, I recommend using React and React Native React for the web client, react native for the native mobile apps on the server side, I recommend you use Serverless frameworks either by AWS. Or GCP or competitors. The AWS Serverless framework all in one package is called Amplify. But if you Google Amplify and look at the various serverless components it's using under the hood, you can use those specific components yourself. For example, Kognito for the user authentication component and Lambda for specific rest routes that you might wanna write, custom server code for Now, if you find that you really do want custom code, maybe your old hat and traditional, or your app is just more custom than what the serverless architectures provide, then use a web framework like Fast API or express JS on node js. If you want a database, which you'll almost certainly need if you're gonna be writing your own custom server on Fast, API, for example, I recommend using Postgres. Postgres is my personal favorite, R-D-B-M-S. You can host Postgres on AWS through a service called. RDS. By the way, a case could be made that RDS is the serverless hosting solution for your database because you're not managing the scaling up and down and the backups and such of your hosted database. But I think that might be a little bit of a stretch. A hosted database is just a hosted database, and these have been around forever. But if you need to store custom tables and data outside of the usual purview of traditional app architectures, then you would set up your own database. Use Postgres on RDS, otherwise, see how far you can get away with using Just Amplify or Firebase and the types of tables and data set up they provide for you outta the box. React for your front end. See how far you can get away with using serverless frameworks and for anything else that slips through the cracks, host your own server code first on Lambda. See how far you can get away with there and only as a last resort on ECS hosted. Custom fast API code or no JS code. This will save you security heartache. It will save you scalability, heartache, and so much more that you just don't think of until it comes up, and then it's too late.