Complete Backend Software Engineer Mind Map - Everything You Need to Know (2 HOURS!)

Everything you need to be aware of as a backend engineer is going to be talked about in this video. I put together this insane mind map, which is going to talk about every major technology and show you where it fits in in the bigger context.

Now, if you want to become a backend engineer or strengthen your backend engineering skills, you don't have to know every single technology in this mind map. This is about helping you think and speak intelligently about different technologies and helping you understand how everything is connected.

If you want to take this information and turn it into a step-by-step road map, I'm going to do that in a follow-up video, so stay tuned for that. And we're going to go through this. If you want to follow along, I have a link to this down below. This will help you get the most up-to-date version if I do end up adding or changing anything in this list. You can also print it if you want to use it as some kind of reference.

So, to start, we're going to go into the backend frameworks, and there are a bunch of different languages here. The main takeaway from this is that you can program a backend in pretty much any major programming language. Certain ones are going to be more popular for web development, and I would generally recommend to pick something that has a decent level of popularity because this will basically show that enough people have gone through it and issues have been resolved, and you're not working with some super cutting-edge technology that doesn't have a lot of development over time or resources for support. And that's going to be something that you can apply for pretty much any technology. I generally like to recommend people get newer technology that's not super dated, but not so new that you're working in basically a beta software where you have to worry about breaking changes or running into issues that nobody else has faced before.

So, we'll go through each one of these, but it's important to understand that you first have the programming language. So, for example, we have Python, and within Python, you will also pick a framework. So, a framework is basically just a more extensive library that someone or some team created to help you build applications that way you don't have to build everything completely from scratch. So, in the example of Python, three popular ones are Django, Flask, and FastAPI. There's probably like a million others. The goal isn't to know all of the frameworks. The main thing is to know the most popular frameworks for each major language. And when it comes to choosing a framework, it's often the case you'll want to pick one that makes sense based off of what your team is using if you're working in an existing company or software. So, if you're given an application written in Django, then yeah, use Django. But if you're starting with a brand new project, you can think of the targeting of that particular framework. Often, it's the case a framework will target simple, small applications or building large enterprise applications, and it makes sense to pick the one based off of what you're trying to build. So, in this case, Flask will give you a really simple start. You can get an application going in a single Python file, whereas Django is going to give you a little bit more structure, and the setup is more complex, but it might be the framework for you if you eventually are going to have a more complex backend. Then it's probably the case there will exist frameworks that will target a particular feature or capability. So, with FastAPI, it's all about creating very performant APIs, so that might be something for you as well.

And if you're watching this thinking, "Wow, there's so much stuff here, where do I even start?" It's often the case that you can achieve the results you want with many different languages or frameworks. You don't have to choose exactly the right one. So, I recommend following some learning path and sticking to that so you can become familiar with all of these different technology categories. So, at the bottom of the road map, I have an example learning road map, and you can follow through with that, or you can wait for my upcoming video, which will go through that material.

Now, if you need a little bit more support, I do offer one-on-one mentorship, and this is if you want me to meet you where you are in terms of skill and help you bring you to the point of being a professional backend engineer. So, I have a link for that application down below in addition to the road map. So, check out those two resources, and if you do end up applying for the mentorship, I look forward to working with you.

But let's get back to working on the backend frameworks. Let's just go through each one of these in no particular order, but I'll grab some of the more popular ones first. So, we have JavaScript. There are a lot of different options here. One of the biggest ones is Express.js. This will give you a really easy way of building a backend API. Next up, we have NestJS, which is going to achieve similar results, but it gives you that larger framework. So, you could kind of compare this to Python's Django and Flask. Express.js gives you the simplicity, ease of starting, like you would get with Flask, and then NestJS is going to give you everything you would possibly need, kind of like Django. And when you have larger systems like that, it often comes with different conventions or opinionated approaches to developing software. For some people, that's great. It gives you exactly how to do things, but for others, you might want a little bit more freedom and not to have to kind of fit into a strict system. So, in that case, you might want to go with something like Express instead of NestJS.

Then we have Fastify, which boasts faster speeds and a better development experience. That's ultimately going to be up to your judgment, but that's another option as well. Then on here, we have two other ones, Nuxt.js and Next.js. These two are kind of interesting because these are often used to create full-stack applications and they just have a backend component to it. So, these are kind of different technologies than Express, Next.js, and Fastify, but I wanted to put them in here because they're going to give you a JavaScript backend.

So, let's take a look at Next.js first. Next.js is going to be pretty similar. Next.js is going to utilize React components, and it's going to give you the framework for building a full-stack application, so both front-end and backend. With this, you're going to get things like static site generation. Overall, it's a really cool technology and has grown a ton in popularity. So, if you're building a new application, it's definitely worth considering, especially if you want to work within JavaScript and you're already using React, then it would just make sense to check out Next.js and see if it's right for you. Nuxt.js is very similar, but it's utilizing the Vue JavaScript framework. Vue is similar to React, a front-end framework, but it's a little bit different. So, if you're working within a Vue environment, you might want to check out Nuxt.js.

Next up, we have C#. The major framework with this is .NET Core. You may also hear .NET MVC. This is a great option, but it's within C#, which is largely tied to the Microsoft environment. So, in this context, there's a good chance you'll be working with Microsoft SQL Server, Microsoft Azure. If you're in a Microsoft shop, then yeah, it makes sense to use C#. Otherwise, there's a lot of other options on here that aren't coupled to a particular system. Now, that doesn't mean if you use C#, you have to use Windows or you have to use SQL Server or any of these other Microsoft products, but it's developed by Microsoft, so that's where you might get the best experience. C# is great for various things, and overall, it's really great. You'll probably get a very similar experience with Java and Spring Boot. Java being the main programming language in the Oracle ecosystem.

Now, if you're going for Spring Boot within Java, there's also Kotlin, which is often positioned as a potential replacement for Java. And Kotlin also has a Spring Boot framework, as well as this Ktor framework. I'm actually not sure how to pronounce that, so I don't want to assume. I haven't personally worked with that, but it's probably a good option if you're working within Kotlin.

PHP is very huge for the web. It powers things like WordPress. You can use it for custom backends with CodeIgniter or Laravel. Haven't personally used PHP in this context, but I know it's very popular. It wouldn't be my personal first choice, but there's not anything necessarily wrong with it. I would just probably choose JavaScript or Python.

Or I've actually worked with Rust professionally, and I use the Actix framework. So, the interesting thing about Rust, while it is newer and might not have the established history that you might get with some of these other options, it is a really good ecosystem and gives you the power of a programming language like C++, but has a better ecosystem for things like API development. So, you wouldn't typically build an API with something like C++, but with Rust, you can easily do that. Actix is another popular one, but within every language, there's like a hundred frameworks, so I'm just putting a few of the most important ones. So, I had a pretty good experience developing in Rust. Definitely did have that feeling of like, "Wow, this is newer, not nearly enough support or people who've solved this particular issue yet." But if you're already working within a Rust environment, maybe you're using Rust for some lower-level programming and you want to build an API, then this is awesome. So, I definitely see Rust being a much more popular option going forward, as well as languages like Go, which you can see as a lower-level language, but often more used in the context of web apps and microservices. So, Go is a great option if you're already in that kind of environment. Here are two frameworks with Go.

Next up, let's talk about Elixir. We have Phoenix. And then Ruby, we have Ruby on Rails. All of these would be great options, just depends on which language you end up going with. Elixir is a functional programming language. The people that use Elixir seem to love it. It's not super popular, and also probably wouldn't be my first choice as a language to use for building a backend. I did use it for one particular job, and it was kind of a rough experience learning it, as it's not super similar to some of the other languages and frameworks I've used. While a lot of the principles of how to design the app were the same, I just felt the learning curve to go to a functional language like Elixir was a little bit high. But if you're starting from scratch and for some reason you want to use Elixir, go for it. Just keep in mind if it's something where other developers might end up having to work on it, not nearly as many people work with languages like Elixir, Rust, Kotlin, and Swift, which I really wouldn't recommend for a backend language. I think it's too tightly coupled to the Apple ecosystem. You may use Swift for building the actual iPhone application, but when it comes to the backend, I probably wouldn't choose Swift unless I knew it was only going to be used in that specific iPhone app environment and I didn't need to use it for anything else. But if I was just building a backend for a general web app, I would not choose Swift personally. Similar idea with Kotlin, which I think is probably a little bit more open and a good choice than using Swift, but Kotlin is often used for Android app development. So, you might end up using Kotlin for the Android app, but then choose a different language for the backend. If you're already developing in Kotlin, then you could potentially create some stuff in Kotlin for the backend, but if you were just trying to create a general backend and you needed to choose one of these programming languages, I probably would choose something that more people have used, such as JavaScript or Python.

I generally do concern myself about the popularity of the language and the framework. It's not the only thing I use to make a decision on which one of these to use, but it definitely is a factor. A great way to get an idea on popularity is using surveys such as the Stack Overflow survey. So, here are some popular technologies: JavaScript being the top of the list here, then we have Python, TypeScript, which is basically JavaScript, Java, C#, PHP. So, if you're working with some language or some framework that's down here, yeah, there might just not be very much support, which is one of the big reasons I'm a little bit hesitant about Elixir. The learning curve is steep, and not a lot of people use Elixir. And I only listed some of the major programming languages. There's probably web development frameworks for a lot of these other languages that we didn't even talk about, but this will give you a pretty good starting point. And if you are familiar with all of these, you should be good to go because you'll understand how other languages and frameworks fit into this larger mind map.

Now, I have a small comment up here that says, "Worth mentioning WebAssembly." I couldn't figure out where to put this, so I was like, "Here looks great." WebAssembly is a technology basically allowing you to use any of the major backend programming languages to do certain things on the front end. So, if you're familiar with development, you probably know that JavaScript is the main programming language for front-end development. So, if it comes to just learning as few languages as possible, you can pick JavaScript because you can do the front end and the backend, and you don't have to learn a different programming language for the backend. However, this could be changing with the adoption of WebAssembly, as it is allowing us to use other programming languages for things on the front end. I think this should have a capital W here, but, you know, everything has different upper cases and lower cases. So, but WebAssembly is a target. So, if you imagine taking a compiled language such as Rust, and instead of compiling that to run on an x86 machine, you could compile it to run on WebAssembly, which is supported in a browser. So, the browser is acting as an interpreter for WebAssembly, allowing us to use these other languages for front-end work. So, it's likely the case you're still going to have JavaScript. It's more so that for certain things, you could use these backend languages for front-end and things, especially if it's very performance-heavy. If you're trying to make a video editor or a maps application or something that requires a lot of computation and you want to run that within a browser, WebAssembly might come up to make that more performant. It's not a different language, it's just a technology that'll utilize these languages you're already familiar with. It's just going to help you have more functionality from these languages. This does kind of get into the front end, but this is likely something you'll want to be aware of as a backend engineer.

Next up on this list, I have ORMs and database libraries. Now, I didn't go through every ORM and library that exists. There's just unlimited. For every major programming language, there's going to be libraries for working with databases. Now, these could be libraries to work with one particular database, or it could be an ORM, which will work with multiple databases. So, let's take a look at this list to give you an idea of some of the most popular ones here. Now, I listed out ORM and I'll explain what that means here in a second, but you may also find libraries to work with a particular database. So, if you were working with PostgreSQL in a certain language, there might be a library to do that for you to make that connection easier, to retrieve data, edit data, and all of that. So, for example, within Python, you might work with psycopg if you wanted to work with PostgreSQL.

The first four on this list are examples of ORMs, which we'll talk about here in a moment. Then we have a database library, sqlx. Let's talk about this one first. So, this is an example that I used with Rust, and this is a database library that will allow you to execute SQL or SQL to different databases. So, it's not a library to work with one particular database. It will allow you to work with multiple databases, but it's not exactly an ORM. So, the difference between this kind of library that can work with multiple databases but is not an ORM, and then these kinds of libraries which are ORMs, is that these are object-relational mappers. They will execute the SQL for you, bring them into objects in your code, and then the way you interact with those objects would be methods and properties on those objects.

So, I didn't want to get into all the details and split out the types of database libraries into different branches, as I didn't really feel it to be necessary. The main thing you need to understand is that you can basically do one of three different things. You can use a library to work with a specific database directly. So, an example would be psycopg2 with Python to work with the PostgreSQL database. You may also hear of this as an adapter, basically a tool to connect your code to the database.

Next up, you might have a library that somebody would write to work with multiple databases and give you some easy commands, but it's not an ORM. The main difference here is it doesn't abstract away the SQL itself. You are the one who will still write out the SQL language, and we're going to get into databases here in a moment, but you're going to basically write that SQL, and then the library will take care of actually executing that on the database and retrieving that data, bringing it into memory for your application. You might then have to do some manual mapping, taking the results of those queries and putting those into objects in your code.

Finally, we have ORMs, which is the highest level of abstraction. This is basically when you will write something like `users.get_all()`. You're not using the SQL language, but you're actually using whatever programming language you're working with. So, if you're working within the context of a Python application, you might make your query in Python using Python syntax, and that ORM will translate that to SQL for you, retrieving the data from the database and then bringing that into your code as objects.

The ORMs have the highest level of abstraction, and it is often the way to easily get started working with databases, but they do have some downsides. They often do not have as much control because the library authors give you a specific set of functions you can use. You're limited to those functions. They may give you an option to execute raw SQL, but that just depends on the library. This is usually fine for most applications. So, when people get started working with an ORM, it is often an easy way to build out applications without having to get super deep into all the database stuff. As you get more specialized queries, you might not find the specific function you need, or behind the scenes, that function might not be executing the most optimized query where the ORM could be doing something fancy in code that you wouldn't expect if you just executed that SQL directly on a database.

This section of the mind map is really just designed to give you an introduction to database libraries because I wanted to mention the potential concerns around ORMs so you can do some additional research on ORMs when you start to build out a project. You can decide if it's something you want to use. It is a great way to get started, but I highly encourage that everybody picks up SQL and has an understanding of the database at the database level, and not just from within your application. So, one of the sections we're going to get to will be databases, and that's an extensive list of the most popular databases. So, we'll get to that in a moment, but for now, just be aware that within your application, you're going to need a way to connect to your database. That will either be just a small direct library or adapter to work with a particular database, or it will be a library for you to execute SQL, or it will be an even larger library or framework, which will be an ORM.

So, the first one on here we have is Entity Framework, and that is within the C# environment. So, if you're working with an .NET Core application, this can help you generate your tables and work with data. That's another cool thing about ORMs: they abstract away a lot of stuff, making it really easy to create tables and not have to worry about all the DDL, which you would have to worry about if you were creating the tables yourself.

Next up, we have Prisma. This is really popular in the JavaScript world. However, I have noticed that Prisma is growing beyond that to where you can use the Prisma syntax with other ORMs or libraries. So, definitely worth looking into. I used Prisma within a Node or JavaScript environment, and I was able to use it to work with a PostgreSQL database, but it also supported MongoDB, which is pretty uncommon for ORMs. So, the fact that it had some NoSQL support and I needed to do something with MongoDB, this was a really good choice for me.

Next up, we have SQLAlchemy and Django ORM. These are both within the Python world. I just wanted to list two from the same language to show you that it's not always the case that there's only one ORM as an option. Just like backend frameworks, there's often multiple ORMs you can choose from. So, you just got to weigh the options, looking at the pros and cons of each, maybe try one out, see if you like it, but you probably won't go wrong with any of the major ORMs.

All right, now I want to get into an interesting section, which is CMS, or Content Management System. And this is going a little bit away from core backend development, but is going to introduce a lot of interesting things that you should be aware of as a backend engineer. CMS is short for Content Management System. If you're not sure what that is, it's a system that helps you manage your content. So, you can think of basic examples such as WordPress. And one of the major benefits of a CMS is that people who are non-technical can use the CMS to create content and manage the website. So, this is going away from custom web apps and getting a little bit more into content creation, but this is still an extremely popular thing you might need to do as a backend developer.

Now, it's not often the case you're going to be working with these Content Management Systems as a backend developer. You might, for example, you might be working in PHP for these three, or C# with Umbraco. But another popular route is the Headless CMS. So, a headless CMS will give you just the backend, so the system for people to go in and create content and organize and manage that content, but it doesn't tightly couple that with a front end. So, within the backend career, you might want to be familiar with these different CMSs because say one of these CMSs delivers the content as an API, you might need to configure that or set it up in a certain way, or make sure the connection between that API and the front end is working. These are often coupled with a front end, and I put here SSG, which stands for Static Site Generation. So, it's often the case that these will be paired with one of these tools, which will be just the front end that will then make requests to your backend to retrieve the content to be displayed on the page.

If this all sounds like crazy jargon, don't worry. You don't have to know all of the information when it comes to CMSs. I just wanted to leave it in here as a section because you should at least be familiar with the idea. So, you can imagine, say you're familiar with WordPress. What if we had WordPress, but instead of automatically showing that in a WordPress front end, we just had a headless WordPress that delivered the content through an API? Then you could use one of these front-end tools to consume that API and display that information on a page. So, we're not going to get into the details of all of these different CMSs and static site generators. You can do additional research if you want. I'm actually not even sure the difference between all of these, but I just know that these are some of the most popular ones.

So, we're making pretty good progress in this, but we still have a lot of sections to go through. So, next up, we're going to take a look at, well, databases, since we just got done talking about ORMs. This will help us kind of tie that information together. Now, the key thing with databases is to not be overwhelmed with the number of databases out there. I've only listed some of the most popular databases, and I have a pretty big list here. There are a lot more, and it seems like every database has some specialty or some fancy marketing words, and it's sometimes challenging to understand what it is even for. So, my goal is to give you an idea of what each of the major databases is for and how it's different than the other databases.

That being said, the main way to categorize these is either SQL or NoSQL. SQL stands for Structured Query Language, and is a programming language, but it's more of a standard. So, all of the SQL databases will use the SQL language, but might have variations and things that are different between databases. Overall, though, if you learn one, you're going to be able to effectively work with all of them. Things might just be a little bit different in how that database works, or some of the data types, or things like that.

The NoSQL, and this is confusing, it doesn't mean that there's no structure. It means "Not Only Structured Query Language." So, some of the databases in the NoSQL category might still have the option to use structured data, but they might have other things as well. So, we'll get to that in a moment. Let's first take a look at the structured databases. We have all the major ones here that you should be familiar with. And just to get started from the beginning, we have two down here, Redshift and Snowflake, which are a little bit different than the rest up here. They're all structured in that they store things in tables, and that's the main thing that makes something a structured database. But these two are largely prioritizing analytics. So, if you have a lot of data and you want to run analytics on that data, you will use an analytical database. That's if the core features of these structured databases are not adequate, which usually it is, and you have some serious analytical needs, then you can look into an analytical database, or you might hear it as a data warehouse.

So, I didn't do it in this example, but if you wanted to, you could split this whole section up into two categories: OLAP, which is Online Analytical Processing, and then everything else being OLTP, Online Transactional Processing. A transaction being a purchase, an interaction that you need to record, creating a post, basically the creates, the updates, and the deletes, and obviously these databases are all going to be capable of reading data. But if your primary thing is just to read data and then calculate numbers off of that data, that's where you would go for the analytical types of databases. So, transactional, analytical. I'm hesitant to do too much splitting, though, because then it just becomes hard to organize. The main thing that these things have in common is that they're table-based. So, everything goes into tables with columns.

There is a whole world that you could explore if you start looking down the path of Redshift and Snowflake, which are two popular data warehouses. Redshift is part of AWS. We're going to talk a lot about AWS here soon. And then Snowflake is another option out there. There's probably a lot more of these analytical databases or data warehouses. But the thing that I was trying to get to is that if you start exploring data analytics and data warehouses, there is a whole realm of information, and this is going to get you into the world of big data, which is going to talk a lot about things like data streaming and Hadoop or Kafka. This is something I don't talk a whole lot about in this mind map. I do this on purpose because while you might explore some of that stuff as a backend developer, there is pretty much an entire different career path, or you could create an entire different mind map for the world of analytics. So, that's going to bring in things like data engineering, ETL, and even some analytics like predictive analytics. So, getting into machine learning and AI. It's a very interesting world, but I just felt it to be kind of out of scope of what I'm trying to accomplish in this mind map, which is really about focusing on backend services, databases, APIs, and how all of that stuff works together. You most certainly might encounter some of those things, so you should be aware that they exist, but you might not. So, you don't have to go and learn about data warehouses. I personally have never needed a data warehouse for anything, as all of the standard SQL databases for transactional processing can do a lot of the same stuff. It just might not be able to do it at a very large scale. But for the majority of use cases, probably most of the use cases I'm going to encounter and you're going to encounter will be fine just to use a transactional database. So, that's specifically if you really need to get into advanced analytics.

Let's now go through the main transactional databases. I will just go from top to bottom here. SQL Server. It's the Microsoft database, similar to C# and Microsoft Azure. It's just an offering from Microsoft competing with similar things from other providers. So, SQL Server is really good. It's been around for a while. I've used it for stuff, nothing to complain about. It's just very tightly coupled to Microsoft. Same idea with others on this list. So, Oracle Database. It's just the Oracle equivalent. Some database administrators probably freaking out that I just said that Oracle and SQL Server are basically the same thing. They're all databases storing structured data. As a developer, you're probably not going to notice a major difference switching between these two. As you get into the details, yeah, there's probably some really critical differences between them, but day-to-day, it's not going to impact us as developers unless you really get into more of like database administration, but most of that is out of scope as well. Plus, the SQL between these is going to be pretty similar. The differences with syntax and language will really come up if you start working with the procedural languages with databases. So, a lot of these databases are going to have their own procedural language you can use to do more custom stuff. So, if you need to do custom logic, you would use PL/SQL for an Oracle database. SQL PL is the SQL Server equivalent, and there's probably languages for all of these. It's not something you're going to probably do a whole lot, but it might come up, and those are just languages specific to that particular database. These languages may come up if you're working with stored procedures and you're not just doing standard SQL. So, there is a chance it will come up. I generally try to bring that logic into the application layer instead of leaving it in the database, but if you're in a company or an environment that's pretty database-heavy, there's a chance that they'll leave some of that logic at the database layer, and you'll just have to familiarize yourself with that procedural language for that database. That would be for things like database triggers or procedures where you need to do additional validation or whatever it may be, but you're not going to be using the procedural language for day-to-day SQL like creating rows or reading data, whatever you need to do for creating CRUD applications for creating, reading, updating, and deleting.

Next up, we have DB2. This is IBM's flagship database, and those are the three major enterprise databases. SQL Server is probably the most common of these three that is used by developers, but there is often times you'll be working in Oracle or DB2 if you are in an enterprise setting. But it's often the case that Oracle, DB2, these are pitched to large enterprises with some pretty intense data needs. SQL Server kind of fills the middle ground between small-scale developers and enterprise. And then we have the open-source databases, which usually will be the pick for first-time developers creating their own app. So, hopefully that gives you a general idea of where these databases fit. It's kind of a generalization, so it's probably not always the case, but if you just want to know what people think about certain databases, these guys are enterprise. SQL Server is kind of middle ground, developer-friendly, but can still be considered enterprise, coming from Microsoft. And MySQL and PostgreSQL, not enterprise. These are open source. The main thing you should know is that MySQL is owned by Oracle. The original MySQL team forked MySQL, creating MariaDB. So, this is kind of like a MySQL sticking to its roots, if that makes any sense. Basically, some concerns about MySQL now being owned by Oracle is that it's going to pull you into that Oracle ecosystem, trapping you for eternity. And some people don't really like that, which looking at this from Oracle's perspective, it's kind of funny if somebody can make a successful product just advertising that they're not in your ecosystem. So, that's something to consider when you're looking into these databases: do you want to be tightly coupled to a particular ecosystem? Doesn't mean you can't ever move, but things are just going to work better. For example, if you're SQL Server, if you're in Azure, working with C#, they kind of make an entire ecosystem, kind of like Apple and all of their products.

All right, I'm kind of ranting. You can tell I like databases. If you're not sure which database to go with, PostgreSQL is a great option because it's open source, it's free, and you can use it for free in a commercial setting. But my thought is, if you're just starting out and you're trying to pick a database, go with PostgreSQL, and if you need one of these other databases for some reason, you can switch over fairly easily because it's all based off of the SQL standard.

All right, last structured database on this list is SQLite. You may also hear people say SQL Lite. I've always said SQL Lite. You may also hear some variations in pronunciation with PostgreSQL, as the full word has a QL at the end, so you might hear PostgreSQL or variations of that. I just call it PostgreSQL. So, SQLite is a bit special because it's an embedded database, and what that means is it's delivered with the software. Now, for a backend developer, you probably won't use SQLite for the majority of the applications you build, and that's because you're building a system. You can imagine that system over here, and lots of clients connect to the server, so you have a single location, and that's going to host the database. SQLite would be a popular choice if you were delivering software to a bunch of clients, and they actually ran it locally. So, instead of having a centralized server, you actually distributed software, and that software needed a database to store some information locally. That's where SQLite would shine. You can use SQLite for centralized storage, but it's not the first choice. That being said, I have learned SQLite. I think it's a great option to learn and practice with. It's super easy to use and set up because it doesn't have a dedicated database management system. It's really just a file on your computer. It's super easy to start working with databases when you're working with SQLite. It's even included with some programming languages. So, for example, if you're working with Python and you want to store some data in a database, you can just use SQLite immediately without having to go install stuff and get things configured and set up. So, that's one of the main reasons I like SQLite, and it's also good to understand what people mean when they say an embedded database. It doesn't always mean embedded systems like people are talking about when they say they're an embedded engineer working on IoT devices or something like that. It can just be desktop software. I like to think of it more as the database is embedded with the software, and it's not at a remote destination acting as a server-client setup. So, I'm pretty sure that covers the core SQL databases. I'm sure there are more out there, but again, you know exactly how they're going to fit into this larger structure.

Next up, let's talk about NoSQL databases, and this one can be a little bit overwhelming because these don't all have core similarities like the structured databases. A lot of these are just competing products from different companies. In NoSQL databases, some of these are specialized databases for certain use cases that are different than some of the other NoSQL databases, and sometimes there are competitors. So, a little bit more complicated, but we're going to work our way through this list, getting a basic idea of each of these.

Now, just so it's clear, and I think I've made this point already, you do not have to get experience with each of these. I have not used most of the databases in this list. It's really about becoming good at a few of these and using certain ones for certain use cases. So, when you have some application and you know you might need to do X, Y, or Z, you can research which database might be the best for that.

So, let's first take a look at MongoDB here. Now, this is known as a document database, and what a document is is basically key-value pairs, pretty much like an object in JavaScript. So, this is going to be pretty similar to JSON, if you are familiar with that, which we'll get to notations here soon. It's a little bit different because it contains data types beyond just JSON. So, you can look up the BSON spec if you wish. But you can tell this is describing what looks like a person. It has their age and their status and groups. The main difference between a NoSQL database and an SQL database is that there can be differences between individual documents. So, the next person you put in this collection could have a name, an age, and then maybe favorite books or something totally different than this document. Comparing that to a structured database, you're going to define the columns, which will be general, not specific values. This is just what you will store in the table, and then every row in this table can only put those particular columns. So, that's the major difference. If you have variation in structure between documents, then it makes sense to consider a NoSQL database. MongoDB is one of the more common ones that developers start learning.

Now, I'll skip over IndexDB for just a sec and talk about DocumentDB, which is pretty much the same idea provided by Amazon. So, AWS DocumentDB. It's going to allow you to store documents. And what that means practically is that DocumentDB is a managed database. AWS hosts it, and you can access that database and pay for it as you use it. Compare that to MongoDB. While you can get cloud offerings, you're not required to. So, you can download MongoDB and you can run it locally. However, there are major MongoDB providers, such as MongoDB Atlas, which will host MongoDB for you. So, that's always an option as well.

Now, let's take a look at IndexDB. Not really sure why I put those between the two, but no big deal. IndexDB is a database in the browser, and this is really kind of cool because it allows you to store information that the user that is using your page might need to store to temporarily giving them a consistent experience between visits, but it's not something that's persisted to the backend. This gives you a database structure in the browser, and that might be more useful than just using something like local storage. Now, I generally wouldn't recommend this for any critical information because it's local to the client, meaning they could disconnect from the server, they're not going to be able to give that information to you, and because it's client-side, they can access that information as well. So, it's not something you would use for storing critical information or if you needed to make sure that information was persisted indefinitely. You would not want to use this because the client could never come back, or they could clear all of their browser stuff, and then they're not going to have that data any longer.

CouchDB offers some interesting similarities between IndexDB. Now, I wouldn't say these are a direct comparison, but one of the selling points of CouchDB that makes people use it is it will allow people to store data locally, and then if they later regain a connection to a server, they can then sync their local data with the server. So, if you need that offline experience, but you still want to store data in a centralized location, a server, then you might want to check out CouchDB.

Next up, we have Neo4j, and the best way to describe this besides saying that it's a graph database is to show you some of the examples from their website. So, here are some of the use cases, such as knowledge graphs, accessing deep dynamic context by connecting data. So, this really shows how data is related and can lead to some really cool visualizations if that's something you're interested in. You can see a basic example here showing how things are connected. Here's a visual I was able to find without actually going in there and creating a database. You can see that it shows the nodes and how they're connected, and it has like this cool liquid movement thing. But yeah, that's an interesting project you might want to check out.

Next up, we have DynamoDB. This is a serverless database provided by Amazon. The whole idea of something being serverless is not that it doesn't use a server behind the scenes, more so that you as the developer are not responsible for the server. It's kind of like a managed database, but it's completely managed where you don't even provision a server that someone else manages. You don't provision anything, you just pay for for the use of the database. So, it's a key-value NoSQL database, giving you single-digit millisecond performance at any scale. And that's obviously one of the selling points because it's serverless, you just pay for what you use. If you need to scale it up or scale it down. And the idea with serverless is no cold starts, version upgrades, maintenance windows, patching, and no downtime.

Bigtable is a product from Google and is the inspiration for Cassandra and HBase. So, this is different than some of the other databases out there because it specializes in wide data, and by wide, we mean lots of columns. So, if for some reason you have some data and you need to store thousands of columns about that data, you might want to look at something like Bigtable. This is a fully managed database from Google.

Cassandra took some of these principles and designed it to be a fault-tolerant database. So, this is something that will be replicated across multiple nodes and can support basically a distributed system using commodity hardware. So, you could have thousands of nodes, and they don't have to be expensive servers. So, you can read about some of the use cases or case studies with Cassandra. I think Apple at one point said they had 75,000 Cassandra nodes supporting 10 petabytes of data. So, this will basically enable a company to have a distributed system, making that possible with commodity hardware with a higher node count, comparing to paying for just a couple really expensive servers, for example. So, this is decentralized in tech, but it's not decentralized in ownership. So, these would all still be owned by Apple, which is just something interesting if you ever do research in like decentralized technology or blockchain. This is a little bit different where it's still all the same owner of the data. It's really just about decentralizing the data across a substantial number of nodes.

HBase is similar in idea to Bigtable and Cassandra, being a wide-column database. However, the difference here is that it's all within the Hadoop ecosystem. So, if you have no idea what that is, probably don't worry about it right now. But again, as I mentioned earlier about analytics, this is an entire environment around big data, and you might run into HBase if you're working within a Hadoop environment. Otherwise, I would look at some of the other options here.

Next up on this list, we have SurrealDB, which is a newer database that you may

Have seen people talking about online, or maybe it's something you will run into. But the target audience of SurrealDB is not entirely clear because it's kind of a database that does everything. So that's really their marketing. It's like the database that could replace a lot of other databases you might be using. So it's the ultimate multimodal database. They definitely have good marketing and branding, but it's probably up for you to decide if it's a great database or not.

With full graph database functionality, SurrealDB enables more advanced querying and analysis, which allows for multi-table, multi-depth document retrieval efficiently in the database without the use of complicated joins.

Next on this list, we have Redis, and this is definitely a good one to know. So be aware of it, but I would encourage you to try it out and become familiar with it because Redis is an in-memory cache. That's what it's primarily known for. Redis has a variety of other things it provides, provides, and can do, but the main thing Redis is known for is caching of data. So you can make your backends faster or use less computation by not having to retrieve or compute things that you've already computed. So, in-memory cache, very valuable for improving the speed of your applications.

Now, if you're using Redis purely as an in-memory cache, it's going to likely be used in addition to some other database. So you'll have some database that's powering your backend application. If you wanted to visualize it, you could then think of Redis as sitting between your backend application and the request from the client. So it will first ask Redis, "Hey, has this value been retrieved or calculated before?" If yes, we just give that value back to the user. But if it has not, then we'll go process whatever needs to be processed, retrieve new information from the database, and then give that to the client, caching it. So if anybody asks for it again, we can just get that cached file value.

Now, when we say "in-memory," that just means this is not persisted to disk. So if the Redis server is restarted, all of the data that has been cached will be reset. And this is generally fine. Resetting a cache or clearing a cache is a pretty typical thing you would need to do anyways. So it's not the end of the world if your cache is cleared. You're not storing anything in there that's critical that you couldn't lose.

Now, I did mention Redis can do a variety of things. So, for example, you can have it persist data. But when people think of Redis, they usually are talking about an in-memory cache.

Now, let's take a look at Memcached. This is another in-memory cache. So this could be seen as an alternative to Redis. While it's also pretty popular, it's not as popular as Redis. And if you were to choose a new caching system, you're probably going to go with Redis. But if you even go to get hosted Redis, for example, you might see Memcached as an alternative option. So there might be some specific scenarios where Memcached shines, and I don't want to say to never use that, but Redis is going to probably be your default choice.

Now, Elasticsearch. We're going to keep this real simple. It's a NoSQL database used for searching data. So if you have some complex data set and you want to be able to full-text search it, you could look into Elasticsearch.

Now, let's take a look at Firebase. And really, there is like a couple of different products within that. So there's Firebase Firestore, which is the default choice if you're going to go with Firebase. But you might also hear of the other option, which was Firebase Realtime Database, which is still an option to use. But pretty much in every scenario, you're going to go with Firebase Firestore.

So here is a quick comparison. And just scrolling through this, you can see that Firestore is preferred in every one of their scenarios. So they are pushing to use Firestore and to not use the Realtime Database. But without getting into the details of the differences between these two, let's first talk about what even is Cloud Firestore and when you might want to use it. It's another JSON-compatible document database.

Now, I'm going to explain one of the reasons why I believe Firebase has become so popular. While I'm sure there's lots of other features and capabilities, when there's millions of different databases, what is the reason Firebase has taken off? It's because it's very useful for what I would typically say are primarily frontend developers. Because the entire Firebase ecosystem is a good ecosystem to provide an entire backend. So when you use Firebase, not only do you get that database, but you also can get a backend layer, which can make it very easy to have a backend to connect your frontend application to. So you can almost think of Firebase as a Backend as a Service. You can just use Firebase for all of your backend setup, and you just worry about the frontend. I've seen a lot of content creators on YouTube basically using Firebase so that they can focus on the frontend material, not having to build out an entire backend from scratch. It's also extremely popular for mobile applications as well. So you'll often see Firebase being the backend for mobile app devs.

Now, one more important thing to know about Firebase is that it is a managed backend. So this is hosted on the cloud by Google. It's a Google product. So it's going to be something that you have to connect to the cloud. You don't download Firebase on your local computer. However, that's where Supabase can come in, and that is positioned as an alternative to Firebase that's open source. And the magic here is that you can get it hosted, or you can self-host it. So it's something that you could download, put on your own server, and use as you please. This means there are also multiple options out there when it comes to managed Supabase hosting. Most likely though, if you're looking for fully managed Supabase, you'd probably just go with the Supabase company themselves, who offers hosting or self-hosting it with any of the other major cloud providers without having the managed aspect.

Throughout this video, we've talked about hosting some, but we haven't really gotten into the details of the different types of hosting and what that looks like. That's what we're going to talk about next. Now, as always, when you're doing a video that covers a billion different technologies, it's kind of challenging not to overgeneralize or potentially not have everything 100% split up into the perfect categories because some of the things we're going to talk about will probably cross over into some of these other categories. So if you're a rep from one of these hosting providers and maybe you offer a little bit of everything here, totally understand that. And it's also something that you should understand as a developer. Often these services will provide a variety of different things, but what I try to do here is kind of categorize by what these companies are most known for.

So first, let's get the foundation. What is hosting? Basically, if you want to run a web server or some application and you don't want to run it from a computer in your house and have people connect to it over the internet, you can host that application. You pay money to a hosting provider, they run all the services, and then people can connect to it. There are three general categories I grouped these into. So we have the shared hosting companies, we have Platform as a Service, and then Infrastructure as a Service. We'll get to those two in a moment. Let's first talk about these shared hosting providers.

So when I sign up for shared hosting, I may run, say, a WordPress website, and there might be a lot of other people running WordPress websites from the same server, sharing resources. So you can think of your application as just one of many applications running on that server. All the resources are shared, and there's no real separation from the different websites. Now, while there's probably things set up to keep things secure between websites and make sure one website doesn't impact the others, that is a potential risk. So if you're paying for shared hosting and it's sharing resources with another website on that same machine, let's say something goes wrong with that other website and it starts to consume too many resources, or maybe there's a security issue, there's a chance that could impact your website. While it's ideal that that doesn't happen, or that you know there's some things in place by these hosting providers to make sure that doesn't happen, it's not something that would likely be guaranteed. And because of that, some people avoid shared hosting.

Not only does shared hosting limit your resources, but you're sharing the machine resources with other people. It's the cheapest option, and this will give you things like hosting for a few bucks a month or whatever it might be. The way the companies package the hosting changes. So on one website, you might pay per website, or you might just pay a certain amount and get unlimited shared hosting. So then you could set up as many websites as you want as long as you're a paying customer. The big ones on this list you might be familiar with: GoDaddy, DreamHost, Bluehost, SiteGround. These do all basically the same thing, and I don't really have a recommendation on which one to go with. I've personally used a lot of DreamHost, I've used Bluehost, and I've used GoDaddy. All have been pretty good. I've also used Hostinger. I hosted a Minecraft server from Hostinger at one point, that was pretty cool. 99% of the time, you're not going to be using shared hosting as a backend engineer. This is really if you just want to launch a simple website and you don't really want to do anything with custom backend coding. You might be able to do some WordPress plugins or something, but you're likely not going to be running a custom API from shared hosting. In fact, a lot of the shared hosting is only going to provide a very limited set of options when it comes to what language and version. So you might be able to use PHP and nothing else, or there might be a few different options, but most of the time it's going to be very limited.

So that's where the idea of a Virtual Private Server comes in, and often it's the case that you'll go from shared hosting and then upgrade to a VPS. This is where you get basically a dedicated server, but it's virtualized behind the scenes. They might be running multiple of these virtual private servers on a single server, so there's some limitations. However, it's pretty much a dedicated server from your perspective. So this is where you can basically have a Linux server, you can run whatever you want on it, and because of that, you can run custom APIs or anything that you need from that server. Now, when you're doing this, you're kind of in control to manage the inbound and outbound of this, and you're likely going to need some kind of web server. We'll talk about some of the most popular web servers here in a moment, but just letting you know that you're kind of in complete control of that environment.

Next up, we have dedicated servers, and this is pretty much what it sounds like. They host a server, and you pay for it monthly. You can do whatever you want with it. It's not virtualized, so you're not sharing resources with anybody else. You can research why you might want to go with a VPS versus a dedicated server. It often comes down just to what you need and costs. In this scenario, you're basically just paying for the infrastructure. So it's kind of Infrastructure as a Service, and we're going to talk about more Infrastructure as a Service in a moment. Whenever something says "as a service," it basically just means a subscription payment model. They're running the computers for you, and you're paying a monthly fee to use them. However, as a backend developer, I don't tend to think of these companies when I'm looking for my backend hosting solutions. Yes, you might run into that, but most likely you're going to look at one of the major cloud providers for infrastructure: so Amazon Web Services, Google Cloud Platform, Microsoft Azure. Those are the major three. There are a few others we'll look at, but those are going to give you a lot of more services, and you tend to really think about those when you say Infrastructure as a Service.

So we'll get into this next category here, which is PaaS. This is Platform as a Service, and here are some of the most common ones you're going to run into. As always, there are a ton out there, so this list is not comprehensive, but Vercel, Netlify are two really popular ones right now. And then we have a lot of these other ones from major companies, which will often help you deploy apps onto that particular cloud. So we'll talk about what that means in a sec. But for Vercel and Netlify, basically, you can think of them as abstracting away all the computer hardware, and they just give you a really good experience for deploying backend applications. And often you can do frontend stuff as well. So it's not just specific to backend, but that's what we're talking about in this video. So if you're looking for a place to deploy an API, you can do it on these platforms, and they're going to make the experience as easy as possible. That's really what you're paying for when you're paying for a platform.

So to explain the difference real quick between a platform and infrastructure as a service: platform makes the experience very easy. It's basically a wrapper around infrastructure. Whereas if you're paying for infrastructure, you're in charge of setting everything up yourself, which can be very painful. It is a valuable skill, but you don't get that nice one-click deploy experience. So Vercel, Netlify, to my knowledge, do not run any servers on their own. They are going to use the infrastructure companies, so AWS and other cloud providers, and they're just writing software to make it very easy to do that without you having to go into AWS and set up a bunch of stuff. Because of this, if you're doing cost comparisons, if you just look in general, Vercel is going to be more expensive than if you hosted on AWS directly. That might not be 100% true all the time, especially if one of these platforms are able to provide some special pricing, or you know, perhaps set up the infrastructure in a way that would save money compared to how you might set it up if you did it on your own, or they might just be reducing prices for customer acquisition. You can go to one of these platforms, do something cheaper than if you went to one of the cloud providers directly.

Heroku is another one that's pretty similar in concept to Vercel, Netlify. I guess I just didn't see it at first in this group because I had it prefixed with Salesforce. I wanted to put Salesforce there because I didn't even realize Heroku was owned by Salesforce until recently. So Heroku is another Platform as a Service that's going to help you deploy to some of the major cloud providers.

Now, let's take a look at this next one here, AWS Elastic Beanstalk. This is a Platform as a Service on AWS. So it's going to make the experience deploying to various AWS infrastructure a lot easier. So while AWS provides the infrastructure, they also provide a platform to deploy to it without you having to set up everything on your own. Similar idea with these other ones. So I'm not going to go through each individual one. Azure has something that's very similar for Microsoft Cloud, and then Google App Engine, same idea for Google Cloud. Then we have DigitalOcean App Platform. I think they host their own stuff, so they use their own infrastructure. Same idea with Oracle Cloud Platform with the Oracle Cloud.

So let's take a look now at the infrastructure platforms. These are the major ones. So we have Oracle Cloud Infrastructure, that's just the full name for Oracle Cloud. We have Amazon Web Services, Google Cloud Platform, Microsoft Azure, IBM Cloud, Alibaba Cloud, DigitalOcean, Aami or LOD, and there's a ton of other ones out there as well. Pretty much any companies that provide infrastructure or computing hardware, they're going to be in Infrastructure as a Service, which I mentioned briefly. But you know, some of these that offer dedicated servers could be considered infrastructure as well. I just grouped them separately because I tend to think of those more as easy hosting providers, and then I kind of think of this group here as companies where the main thing that they try to sell is infrastructure. So when you go to one of these websites, they don't advertise hosting a website for $3.99 a month or whatever. They're basically selling a variety of different services, all of those around infrastructure.

So far so good. We've made it through three major sections in this center section, and then we have these two floating over here on the sides. But let's go through the next one, which the logical next one is going to be clients and servers. Since we were just talking about hosting, what web server software is actually used? Well, if you're working with the infrastructure directly or you have a dedicated server, you're going to be responsible for choosing what web server you want to use. And the web server is what actually handles requests to that computer and makes it possible to run applications from that computer. The three major ones I'm familiar with are Nginx, Apache, and IIS. There's also Caddy on here, which I've heard a little bit about when I was just researching different web server software, but I haven't used or experienced that directly. And as always, there's other ones out there, I'm sure, but these are the big ones you might run into.

So let's just talk about IIS real quick. This is a web server that's really popular for ASP.NET and Microsoft applications. So if you're not doing that, then I would probably go with one of these two in the middle. I have used both of these a bit, but I've grown to kind of like Nginx. Really, it's just about getting them set up and then probably never touching them again because they work. You might have to do a little bit of stuff with, like, SSL certificates and maybe some configurations for routing or redirection, but overall, you're not going to be doing a whole lot at this level. Hopefully, it's just something that you can set up once and it works. This is where more differences show up between using infrastructure and using a platform. If you're using a Platform as a Service, there's a good chance they abstract away all the web server stuff for you, so you don't have to even think about setting up Nginx or Apache. It's just done. The difference is, if they just hand you a virtual machine or a dedicated server, you're going to have to learn how to set all that stuff up yourself.

Now let's talk about things from the other end, so the client that actually makes a request to the web server. So when I say "client" here, I'm specifically referring to the software that makes the request. So the browser, that's going to be the case majority of the time. People are going to make requests to your web application through HTTP or HTTPS, doing that through a browser. So I grouped these in three different categories, but if I expand these, it'll basically just be the major browsers you might be familiar with already. The first word over here is the engine that powers those web browsers, and then in parentheses is the JavaScript engine. Similar ideas, and you can do more research on the differences, but behind the scenes, these four here in this Blink V8 section have similarities because they share the same JavaScript engine. The engine is what actually makes it possible to execute JavaScript code within the browser, and you're probably going to get a more consistent experience between these four because they all use the same JavaScript engine.

Now, just to get sidetracked for a minute, if you're studying JavaScript and browsers and engines, you might hear the term runtime. V8 is not the runtime. You can think of the runtime as where the JavaScript code is executed. So you could say the runtime is the browser here. But if you use Node.js or backend JavaScript, the runtime is actually Node.js, and the engine is still V8. So we still have the same core JavaScript processing, it's just the location is changed from frontend in a browser to backend with Node.js. So just saying that to be careful not to say V8 runtime, it's the V8 engine, not to be too picky on words, but you might hear people say one or the other and just wanted to clarify what is correct.

Now, as for the words WebKit, Blink, and Gecko, you might hear these as the rendering engine. They are what take the HTML, CSS, and JavaScript and make it functional in the browser by providing different browser APIs and different things you can do with JavaScript. So it's a partnership between the JavaScript engine, which provides the language and the execution of the JavaScript, and the rendering engine, which provides the APIs and the DOM. So while this isn't really designed to be a tutorial on web browsers, it's just important to know that behind the scenes of these common web browsers, there are a lot of things going on. And the introduction of a web browser has changed a lot of things. As we go on, web browsers are becoming more powerful and more standardized and readily available on more and more systems. And what this can do is give us a standard environment that we can build upon so that we can create apps that run on any systems. This is kind of similar to how operating systems abstract away differences in hardware. One layer higher, browsers abstract away differences between computers. So you can create an application to work correctly in a browser, and we don't have to worry about whether it's being ran on Windows, Windows, Mac, or x86 or ARM-based systems. We just create it to work in JavaScript with these different JavaScript engines and rendering engines. You may also hear of this set of browsers as Chromium browsers, which is an open-source browser project that Chrome was built on. So that scratches the surface of web browsers. There is a ton more on how web browsers work. They're kind of magical. That does get more into the realm of frontend development, but certainly not a waste of time in terms of studying. As likely even as a backend engineer, your work is going to be tightly coupled to a browser environment, especially going forward as more and more apps are moving to browsers. The skills that you develop in browsers definitely will not be wasted.

Now let's talk about CDNs, which kind of sit between servers and browsers. So if you make a request from a browser to hit somebody's web server, you might go through a CDN, which stands for Content Delivery Network. Here are the most popular ones. You've probably heard of Cloudflare if you've worked in backend development at all. And then we have CloudFront, which is Amazon's CDN. Akamai CDN, Azure CDN, Alibaba CDN, Google Cloud Platform CDN. Seems like every major cloud provider has some CDN service. And even Cloudflare does offer some Infrastructure as a Service. We didn't talk about it specifically, but you can look up Cloudflare Workers. This is their serverless compute option, and then they also have R2, which is their storage. But let's not get back to infrastructure. Let's focus on CDNs here.

The CDN is a Content Delivery Network, and its purpose is to do two things. The first of those two things being edge distribution. So if you imagine a graph, and you have a bunch of different locations where the center might be your web server, the CDN is basically going to copy the pages that people request and distribute them to all of these different locations so that when somebody closer to one of these edge locations makes a request, they don't have to go all the way to the main server. They can just request it from an edge location. Now, in general, the internet is very fast. You can make a request to something on the other side of the world and get a response relatively quickly. But if you're building a service and you want to make sure the times for loading are as quickly as possible, the less distance the request has to travel, because you know there's actual networking for these requests, the faster the response to that request is going to be received back by the client. So this can drastically improve performance. So that's the first major thing.

And then the second major thing, which is included in this concept, is caching. So when someone makes a request, instead of having to recompute that information, they are just getting a cached version of that page, which is going to be a lot faster because there doesn't have to be any computation or requests to a database. Now, caching is a more challenging topic when it comes to backend engineering, and it's probably something I'd like to make a dedicated video on, like all the different layers of caching. But just as an example, you can have caching in the browser, you can have caching at the CDN level, you can have in-memory database caching with something like Redis. So there's a lot of different spots where information can be cached. If you're ever in a scenario where you make some change, but you're not seeing that change reflected, there's a good chance it's being cached. To fix that, you may have to clear some caches. So if you deploy a new change to your API, there's a good chance you'll need to go into Cloudflare or any of these other CDNs, clear the cache, so that the new pages and the new requests get sent to the edge nodes. And then you could also have questions about, do you cache the actual API responses, or do you just cache frontend pages? And these are all things that you can have control over. The main thing you need to understand is that any level of caching, you'll need to clear that cache if you need new changes to be propagated so that users get the latest data. So that's your basic intro to CDNs, definitely an important topic to be really familiar with as a backend engineer.

Now, another section that may be interesting to add in here that I did not put in here would be Internet Service Providers (ISPs). These are the people you pay for internet access. And I say that because ISPs are responsible for the routing between these different sections. So when you make a request from the browser to some server on the other side of the world, it's because of your ISP that that request is made possible. I didn't want to put that here right now though, because I didn't want to get too much into the physical networking because it is something you can kind of just abstract away from your mind. You just know that requests go through the magical internet black box. You don't really need to know all of those details as a backend engineer. But if you are working in a role that might be a little bit lower level, working at the network level, you may benefit from having a deeper understanding of how the actual internet networking works. I obviously decided to leave that out, but just wanted to give it a quick mention if it's something you wanted to spend more time studying. That wraps up the section on clients and servers.

Up next, we have communication, and this is a general category where I wanted to talk about some protocols as well as different notation, or basically the language or the way you decide how to write things that you communicate. You can imagine calling somebody in real life on a phone, and just because you have a means to communicate doesn't mean that you can communicate. You still have to have the same language. So if I'm speaking English, you're speaking another language, we're not going to be able to communicate. Translating that back to our example here, the phone would be the means of communication, but the actual language would be the notation, and that would basically just be the exact syntax we use in our code to communicate.

Let's first look at this section here. These are the main approaches to communicating. You don't necessarily have to have experience using all of these, but you should at least be familiar with these. Now, I say this with pretty much every section, there's probably a lot more in software engineering. There's pretty much unlimited information, so don't feel like you have to know everything, but you should at least be familiar with these main ones. So if somebody says, you know, webhooks, you know what that is. That's actually probably a good one to get experience with. But for example, someone says a SOAP API, you don't want to be like, "What? I already like took a shower today. Like, what are you talking about?" So we're going to give you the basics of what each one of these are, but you don't need to go and actually implement all of these. There's just a few you should really have experience in.

So let's first talk about REST APIs because that's going to be the most popular. This stands for Representational State Transfer, which basically is a way to transfer state or data through HTTP or HTTPS, which is one of the protocols we're going to talk about here in a moment. So the way you do this is you associate a particular verb. You can kind of think of it as the official term is HTTP methods, but you can get data, you can post data, you can delete data, put data, and there are a variety of other HTTP methods. This describes your intent when you make a request. So when you go to a website such as youtube.com, that is a GET request. You're requesting the HTML, JavaScript, CSS from the server. There's also scenarios where you post data, or you can think of it as create data, and this would be submitting a form. In that situation, you're giving information to the server, and you associate that with an HTTP method so the server understands how to interpret it. When you're building a REST API, you're going to make endpoints on the server side to accept different request types. So the user, the end client, could receive data with a GET request, or it could give us data with a POST request. This is often going to use JSON, which is the notation that's basically the syntax for transferring data back and forth, and this is probably something you're familiar with if you've done any backend development. So REST, it's a really good thing to know. You should probably prioritize that here first.

So let's talk about SOAP real quick. The only thing you really need to know is that this was the approach to building APIs before REST, and it used XML. So REST is the modern replacement, and you shouldn't be creating a SOAP API at any point. Now, that's a general statement. There might be scenarios where you need to build a SOAP API to interact with some legacy systems or something, but really, REST is going to be the modern default.

Now let's talk about the flip of this. So a REST API, the client makes a request. With a webhook, the server actually announces something. So this is really popular with integrations. So if you want to be notified when something happens, often times services will provide webhooks that you can hook up to so that you receive a notification when something happens. So that's pretty much the summary of webhooks, definitely important if you're building any kind of notification systems or interacting with other services out there on the internet.

Now let's talk about GraphQL. This will serve a similar purpose to something like a REST API, but the way it's done is different. The idea here is you can make a request to the server, let's say you were trying to retrieve some information, but you can adjust that request almost like a structured query language query, SQL, with it, instead of being called GraphQL. So the client can adjust that request and retrieve just the information it needs. The cool thing here is that on the backend, you just set up the GraphQL endpoint, you know, set up some rules or restrictions, but then the client has control and can request exactly what it needs. The control is put into the client's hand, relieving some effort on the backend. So pretty cool structure, especially if you do enjoy like the database feel of it, where you can select exactly what you need to retrieve from the backend. So definitely something worth looking into, and there's also a lot of services around GraphQL for generating the appropriate requests. So you can set this up in your application so that the clients can go in and adjust their requests with like a webpage, and it's not always in code. So pretty cool thing that you should probably at least know the basics of.

Next up, we have a couple things here that say RPC, which stands for Remote Procedure Call, which you can think of that idea as invoking a function on another computer. JSON-RPC is a very simple implementation of a communication protocol, but a major difference is that it's bidirectional. So REST is a one-way thing where the client makes a request and then the server responds, but the server is never going to initiate the communication. With JSON-RPC, you can have bidirectional communication where the server initiates some communication. This is handy for real-time communication because the server can say something as soon as it needs to, instead of waiting for a client to make a request.

gRPC is a very similar idea, and this is a protocol built by Google, and it's going to utilize Protocol Buffers, which is one of the other notations we're going to talk about. So Protocol Buffers are really useful for inter-service communication. So if you have microservices, or perhaps you are working with some lower-level languages and you want to integrate that with an API you built in another language, you might communicate between these apps using Protocol Buffers. So gRPC is a communication protocol that utilizes Protocol Buffers, and it's a bidirectional protocol. So the server can communicate to the client directly without waiting for a request.

WebRTC, Server-Sent Events, and WebSockets are all things for real-time app development. So you can look up all of the differences about these. I would say that WebRTC's specialty is with things like video. Server-Sent Events is when servers need to broadcast events. And then WebSockets are ideal if you want ongoing instant communication. So if you had a video game or instant messaging, that's probably where I would go with WebSockets. So when it comes to getting a grip on all of these, REST is the default for API. Learn that. When it comes to real-time stuff, learn WebSockets. When it comes to broadcasting announcements, webhooks. When it comes to inter-service communication, gRPC or REST. So that gives you a pretty good idea of these different comms protocols.

Now, I've said protocols, but really, you should probably consider these as means of communication or architectures for communication using protocols. So HTTP, HTTPS is a really good example of a protocol that REST uses to communicate over. So the protocol is actually more of the technical spec detailing how that communication actually happens, and all of the communication styles we just talked about are made possible thanks to the protocols. So perhaps this would be better just said as APIs or Communications, whereas the protocols, which we're going to talk about now, would be some of these here.

So HTTP, HTTPS, Hypertext Transfer Protocol and Hypertext Transfer Protocol Secure. These are probably the two most popular you're going to see, and these are built with methods: GET, POST, PUT, DELETE, PATCH, and others. TCP is a layer lower. So HTTP and HTTPS will use TCP. So this gets all into the different levels of networking, which you can do additional research on. You probably just need to understand the basics to be an effective backend developer, but obviously knowing more is not going to hurt. TCP is used to make network connections. Another one you'll probably hear is UDP, with the primary difference that UDP is not a reliable means of communication. You can think of it as one computer broadcasting a message, and then anybody who picks up that message takes the message, but if they don't get the message, the sender does not care. It's basically just broadcasting that information. So TCP is a connection-based protocol. UDP is connectionless. If you need to transfer data and you need to make sure it gets there without being destroyed, that's where TCP is going to come in. Now, as a developer building APIs, you don't actually usually have to worry about this, but if you start working with lower-level systems where there's some network communication, then you might have to be aware of messages being transferred via TCP or UDP.

Now, another thing I wanted to mention is that devices get IP addresses. You will see IPv4 addresses and IPv6, which is designed to ultimately replace IPv4. So if you see something like 192.0.0.1, that's an example of an IPv4 address. That's the loopback address, so that refers to your own computer. But there's a variety of other number combinations which are going to refer to individual devices. IPs are given to the entrance to your network, and then devices within that network can have IP addresses that are local to that network. Meaning my device on my network might have the same IP address as your device on your network, but because those IP addresses are just local to our individual networks, those are not a conflict by any means. However, we should both be given a public IP address from our internet service provider. These will need to be unique, but that public IP address is for my entire network and does not uniquely identify a single device. Due to there being a limited number of IPv4 addresses, IPv6 is being introduced and is slowly growing adoption, where you can now have many more different IP addresses. So that's IPv4 and IPv6.

Next up, another protocol you should be familiar with is SSH. This is used to remotely connect to another computer. Often it's used to connect to a server, and SSH stands for Secure Shell. And it's probably one of the first things you're going to get experience with when you start working with another server where you're not just working on your local environment for building test applications. If you have a dedicated server and you need to work on that server, you'll connect via SSH. You'll be within the terminal, so you'll probably want to be comfortable with a terminal-based editor if you need to edit any text files, for example. So we'll get into some of that as well, but that is a pretty important protocol to be familiar with. And when I talk about these protocols, you don't necessarily need to understand how they're implemented. You just need to understand what they are.

So SSH is to connect to another computer through the terminal. FTP, SFTP, Secure FTP, these are all things to transfer files between computers. Pretty common if you're working with shared hosting and you need to upload some photos or something. So you might have heard of FileZilla, that's a software that will use these protocols to allow you to transfer files between computers.

Now, the next section I have here is on email. This will come up if you're working with custom emails for a domain. So if I wanted to have info@calb.curry.com, you might run into these settings, or if you're trying to set up email on your phone, even, you'll probably run into these. SMTP is the protocol for sending email, and then IMAP and POP3 are for incoming email. The major difference is that typically with POP3, the emails will be downloaded and not kept on the server, whereas IMAP will have them downloaded so you can read them locally, but they're still up on the server.

Then we have down here messaging. Wanted to add this in here, especially if you're working with something like RabbitMQ. Messaging software can be used to facilitate communication between microservices. So you don't always have to utilize just these things here. Software exists to help facilitate communication between smaller services, and these are the protocols that might be used behind the scenes. I think the major difference is this one being for more complex data, MQTT for simple data, and STOMP for simple text-based data. So those are something you might at least want to be familiar of those words, and you can research them more if you are in a situation where you might need to use them. Now, again, and these are the protocols. So you're probably not going to be writing MQTT stuff. You're going to be utilizing something that uses these protocols.

So at this point, we have a pretty good understanding of different protocols you might hear about, as well as the different paradigms of communication. Now let's talk about the notation, which is when you receive a message, how do you actually parse the text to know what it says. So these are the main ones you're going to run into. Most popular is probably JSON for APIs. XML is still a thing, but that was mainly used with SOAP APIs, so you probably aren't going to be using that a whole lot. For this, we talked a little bit about Protocol Buffers already when we mentioned gRPC. Now, this is independent of gRPC, but they'll often be used together. Protocol Buffers are interesting because of a few different reasons. The first is that they are serialized into a binary format. This takes up less space and makes communication more efficient. The other major benefit is that they have tight information. So the fields within a Protocol Buffer will adhere to particular data types. The structure for the data is described in a Proto file. You can use the Proto files to generate types, so for example, classes or structs in various programming languages. So if I build a bunch of information and I want to communicate to a new app with Protocol Buffers, I can give you the Proto definitions, and you can generate the correct types for your app, even if it's in a different language. So that is an overview of Protocol Buffers, or Protocol Buffers for the full words.

Now let's talk about YAML and TOML. You'll probably run into these for configuration files. These are two you're going to run into, as well as Markdown for notation, often for documentation. So, for example, a README file is going to be an MD file. Working with Markdown will allow you to easily describe how that information should be displayed, and there are a lot of Markdown renderers to show that information. CSV, or comma-separated values, is a common format if you want to export some data. So say you have an Excel spreadsheet, you could probably export that to a CSV file and import that into a different program. The ones I would probably start off with is JSON and probably Markdown, so you can create a README for your project. You only really have to worry about these others if you're using them for specific use cases. So if you're not working with Protocol Buffers, you don't have to worry about learning Protocol Buffers right now.

There we go. We covered the types of communication, the protocols, and the different notations you should be familiar with. So that covers the five core sections of this mind map. The next two sections we have: the app dev lifecycle, which basically talks about the most common things you're going to run into when you start building an app from the start all the way to production. And then the section over here is going to talk about some of the most important cloud services if you start working with something like AWS. So we'll start by first taking a look at the app dev lifecycle, and then we'll come back to the cloud services. So we'll expand this, and we'll go through these one at a time.

So first, taking a look at your local development environment, and this is probably basic stuff you're familiar with. You're going to have an operating system, which is going to be Windows, Linux, or Unix, or Mac. Now, within Linux and Unix, we could get into tons of different operating systems. We're not going to get into all of that in this lesson. It's definitely worth exploring, especially since you'll probably be deploying to a Linux operating system. You might want to be familiar at least with some of the main categories: Ubuntu, Red Hat, and all these other variations. But the main categories is Windows, Linux, or Unix, and then Mac, which is technically Unix-based, but it's going to give you a much different experience than developing on Ubuntu, for example. Generally, you should be familiar with your main operating system and some form of Linux because you're going to be deploying to Linux servers. So you should probably start familiarizing yourself with the Linux commands.

As for local development, we have editors. There's three main categories, and I just gave a few examples, not all of the different ones out there. You'll want to know at least some terminal-based editors, so Vim, Neovim, Nano, especially if you're SSHing into servers. Then there's the text editor, or you might probably hear code editor, and I use the example of VS Code. It's basically like a more involved text editor, giving you some capabilities around code, but it's not a full IDE. IDEs, some examples would be PyCharm or Visual Studio. There's often an IDE for

Every language that people will tend to use, these often have a lot of more capabilities or features, especially if they're language-specific. You might get Python-specific stuff with PyCharm, and Visual Studio is going to have a lot of features with anything built in the .NET world. So C, you're going to get a lot of capabilities there. Which one do you choose? That's ultimately up to you. I personally use VS Code right now, and I've used to use IDEs. I've worked around with terminal-based editors. You should probably try out everything, but you'll probably gravitate towards one depending on what language you use and what you like. I like VS Code 'cause it can do pretty much anything.

Next up, we have source control. You may also hear version control. The biggest one here is Git. You may hear of Subversion or other source control systems, but Git is pretty much the one everybody uses now. You'll want to use Git for all of your code, and that'll help you keep things organized. But most likely, you're going to want to host that somewhere, with the biggest popular providers being GitLab, GitHub, and Bitbucket. So GitHub is different than Git. Git is the software. GitHub is a hosting provider where you can store your repos. So I would recommend using those as well.

Next up, we'll talk about containerization, which we haven't really talked about much yet. So we have Docker. This is pretty much the only containerization software you need to be familiar with, and then this is going to be used to create images. Now, this is something we could get into in a lot of detail. We're just going to go pretty high-level here. Basically, you can think of Docker kind of like a very light VM that runs your code in isolation. And when you work with Docker, there are images, and then there are containers. Images is basically a snapshot of what the container should look like, and you can generate containers from that. So when you create an image, you can keep that locally, or you can upload it somewhere. Here are some of the most popular image hosting websites, which some of these are acronyms, which hopefully I can remember: We have Harbor. This one, we have Google Container Registry or Google Artifact Registry. Here, we have Azure Container Registry, Docker Hub, Elastic Container Registry. This is Amazon's version. Then we have GitHub Container Registry and GitLab Container Registry. There are a million places that you can store these containers, often within whatever ecosystem you're working with. So if you're hosting your source code on GitLab, you might use GitLab's container registry.

So that is the basics of Docker. But it's often the case you'll need to create containers from multiple different images and get them all working together. And because of that, we have this orchestration section. With the most basic example here being Docker Compose, which is kind of like the default way of doing this. If you're working with Docker, you'll probably learn about Docker Compose, and this will help you run your applications. If you need a little bit more, there is Docker Swarm and Kubernetes. And then I have this one on here, Nomad. Something I'm not actually really familiar with, but I read about that. So you might want to look into that in more detail. The big one you're probably going to hear about is Kubernetes. Some people will use Docker Swarm, but I would say in general, the preference has grown to be Kubernetes. And this will allow you to control your containers and basically orchestrate them, which is the entire section we're talking about. Kubernetes is going to help you deploy a bunch of containers, scale as needed, fix things if certain containers go bad. So it's additional software that you might end up using.

There are a lot of different Kubernetes services out there. So I listed some of the popular ones here: Google Kubernetes Engine, Elastic Kubernetes Service, Linode Kubernetes Engine, Azure Kubernetes Service. I probably should have spelled these out. And then IBM Kubernetes Service, DigitalOcean Kubernetes. You can see there are a lot of hosted Kubernetes options. Now, this is the default Kubernetes, just hosted. Sometimes companies will build upon this, offering additional services or, uh, basically allow Kubernetes to work nicely within a larger ecosystem. So this introduces some of the Enterprise extensions. So a big one here being OpenShift from Red Hat. So if you are working within an Enterprise Red Hat environment, you might use OpenShift as your Kubernetes option. And then there are a couple of other ones you may have heard of here, which you can do additional research on. But the idea of Enterprise extensions is that it's basically Kubernetes with more features and more cost, but that can sometimes be worth it, as these providers will help you deploy and get things working.

So that is a crash course of containerization. Probably something we could have covered in a lot more detail, but this will give you basically the essentials. The next thing is, you can start using CI/CD, Continuous Integration, Continuous Deployment. And this will help you deploy things automatically. CI/CD is a series of steps. You may also hear it known as a pipeline. And these steps will take your code from a repository, such as GitHub, run any tests, any kind of validation, checking the syntax, and then ultimately deploy it onto a server. Now, that server could be for a testing environment, or it could be your production environment. This could be tied based off of which branch you're deploying to, or various other configurations. So not only is it just taking the source code and getting it onto the production server, there are various other things you can do. A lot of testing is done in this stage to make sure your code meets certain expectations. So we're specifically talking about automated testing, where that could tie into a CI/CD pipeline. You could also first deploy to a testing environment, which can then be manually tested by developers, stakeholders, testers, anybody who would need to interact with that application before moving it to a production environment.

So opening CI/CD, you'll see a bunch of different tools you can use. Jenkins is a very popular one, as well as GitHub Actions, GitLab CI/CD, if you're working within the GitLab ecosystem, and CircleCI. Now, there's also AWS CodePipeline, Azure DevOps, and GCP DevOps. These are the major CI/CD tools for the big cloud providers. Each one of these is going to have its own way of doing things and potentially different limitations. So you might need to do some research on which one of these you want to use. It's often the case if you get a job, you'll be given a setup that already has a CI/CD pipeline. If there's a dedicated DevOps team, this is probably where they're working, and probably more in the containerization space. Now, you can tie these two things together. So if there are certain steps when it comes to creating images, you can often tie that into the CI/CD pipeline.

Another thing you will want to do when you are deploying software is test the software. I don't do any of that because I don't really make software that has bugs. But in theory, since you guys probably do make bugs, you'll probably want to test your software. Here are some of the most popular testing tools. Now, generally, there's probably a testing framework for whatever language you are using. I used Pytest here as an example. So if you're working with a particular language for your backend, find out what testing frameworks exist, and you can use that to create tests in your code. This can help you make sure you don't have any regressions. If you make some changes, you can run all your tests, confirm that they work, and this is a great way to check edge cases. So if you, for example, put the highest value or one above the highest value, what happens? What should happen? What happens if you make a certain request type to the API? You should get this type of response. Making those things all automated.

Postman is a great tool for those API tests, where I would probably use whatever language is testing framework for testing functions. So actually checking the functionality. Postman tests, I would instead check the end-to-end, so describing what the request should look like and describing what the response should look like for that type of request. You can create a collection of these different tests, run them all at once, making sure your backend is fully functional with a single click of a button. Now, this is additional code that you have to write. So if you make any changes, now you have to change not only your code, but you have to change the test as well. You also might have to debug tests. So not only can you have broken code, but you can have tests that are broken as well. Maybe it says the test is passing, but it's checking for the wrong thing. Then you have a false sense of security, and more code to maintain. Congrats, that's what it's like to be a developer. So keep your tests minimal, just testing the core essential things you need to test, so you don't just have a bloated codebase and a ton of testing you have to maintain.

Now, Swagger, I tend to think of this more as a documentation tool. It will allow you to see all the endpoints for your API, but you can easily look through the different API possibilities and test them in the browser. Here's an example of what that might look like. So you can go in here and say, "Hey, let's get the stores inventory," and then you can run this in the browser, getting the response, confirming that it works the way you would expect. Down here, we have Selenium, Cypress, and Playwright. Three different automation tools you can look into. These can be used to test user interfaces as well as APIs and do various things. And some of these tools can tie into CI/CD, so you can automate some of that testing and making sure things work before doing an automatic deployment. So definitely want to look into these different tools here. Selenium is more of a front-end testing framework, but you can still use it to check that your website's working properly, which can help you confirm that your API is working properly. But if you want to work with APIs directly, probably recommend Cypress, or probably Playwright, which is probably the one of these three I would start with. And there are a bunch of other API testing tools out there as well. So whatever testing library you choose to use, just stick with it, learn it really well, and start to become comfortable with some of that automation. For me, I just use Postman. I created a collection of all of the different requests that I would want to make to the API, wrote some automated tests, and I was able to export all of that into a file so I could keep it in my repo. Maybe that's like an old-school solution. They have some cloud stuff you can use now, but just showing one option that you could try. If you're going to be changing it all the time, you probably not wanting to export and do all that stuff regularly. So you can just keep it local, or you can use one of their cloud options. If you're working in a team environment, probably getting that cloud variation setup would be ideal.

Now, this one's pretty high-level, but you need to keep track of stuff somewhere. Thought I would mention some of these as you probably run into them. I don't think you really need to go and study these, they're pretty basic, but here are some of the different locations you might store software issues. Now, obviously, GitHub Issues, that's going to be the most common for actual code issues, as well as GitLab Issues. But when it comes to tasks and organizing the development process, Notion, Trello, Jira, all tools to better your life by making things more difficult. So check out all of those if you want to try those out. Personally, I use Notion for pretty much everything. It's actually pretty handy. But if you're working in an agile environment or something, companies do have a tendency of overdoing this and making the actual tracking of development more complicated than going and building stuff. But that's an issue for another day.

Next up, we're going to talk about monitoring. These are tools that you can use to keep track of your running applications, making sure they are working as you would expect. This could be monitoring memory usage, request counts, or it could be keeping track of any issues that the end users are experiencing. I'm not going to get into each one of these. The one I'm familiar with most is CloudWatch, which is part of AWS. So that will allow you to get an immediate view of your application, as well as keep track to make sure no issues are happening with that. You might want to tie into some notification system, which some of these might have things for that built in. But two popular ones that I wanted to mention here is PagerDuty, and then OpsGenie. So these are things that can text you, call you, say, "Hey, I know it's Friday night and you're hanging out with friends, but you just broke the entire website. So go fix that." So if that sounds fun, check out one of these. Also, why you shouldn't deploy on a Friday, by the way. But that's pretty much the end-to-end.

So let's do a quick review. You start with your local development, you push your code into source control, you may containerize it, you can optionally have a CI/CD pipeline, which will take the code from version control or from the images, get it out into production. You can have steps in there for automated testing, as well as manually testing using various tools. And then you can keep track of all your problems in these issue tracking softwares, and then monitor, make sure things are going as planned, and getting notified if not. We're almost there. We just have one major section to cover.

Now, and this is going to be about the big three cloud providers, talking about the most common services. The services you should be familiar with will depend on the type of work you are doing. So I'm going to cover the most important ones. However, if you specialize, say you're doing a little bit more stuff in data science, you might get a few more services, or if you have some other specialty that you're working in. These ones are going to really be about if you're deploying APIs, what kinds of stuff you're going to run into. Now, as a general approach for this, I think you should prioritize one cloud provider. Now, yes, eventually having the understanding of other cloud providers is good, as you might be working in a multicloud environment, a company might use multiple services, so you should be familiar with all of them to some degree. But even just knowing the equivalent services will probably get you far enough, because you can compare it to what you already know in one of the services. So if you don't know which one to choose, if you're working within a company, just pick the cloud provider that your company uses. If you're going to be working in an Azure environment, go ahead and learn all of the Azure services. If that's not the case, then I would just recommend AWS. AWS has the largest market share, and that's just the one I'm most familiar with, so that's what I'm going to recommend. But of course, you're not going to go wrong learning any of the others. So if you have a preference for Google, Microsoft, Amazon, go ahead and pick your favorite. Unfortunately, though, you do not get unlimited free computation with Amazon Prime.

Now, when I was first learning these, I was finding it myself getting frustrated because it seems like Amazon has some wild names for these, and you have to kind of memorize them. This frustrated me at first, but as I started to learn them, it was actually helpful because the Google Cloud Platform and Azure names are more general or generic that they're actually harder to remember. For example, AWS Elastic Beanstalk, such a specific weird name that once you actually have it memorized, it's hard to forget. Compare that to Azure App Service, it's just kind of general. At first, that might be helpful because you can kind of guess what that does, but when you introduce a bunch of services and they all have these general names, it gets a little confusing. That's just been my experience. Take it for what it is. Let's just start going through these one at a time, and I'm sure as soon as I finish this video, I'll think of a few more services I should add. So if that's the case, I'll update the mind map so you can go get the most up-to-date version. A lot of these we've already talked about, which is great. So AWS CloudWatch, it's all part of monitoring. So monitoring is used to keep track of what's going on with your applications. Then we have GCP Cloud Monitoring and Azure Monitor. Managed databases: AWS RDS, GCP Cloud SQL, or SQL, Azure Database. So again, as a reminder, this would basically be if you wanted to, for example, host PostgreSQL in the cloud. RDS is not the database, it's just the name for the database hosting. For storage, we have AWS S3, GCP Cloud Storage, and Azure Blob Storage. Kind of like the word blob. So if you need to store files for file uploads in your application, you'll end up using S3 or the equivalent from other clouds.

Next up, we have compute. So if you need to allocate some computing power: EC2, GCP Compute Engine, and Azure VMs. This is the equivalent to a dedicated server from a hosting provider. So if you went and got a dedicated host server from one of these providers, that is the closest thing AWS has. Now, we've talked a little bit about managed services, and then we also have serverless services. So when something is serverless, it still has servers behind the scenes, it's just that you do not deal with them. You just pay as you use it. So you do not provision a certain size of computer or a certain amount of RAM or anything like that. So we have AWS Lambda, GCP Cloud Functions, and Azure Functions. Identity: This has to do with permissions. Kind of boring, but I wanted to throw that in here because you probably hear it. AWS IAM, GCP IAM, or Azure AD Active Directory. The IAM is Identity and Access Management. So this is used to control the access different users have, as well as services. So services can be limited by the rules you define here. Now, when it comes to DNS, if you want to buy a domain or control different DNS settings, we got AWS Route 53, GCP Cloud DNS, and Azure DNS. Now, if you're working on anything with virtual clouds, you'll have AWS VPC, GCP VPC, and Azure VNet. Now, when it comes to CDN services: AWS CloudFront, GCP Cloud CDN, and Azure CDN. For CI/CD, we have AWS CodePipeline, GCP Cloud Build or Deploy, and then Azure DevOps Pipelines. Now, when it comes to certificate management, so say you wanted to have SSL or HTTPS for one of the services you are running, you would use AWS ACM or GCP Certificate Manager or Azure Key Vault certificates. Now, when it comes to containers, we have AWS ECR, Elastic Container Registry, GCP Artifact Registry, and Azure Container Registry. Going back to one of our previous things on image hosting, if you see GCR, this is replaced with Google Artifact Registry, but you might see the previous floating around as well.

Next up, we have serverless compute, which is a little bit different than serverless functions. I guess I didn't get into that in much detail, but if you have some function that you want to execute, you can use a service like AWS Lambda, and you don't have to worry about the larger environment that that would normally run in. Contrast this with serverless compute. It's basically serverless computing, but not just at the function level. You could actually run full apps from this. So we have AWS Fargate, Google Cloud Run, and Azure Container Instances. Kubernetes: We have AWS Elastic Kubernetes Service, Google Kubernetes Engine, and Azure Kubernetes Service. Now, we have this IaC, which we haven't talked about yet, but this is short for Infrastructure as Code. So something you might run into, you might not need to do it, but basically this gives you a way to describe the cloud infrastructure you have set up in code instead of going into the console and setting everything up manually. This will give you the control and flexibility to do whatever you want and describe exactly what that structure is. So you could, one, check that structure into some version control and share it with others if needed, and easily reset services because you have the exact configuration defined in these code files. So AWS CloudFormation, GCP Deployment Manager, and Azure Resource Manager. And then lastly, we have load balancing. So when you make a request to a server, going back to this example here, you might not just hit a single computer. You may actually hit a load balancer, and the load balancer's job is to distribute the requests to multiple servers. There's a few major benefits here. It will distribute and balance the load across multiple servers, so you can scale, and it will allow you to replace individual servers without the service going down. So say you had a web application and you wanted to scale to more users, you're already capped out. What are you going to do? One option is to scale vertically, and this would be you can visualize growing this way using a larger server with more resources that can handle more users, and this is fabulous, but that doesn't give you the fault tolerance if that server shuts down for some reason. So if you have multiple servers, you can load balance them and distribute the load horizontally. This is the difference between scaling up and scaling out. Which one should you do? Well, as you grow, you're most likely going to want to have that fault tolerance provided by a load balancer, so you'll definitely want to scale out to some degree, and then you can adjust those servers vertically. So a little bit of both. Now, I'm sure there are detailed guides out there on the details of scaling web applications, but that will give you the basics. You want to have good machines that can handle the workload, but you also want that fault tolerance, and you achieve that with load balancing. So we have AWS Elastic Load Balancing, Google Cloud Load Balancing, and Azure Load Balancer. And then for other services, TBD, but maybe I'll add in some more here later.

The final thing is the example learning roadmap, and this is what we're going to talk about in the upcoming video. So two things: be sure to check out this roadmap down below. Also, I have mentorship. If you want, basically guidance, accountability, and skill sharpening to get to the point of being a good backend engineer and getting employed, I help people with that. So I have a link down to that below. So that's the first thing, the links. The second thing is check out the upcoming video that's going to take all of this information and tell you the exact things to study if you're new or overwhelmed with all of the different options. You don't have to learn all of these things to be an effective developer. So this roadmap is going to give you exactly where to start. So this is pretty much every technology you should be familiar with if you want to be a successful backend developer. I'm positive there are plenty that I missed. There's probably some that maybe I should remove from this list. These are the questions I have for you. So if you have any things that you would like to add, drop it in a comment down below. Again, check out the links to get this resource and to the mentorship, and I will see you in the upcoming lesson where we'll talk about the roadmap. See you there.