A "tech stack" includes all the technologies used to build a complete web or mobile application - like frameworks, cloud services, libraries, languages, and APIs. Let’s over-engineer a tech stack for an MVP, then simplify it. Learn how to build fullstack apps in courses https://fireship.io/courses/

#tech #code #dev

🔗 Resources

Learn about popular tech in the 100 Second Playlist https://youtube.com/playlist?list=PL0vfts4VzfNiI1BsIK5u7LpPaIDKMJIDN
Petite Vue https://github.com/vuejs/petite-vue
Stacks of successful startups https://stackshare.io/
LAMP https://en.wikipedia.org/wiki/LAMP_(software_bundle)

📚 Chapters

00:00 Intro
00:37 What’s in a Tech Stack?
02:05 Popular Stacks
03:08 Frontend 
05:34 Backend 
08:23 APIs
09:23 Petite Fire Stack

🔥 Get More Content - Upgrade to PRO

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

🎨 My Editor Settings

- Atom One Dark 
- vscode-icons
- Fira Code Font

🔖 Topics Covered

- Choosing a Tech Stack for Web Development
- Comparing JS frameworks
- React State Management with Redux
- Containers with Docker and Kubernetes
- Mobile dev with React Native, Flutter, & Ionic
- APIs with GraphQL and Apollo
- How to build a website
- Cloud Computing Concepts
2024-02-04T13:55:33.989Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
d9242821-fc10-4f3a-89e2-d2ffae6e43d6
b833e6c63753da5035b4a0b51fabc42a1fd5dcfecd98f0f825fa1423a5a8f454
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
If you're learning to code, it means you probably have a $1,000,000,000 startup idea in your head.
But before you can execute that idea, you'll need to choose a tech stack, and you better choose choose wisely because it's a real pain in the ass if you decide to change it later.
Every app is actually just a technology sandwich.
And in today's video, cheat out, I will teach you how to make a sandwich.
We'll look at popular stacks like lamp, mean, mern, mevin, fluff, refi, fart, fancy, and so on.
Then we'll architect our own tech stack from scratch and look at the decision making process for each layer in the stack.
By the end of this video, you'll know how to over engineer a website like a true professional.
If you're new here, like and subscribe, and let me know what kind of tech stack you're using in the comments.
The OG tech stack is LAMP, which came about in the late nineties n stands for Linux, Apache, MySQL, and PHP.
Building a web application in the nineties was a lot more complicated and typically required expensive a commercial software.
LAMP was a free and open source stack that eventually led to web frameworks like WordPress and Joomla.
In modern times, building a web application is much easier, but tech stacks have become far more complicated because there's so many different companies selling shovels in the start up gold rush.
That begs the question, what is a tech stack exactly?
There's no official definition, but I would break it down into 3 parts.
1st, you have the front end layer, which includes the tools required to build a user interface for the end user.
On the web, that likely means a JavaScript framework, or for mobile, it might be iOS, Android, or a cross platform tool like Flutter.
At the other end, we have the back end layer, cheater, which includes a server side runtime like Node.
Js or Python along with a database to store user generated data.
In addition, you'll likely purchase this infrastructure from a big cloud provider and they'll try to lock you in, so I would consider them as part of your tech stack as well.
Now the 3rd and final layer is APIs, which are the tools used to connect the front end to the back end.
That might be something like REST or GraphQL that you roll out on your own, But mostly, it includes essential third party services that you absolutely need to run your app, like Stripe for payments, Twilio for text messaging, SendGrid for email, and so on.
These tools often do things that fall into both the back end and front end categories, so we put them in the middle.
Now let's take a look at some common tech stacks that you've probably heard of.
Starting something with MEAN, which stands for MongoDB, Express, Angular, and Node.
The reason this stack got so popular is because it has a catchy acronym.
Them.
It's important to make that acronym pop because it will automatically make other people in the tech industry think you know what you're doing.
Like on Fireship IO, I made up my own tech stack called FANCY, which stands for Firebase, Hugo, Angular, Node, Stripe, and Express.
It works great, but sometimes I do regret choosing my tech stack entirely for the acronym.
Them.
Others have realized this with the MEAN stack, and there are variations like MERN and Mevin, which use React and Vue respectively.
The reality though is that these acronyms don't to really capture everything you really need in a tech stack.
If you wanna see what other successful companies are using in their stacks, there's a website called stackshare.io.
You can see how popular technologies are in which companies are using them.
Let's go ahead and build our own from scratch.
But the first time around, let's use the hottest of the hot technologies at every single point regardless of cost or complexity.
Don't worry.
By the end of the video, we'll come back and simplify things in a much more practical way.
A.
Let's imagine we're building the next MySpace, an app that requires user authentication, a database to store user generated data that needs to scale around the the world.
Let's start by architecting the front end layer.
The very first question you need to ask is where will my customers be consuming the application?
It.
Is it the web, iOS, Android, desktop, IoT, or something else?
For this app, we'll assume that our customers are primarily it on the web.
But we might also want to build a mobile app in the future.
When targeting the web, the programming language in your front end layer will almost always be JavaScript.
There are tools that can help you avoid JavaScript if you really want to, but if your goal is to build a killer web app, I would highly recommend embracing JavaScript.
But we need this app to scale, so we're not just going to use vanilla JavaScript, but instead TypeScript.
That adds a type system on top of JavaScript, which might help us catch bugs earlier and deliver more reliable code.
The next thing we need is a UI framework, because trying to build a complex UI with vanilla JavaScript is very full.
There's too many options to even analyze, but I have a video comparing 10 of them.
I'm choosing React for this app, not because it's the best or the fastest, but because it's the most popular.
Sadly, many decisions end up being a popularity contest.
As much as I wanted to choose Svelte, I know that choosing React will give me a much larger pool of developers to higher in the future.
On top of that, I can more easily add React Native to my stack to build a mobile app, but React on its own is still not enough for our web application.
We heard on the street that we'll need a state management solution if our app has any hope to scale.
There are dozens of different state management libraries for React alone, but we'll choose the most popular option that everybody also hates the most, Redux.
It allows us to write a lot more boilerplate code, which is awesome because we all know that more code leads to better quality apps.
Now, another glaring problem with our tech stack is that it's currently using vanilla CSS.
It's basically impossible to make CSS look good on its own, so we're going to bring in Tailwind.
That'll give us a bunch of pre built utility classes to style things quickly in exchange for some crazy looking HTML.
We're also going to want a CSS preprocessor like Sass.
Just like TypeScript, It provides some extra syntax to help us write code more efficiently.
And we're also going to need post CSS to purge any unused styles from our code base and prepare our CSS for production.
Now at this point, we have almost everything we need to build the front end.
The only thing we're missing is a module bundler, which takes all of our raw Java script files and combines them into a single bundle that can be used in the browser.
There's many options to choose from and they're notoriously frustrating to configure.
I'm going with webpack, which is the most popular option today.
That'll give us almost everything we need for the front end stack.
Now it's time to switch gears to the hard part, the back end.
The The most important decision you'll make here is the database for your user generated data.
A good option for us might be a NoSQL document database like MongoDB or Firestore.
They're easy to learn, inexpensive, and can scale to practically any workload, but they sometimes to model certain types of relationships, especially things like a social graph that we might want for our Myspace clone.
The most popular database option out there is the relational database, this, like MySQL, Postgres, and many other options.
These databases are great at handling relationships, but they're not quite as flexible to changing requirements and generally more expensive to operate.
There's also more exotic graph database options out there, but in this demo, we'll go with the gold standard of MySQL.
Now that we've chosen our database, we find an article on the web that says it's not going to be fast enough at scale.
To address this, we're going to add a second database to our stack called redis, which is often used as a cache because it stores all of your data in memory as opposed to the disk, which is much faster to read from.
But in order to put these databases to work, we need a server side runtime where we can write code to access data and then send it back to the front end.
There are tons and tons of options to choose from and often the decision comes down to the programming language that you're most comfortable it.
If you like Python, there are frameworks like Flask and Django that help you build server side web applications.
There's Ruby on Rails, Laravel for PHP, Spring for Java, and so on.
As a JavaScript developer, I'm going to go with Node.
Js as my runtime, and then use a framework called Nest to handle the server side web application stuff because it supports TypeScript out of the box.
We also don't wanna have to write raw SQL queries, so we're going to bring in an object relational mapper like type ORM.
So that gives us a runtime for writing and executing code on a server.
But in order to make that server available to the world on the Internet, that.
We also need a web server like NGINX or Apache, so let's throw one of those on the stack as well.
But now that we have a server framework, we need to figure out how to deploy it.
Before we can do that, we need to standardize the environment for our code by containerizing it with Docker.
This creates a standard Linux environment that we can then use to deploy our code to any cloud server.
But as our app scales, we'll need to orchestrate multiple containers.
So for that, we're going to bring in Kubernetes.
Then we'll need to choose 1 or more cloud providers to host all this infrastructure.
Let's Let's go with Amazon Web Services to give us the most complicated user experience.
Now because we're smart, we're not going to just go on AWS and click on buttons.
Instead, we'll use Terraform to programmatically create our infrastructure and version it for better reliability.
Now we also need a place to host our actual source code, and I can think of no better place than GitHub.
The reason we want to host our source code in the cloud is to set up a continuous integration pipeline.
We can add GitHub actions to the stack to automatically test and redeploy our code anytime we push an update to the repository.
That gives us a solid back end, but there are many things our app needs to do that are just too complicated to handle from scratch.
One of those things is building an API for our front end and back end to communicate.
We heard on the Internet that GraphQL awesome.
So we're going to add it to the stack along with a library called Apollo, which will provide code on both our front end and back end to help us build a SQL API, which allows the front end to securely communicate with the back end.
Another thing we're not going to wanna do is deal with payments.
So for that, we're going to bring in Stripe, which provides SDKs for both the server and front end to collect payments.
We also don't wanna deal with user authentication, so we'll bring in auth0 to handle that.
We also don't want dudes uploading dick pics to our platform, so we'll bring in Amazon Rekognition with its deep learning dick detection capabilities.
We also have no idea how to send text messages to our users, so we'll bring in Twilio to help us with that.
I could keep going here, but you get the idea.
We use APIs to help us for the things that are too hard to do on our own.
At this point, we have a nearly complete tech stack, but it's likely way more complicated than it needs to be.
It's important to keep in mind that your end users don't care and will never know what technology you use to build the application.
They just wanna have a good experience, and if you don't build a good experience at first, you'll never get to the point where you actually need something like Kubernetes.
Let's go ahead and throw this entire tech stack in the garbage and start from a plain HTML file.
Now our web app does need to be interactive, so we need some kind of JavaScript a framework.
Instead of something big and heavy, let's throw in a new option called petite view.
It has a syntax that's compatible with Vue.
Js, which many developers out there already know.
And we can drop it in with a script tag, so we're not even going to need a module bundler like webpack.
When it comes to CSS, we'll throw in Bootstrap, which is a little a more cookie cutter than something like Tailwind, but it's probably the quickest way to get to a decent looking UI.
If we decide we need a mobile app, we're going to bring in Ionic to wrap our application in a web view, allowing us to quickly ship it off to iOS and Android.
That takes care of our front end stack.
To simplify the back end, we'll bring in Firebase.
It gives us a document database that choose a scale without any need for a back end server.
It also handles user authentication, and we can include it in the application by simply adding a script tag to the document.
It.
Now we still might want to write some server side code, in which case we can use Firebase Cloud Functions, which is a serverless option that allows us to choose right code in Node.
Js or Python or Go if you prefer, and deploy it with a single command without ever having to worry about the server a duration.
It scales automatically without ever having to worry about Docker, Kubernetes, or Terraform.
When it comes to continuous integration, we're just not going to worry about it.
Unless you find yourself testing and redeploying your app every day, it's probably just a waste of time.
We can also get rid of GraphQL because it's more well suited for complex apps that have multiple APIs to stitch together.
And that leaves us with the petit Firestack, which is quite possibly the easiest way to build a full stack web application.
I'm gonna gonna go ahead and wrap things up there.
But if you wanna learn more about building full stack web applications with Firebase using multiple different front end frameworks, check out Fireship Pro to get access to my full courses.
Thanks Thanks for watching, and I will see you in the next one.

Speaker 0: If you're learning to code, it means you probably have a $1,000,000,000 startup idea in your head. But before you can execute that idea, you'll need to choose a tech stack, and you better choose choose wisely because it's a real pain in the ass if you decide to change it later. Every app is actually just a technology sandwich. And in today's video, cheat out, I will teach you how to make a sandwich. We'll look at popular stacks like lamp, mean, mern, mevin, fluff, refi, fart, fancy, and so on.

Then we'll architect our own tech stack from scratch and look at the decision making process for each layer in the stack. By the end of this video, you'll know how to over engineer a website like a true professional. If you're new here, like and subscribe, and let me know what kind of tech stack you're using in the comments. The OG tech stack is LAMP, which came about in the late nineties n stands for Linux, Apache, MySQL, and PHP. Building a web application in the nineties was a lot more complicated and typically required expensive a commercial software.

LAMP was a free and open source stack that eventually led to web frameworks like WordPress and Joomla. In modern times, building a web application is much easier, but tech stacks have become far more complicated because there's so many different companies selling shovels in the start up gold rush. That begs the question, what is a tech stack exactly? There's no official definition, but I would break it down into 3 parts. 1st, you have the front end layer, which includes the tools required to build a user interface for the end user.

On the web, that likely means a JavaScript framework, or for mobile, it might be iOS, Android, or a cross platform tool like Flutter. At the other end, we have the back end layer, cheater, which includes a server side runtime like Node. Js or Python along with a database to store user generated data. In addition, you'll likely purchase this infrastructure from a big cloud provider and they'll try to lock you in, so I would consider them as part of your tech stack as well. Now the 3rd and final layer is APIs, which are the tools used to connect the front end to the back end.

That might be something like REST or GraphQL that you roll out on your own, But mostly, it includes essential third party services that you absolutely need to run your app, like Stripe for payments, Twilio for text messaging, SendGrid for email, and so on. These tools often do things that fall into both the back end and front end categories, so we put them in the middle. Now let's take a look at some common tech stacks that you've probably heard of. Starting something with MEAN, which stands for MongoDB, Express, Angular, and Node. The reason this stack got so popular is because it has a catchy acronym.

Them. It's important to make that acronym pop because it will automatically make other people in the tech industry think you know what you're doing. Like on Fireship IO, I made up my own tech stack called FANCY, which stands for Firebase, Hugo, Angular, Node, Stripe, and Express. It works great, but sometimes I do regret choosing my tech stack entirely for the acronym. Them.

Others have realized this with the MEAN stack, and there are variations like MERN and Mevin, which use React and Vue respectively. The reality though is that these acronyms don't to really capture everything you really need in a tech stack. If you wanna see what other successful companies are using in their stacks, there's a website called stackshare.io. You can see how popular technologies are in which companies are using them. Let's go ahead and build our own from scratch.

But the first time around, let's use the hottest of the hot technologies at every single point regardless of cost or complexity. Don't worry. By the end of the video, we'll come back and simplify things in a much more practical way. A. Let's imagine we're building the next MySpace, an app that requires user authentication, a database to store user generated data that needs to scale around the the world.

Let's start by architecting the front end layer. The very first question you need to ask is where will my customers be consuming the application? It. Is it the web, iOS, Android, desktop, IoT, or something else? For this app, we'll assume that our customers are primarily it on the web.

But we might also want to build a mobile app in the future. When targeting the web, the programming language in your front end layer will almost always be JavaScript. There are tools that can help you avoid JavaScript if you really want to, but if your goal is to build a killer web app, I would highly recommend embracing JavaScript. But we need this app to scale, so we're not just going to use vanilla JavaScript, but instead TypeScript. That adds a type system on top of JavaScript, which might help us catch bugs earlier and deliver more reliable code.

The next thing we need is a UI framework, because trying to build a complex UI with vanilla JavaScript is very full. There's too many options to even analyze, but I have a video comparing 10 of them. I'm choosing React for this app, not because it's the best or the fastest, but because it's the most popular. Sadly, many decisions end up being a popularity contest. As much as I wanted to choose Svelte, I know that choosing React will give me a much larger pool of developers to higher in the future.

On top of that, I can more easily add React Native to my stack to build a mobile app, but React on its own is still not enough for our web application. We heard on the street that we'll need a state management solution if our app has any hope to scale. There are dozens of different state management libraries for React alone, but we'll choose the most popular option that everybody also hates the most, Redux. It allows us to write a lot more boilerplate code, which is awesome because we all know that more code leads to better quality apps. Now, another glaring problem with our tech stack is that it's currently using vanilla CSS.

It's basically impossible to make CSS look good on its own, so we're going to bring in Tailwind. That'll give us a bunch of pre built utility classes to style things quickly in exchange for some crazy looking HTML. We're also going to want a CSS preprocessor like Sass. Just like TypeScript, It provides some extra syntax to help us write code more efficiently. And we're also going to need post CSS to purge any unused styles from our code base and prepare our CSS for production.

Now at this point, we have almost everything we need to build the front end. The only thing we're missing is a module bundler, which takes all of our raw Java script files and combines them into a single bundle that can be used in the browser. There's many options to choose from and they're notoriously frustrating to configure. I'm going with webpack, which is the most popular option today. That'll give us almost everything we need for the front end stack.

Now it's time to switch gears to the hard part, the back end. The The most important decision you'll make here is the database for your user generated data. A good option for us might be a NoSQL document database like MongoDB or Firestore. They're easy to learn, inexpensive, and can scale to practically any workload, but they sometimes to model certain types of relationships, especially things like a social graph that we might want for our Myspace clone. The most popular database option out there is the relational database, this, like MySQL, Postgres, and many other options.

These databases are great at handling relationships, but they're not quite as flexible to changing requirements and generally more expensive to operate. There's also more exotic graph database options out there, but in this demo, we'll go with the gold standard of MySQL. Now that we've chosen our database, we find an article on the web that says it's not going to be fast enough at scale. To address this, we're going to add a second database to our stack called redis, which is often used as a cache because it stores all of your data in memory as opposed to the disk, which is much faster to read from. But in order to put these databases to work, we need a server side runtime where we can write code to access data and then send it back to the front end.

There are tons and tons of options to choose from and often the decision comes down to the programming language that you're most comfortable it. If you like Python, there are frameworks like Flask and Django that help you build server side web applications. There's Ruby on Rails, Laravel for PHP, Spring for Java, and so on. As a JavaScript developer, I'm going to go with Node. Js as my runtime, and then use a framework called Nest to handle the server side web application stuff because it supports TypeScript out of the box.

We also don't wanna have to write raw SQL queries, so we're going to bring in an object relational mapper like type ORM. So that gives us a runtime for writing and executing code on a server. But in order to make that server available to the world on the Internet, that. We also need a web server like NGINX or Apache, so let's throw one of those on the stack as well. But now that we have a server framework, we need to figure out how to deploy it.

Before we can do that, we need to standardize the environment for our code by containerizing it with Docker. This creates a standard Linux environment that we can then use to deploy our code to any cloud server. But as our app scales, we'll need to orchestrate multiple containers. So for that, we're going to bring in Kubernetes. Then we'll need to choose 1 or more cloud providers to host all this infrastructure.

Let's Let's go with Amazon Web Services to give us the most complicated user experience. Now because we're smart, we're not going to just go on AWS and click on buttons. Instead, we'll use Terraform to programmatically create our infrastructure and version it for better reliability. Now we also need a place to host our actual source code, and I can think of no better place than GitHub. The reason we want to host our source code in the cloud is to set up a continuous integration pipeline.

We can add GitHub actions to the stack to automatically test and redeploy our code anytime we push an update to the repository. That gives us a solid back end, but there are many things our app needs to do that are just too complicated to handle from scratch. One of those things is building an API for our front end and back end to communicate. We heard on the Internet that GraphQL awesome. So we're going to add it to the stack along with a library called Apollo, which will provide code on both our front end and back end to help us build a SQL API, which allows the front end to securely communicate with the back end.

Another thing we're not going to wanna do is deal with payments. So for that, we're going to bring in Stripe, which provides SDKs for both the server and front end to collect payments. We also don't wanna deal with user authentication, so we'll bring in auth0 to handle that. We also don't want dudes uploading dick pics to our platform, so we'll bring in Amazon Rekognition with its deep learning dick detection capabilities. We also have no idea how to send text messages to our users, so we'll bring in Twilio to help us with that.

I could keep going here, but you get the idea. We use APIs to help us for the things that are too hard to do on our own. At this point, we have a nearly complete tech stack, but it's likely way more complicated than it needs to be. It's important to keep in mind that your end users don't care and will never know what technology you use to build the application. They just wanna have a good experience, and if you don't build a good experience at first, you'll never get to the point where you actually need something like Kubernetes.

Let's go ahead and throw this entire tech stack in the garbage and start from a plain HTML file. Now our web app does need to be interactive, so we need some kind of JavaScript a framework. Instead of something big and heavy, let's throw in a new option called petite view. It has a syntax that's compatible with Vue. Js, which many developers out there already know.

And we can drop it in with a script tag, so we're not even going to need a module bundler like webpack. When it comes to CSS, we'll throw in Bootstrap, which is a little a more cookie cutter than something like Tailwind, but it's probably the quickest way to get to a decent looking UI. If we decide we need a mobile app, we're going to bring in Ionic to wrap our application in a web view, allowing us to quickly ship it off to iOS and Android. That takes care of our front end stack. To simplify the back end, we'll bring in Firebase.

It gives us a document database that choose a scale without any need for a back end server. It also handles user authentication, and we can include it in the application by simply adding a script tag to the document. It. Now we still might want to write some server side code, in which case we can use Firebase Cloud Functions, which is a serverless option that allows us to choose right code in Node. Js or Python or Go if you prefer, and deploy it with a single command without ever having to worry about the server a duration.

It scales automatically without ever having to worry about Docker, Kubernetes, or Terraform. When it comes to continuous integration, we're just not going to worry about it. Unless you find yourself testing and redeploying your app every day, it's probably just a waste of time. We can also get rid of GraphQL because it's more well suited for complex apps that have multiple APIs to stitch together. And that leaves us with the petit Firestack, which is quite possibly the easiest way to build a full stack web application.

I'm gonna gonna go ahead and wrap things up there. But if you wanna learn more about building full stack web applications with Firebase using multiple different front end frameworks, check out Fireship Pro to get access to my full courses. Thanks Thanks for watching, and I will see you in the next one.
If you're learning to code, it means you probably have a $1,000,000,000 startup idea in your head. But before you can execute that idea, you'll need to choose a tech stack, and you better choose choose wisely because it's a real pain in the ass if you decide to change it later.
Every app is actually just a technology sandwich. And in today's video, cheat out, I will teach you how to make a sandwich. We'll look at popular stacks like lamp, mean, mern, mevin, fluff, refi, fart, fancy, and so on. Then we'll architect our own tech stack from scratch and look at the decision making process for each layer in the stack.
technology
programming
electronics
computers
ibm
By the end of this video, you'll know how to over engineer a website like a true professional.
If you're new here, like and subscribe, and let me know what kind of tech stack you're using in the comments. The OG tech stack is LAMP, which came about in the late nineties n stands for Linux, Apache, MySQL, and PHP. Building a web application in the nineties was a lot more complicated and typically required expensive a commercial software.
internet
LAMP was a free and open source stack that eventually led to web frameworks like WordPress and Joomla. In modern times, building a web application is much easier, but tech stacks have become far more complicated because there's so many different companies selling shovels in the start up gold rush.
That begs the question, what is a tech stack exactly? There's no official definition, but I would break it down into 3 parts. 1st, you have the front end layer, which includes the tools required to build a user interface for the end user. On the web, that likely means a JavaScript framework, or for mobile, it might be iOS, Android, or a cross platform tool like Flutter.
networking
At the other end, we have the back end layer, cheater, which includes a server side runtime like Node.
Js or Python along with a database to store user generated data. In addition, you'll likely purchase this infrastructure from a big cloud provider and they'll try to lock you in, so I would consider them as part of your tech stack as well. Now the 3rd and final layer is APIs, which are the tools used to connect the front end to the back end. That might be something like REST or GraphQL that you roll out on your own, But mostly, it includes essential third party services that you absolutely need to run your app, like Stripe for payments, Twilio for text messaging, SendGrid for email, and so on.
databases
infrastructure
data management
networking
internet
These tools often do things that fall into both the back end and front end categories, so we put them in the middle. Now let's take a look at some common tech stacks that you've probably heard of. Starting something with MEAN, which stands for MongoDB, Express, Angular, and Node. The reason this stack got so popular is because it has a catchy acronym.
Them. It's important to make that acronym pop because it will automatically make other people in the tech industry think you know what you're doing. Like on Fireship IO, I made up my own tech stack called FANCY, which stands for Firebase, Hugo, Angular, Node, Stripe, and Express. It works great, but sometimes I do regret choosing my tech stack entirely for the acronym.
technology
Them. Others have realized this with the MEAN stack, and there are variations like MERN and Mevin, which use React and Vue respectively. The reality though is that these acronyms don't to really capture everything you really need in a tech stack. If you wanna see what other successful companies are using in their stacks, there's a website called stackshare.io. You can see how popular technologies are in which companies are using them.
Let's go ahead and build our own from scratch. But the first time around, let's use the hottest of the hot technologies at every single point regardless of cost or complexity. Don't worry. By the end of the video, we'll come back and simplify things in a much more practical way. A. Let's imagine we're building the next MySpace, an app that requires user authentication, a database to store user generated data that needs to scale around the the world. Let's start by architecting the front end layer. The very first question you need to ask is where will my customers be consuming the application? It. Is it the web, iOS, Android, desktop, IoT, or something else? For this app, we'll assume that our customers are primarily it on the web. But we might also want to build a mobile app in the future. When targeting the web, the programming language in your front end layer will almost always be JavaScript.
customers
technology
customer support
youtube
telecommunications
multimedia
internet
graphic design
There are tools that can help you avoid JavaScript if you really want to, but if your goal is to build a killer web app, I would highly recommend embracing JavaScript. But we need this app to scale, so we're not just going to use vanilla JavaScript, but instead TypeScript. That adds a type system on top of JavaScript, which might help us catch bugs earlier and deliver more reliable code. The next thing we need is a UI framework, because trying to build a complex UI with vanilla JavaScript is very full. There's too many options to even analyze, but I have a video comparing 10 of them. I'm choosing React for this app, not because it's the best or the fastest, but because it's the most popular. Sadly, many decisions end up being a popularity contest. As much as I wanted to choose Svelte, I know that choosing React will give me a much larger pool of developers to higher in the future. On top of that, I can more easily add React Native to my stack to build a mobile app, but React on its own is still not enough for our web application.
We heard on the street that we'll need a state management solution if our app has any hope to scale. There are dozens of different state management libraries for React alone, but we'll choose the most popular option that everybody also hates the most, Redux. It allows us to write a lot more boilerplate code, which is awesome because we all know that more code leads to better quality apps.
management
software
Now, another glaring problem with our tech stack is that it's currently using vanilla CSS. It's basically impossible to make CSS look good on its own, so we're going to bring in Tailwind. That'll give us a bunch of pre built utility classes to style things quickly in exchange for some crazy looking HTML. We're also going to want a CSS preprocessor like Sass.
Just like TypeScript, It provides some extra syntax to help us write code more efficiently. And we're also going to need post CSS to purge any unused styles from our code base and prepare our CSS for production. Now at this point, we have almost everything we need to build the front end.
programming
The only thing we're missing is a module bundler, which takes all of our raw Java script files and combines them into a single bundle that can be used in the browser.
There's many options to choose from and they're notoriously frustrating to configure. I'm going with webpack, which is the most popular option today. That'll give us almost everything we need for the front end stack. Now it's time to switch gears to the hard part, the back end. The The most important decision you'll make here is the database for your user generated data. A good option for us might be a NoSQL document database like MongoDB or Firestore. They're easy to learn, inexpensive, and can scale to practically any workload, but they sometimes to model certain types of relationships, especially things like a social graph that we might want for our Myspace clone. The most popular database option out there is the relational database, this, like MySQL, Postgres, and many other options. These databases are great at handling relationships, but they're not quite as flexible to changing requirements and generally more expensive to operate. There's also more exotic graph database options out there, but in this demo, we'll go with the gold standard of MySQL. Now that we've chosen our database, we find an article on the web that says it's not going to be fast enough at scale. To address this, we're going to add a second database to our stack called redis, which is often used as a cache because it stores all of your data in memory as opposed to the disk, which is much faster to read from. But in order to put these databases to work, we need a server side runtime where we can write code to access data and then send it back to the front end. There are tons and tons of options to choose from and often the decision comes down to the programming language that you're most comfortable it.
databases
data management
websites
If you like Python, there are frameworks like Flask and Django that help you build server side web applications. There's Ruby on Rails, Laravel for PHP, Spring for Java, and so on. As a JavaScript developer, I'm going to go with Node. Js as my runtime, and then use a framework called Nest to handle the server side web application stuff because it supports TypeScript out of the box.
We also don't wanna have to write raw SQL queries, so we're going to bring in an object relational mapper like type ORM. So that gives us a runtime for writing and executing code on a server. But in order to make that server available to the world on the Internet, that. We also need a web server like NGINX or Apache, so let's throw one of those on the stack as well. But now that we have a server framework, we need to figure out how to deploy it. Before we can do that, we need to standardize the environment for our code by containerizing it with Docker. This creates a standard Linux environment that we can then use to deploy our code to any cloud server. But as our app scales, we'll need to orchestrate multiple containers. So for that, we're going to bring in Kubernetes. Then we'll need to choose 1 or more cloud providers to host all this infrastructure. Let's Let's go with Amazon Web Services to give us the most complicated user experience. Now because we're smart, we're not going to just go on AWS and click on buttons. Instead, we'll use Terraform to programmatically create our infrastructure and version it for better reliability. Now we also need a place to host our actual source code, and I can think of no better place than GitHub.
databases
amazon
internet
networking
infrastructure
software
data management
software development
The reason we want to host our source code in the cloud is to set up a continuous integration pipeline. We can add GitHub actions to the stack to automatically test and redeploy our code anytime we push an update to the repository. That gives us a solid back end, but there are many things our app needs to do that are just too complicated to handle from scratch.
One of those things is building an API for our front end and back end to communicate. We heard on the Internet that GraphQL awesome. So we're going to add it to the stack along with a library called Apollo, which will provide code on both our front end and back end to help us build a SQL API, which allows the front end to securely communicate with the back end. Another thing we're not going to wanna do is deal with payments. So for that, we're going to bring in Stripe, which provides SDKs for both the server and front end to collect payments. We also don't wanna deal with user authentication, so we'll bring in auth0 to handle that. We also don't want dudes uploading dick pics to our platform, so we'll bring in Amazon Rekognition with its deep learning dick detection capabilities. We also have no idea how to send text messages to our users, so we'll bring in Twilio to help us with that. I could keep going here, but you get the idea. We use APIs to help us for the things that are too hard to do on our own. At this point, we have a nearly complete tech stack, but it's likely way more complicated than it needs to be. It's important to keep in mind that your end users don't care and will never know what technology you use to build the application. They just wanna have a good experience, and if you don't build a good experience at first, you'll never get to the point where you actually need something like Kubernetes. Let's go ahead and throw this entire tech stack in the garbage and start from a plain HTML file. Now our web app does need to be interactive, so we need some kind of JavaScript a framework. Instead of something big and heavy, let's throw in a new option called petite view.
billing
infrastructure
databases
technology
software development
amazon
software
internet
twitter
networking
animation
It has a syntax that's compatible with Vue. Js, which many developers out there already know. And we can drop it in with a script tag, so we're not even going to need a module bundler like webpack. When it comes to CSS, we'll throw in Bootstrap, which is a little a more cookie cutter than something like Tailwind, but it's probably the quickest way to get to a decent looking UI.
If we decide we need a mobile app, we're going to bring in Ionic to wrap our application in a web view, allowing us to quickly ship it off to iOS and Android. That takes care of our front end stack. To simplify the back end, we'll bring in Firebase.
phones
It gives us a document database that choose a scale without any need for a back end server. It also handles user authentication, and we can include it in the application by simply adding a script tag to the document. It. Now we still might want to write some server side code, in which case we can use Firebase Cloud Functions, which is a serverless option that allows us to choose right code in Node. Js or Python or Go if you prefer, and deploy it with a single command without ever having to worry about the server a duration. It scales automatically without ever having to worry about Docker, Kubernetes, or Terraform. When it comes to continuous integration, we're just not going to worry about it.
Unless you find yourself testing and redeploying your app every day, it's probably just a waste of time. We can also get rid of GraphQL because it's more well suited for complex apps that have multiple APIs to stitch together. And that leaves us with the petit Firestack, which is quite possibly the easiest way to build a full stack web application.
databases
I'm gonna gonna go ahead and wrap things up there. But if you wanna learn more about building full stack web applications with Firebase using multiple different front end frameworks, check out Fireship Pro to get access to my full courses. Thanks Thanks for watching, and I will see you in the next one.
If you're learning to code, it means you probably have a $1,000,000,000 startup idea in your head. But before you can execute that idea, you'll need to choose a tech stack, and you better choose choose wisely because it's a real pain in the ass if you decide to change it later. Every app is actually just a technology sandwich. And in today's video, cheat out, I will teach you how to make a sandwich. We'll look at popular stacks like lamp, mean, mern, mevin, fluff, refi, fart, fancy, and so on. Then we'll architect our own tech stack from scratch and look at the decision making process for each layer in the stack. By the end of this video, you'll know how to over engineer a website like a true professional. If you're new here, like and subscribe, and let me know what kind of tech stack you're using in the comments. The OG tech stack is LAMP, which came about in the late nineties n stands for Linux, Apache, MySQL, and PHP. Building a web application in the nineties was a lot more complicated and typically required expensive a commercial software. LAMP was a free and open source stack that eventually led to web frameworks like WordPress and Joomla. In modern times, building a web application is much easier, but tech stacks have become far more complicated because there's so many different companies selling shovels in the start up gold rush. That begs the question, what is a tech stack exactly? There's no official definition, but I would break it down into 3 parts. 1st, you have the front end layer, which includes the tools required to build a user interface for the end user. On the web, that likely means a JavaScript framework, or for mobile, it might be iOS, Android, or a cross platform tool like Flutter. At the other end, we have the back end layer, cheater, which includes a server side runtime like Node. Js or Python along with a database to store user generated data. In addition, you'll likely purchase this infrastructure from a big cloud provider and they'll try to lock you in, so I would consider them as part of your tech stack as well. Now the 3rd and final layer is APIs, which are the tools used to connect the front end to the back end. That might be something like REST or GraphQL that you roll out on your own, But mostly, it includes essential third party services that you absolutely need to run your app, like Stripe for payments, Twilio for text messaging, SendGrid for email, and so on. These tools often do things that fall into both the back end and front end categories, so we put them in the middle. Now let's take a look at some common tech stacks that you've probably heard of. Starting something with MEAN, which stands for MongoDB, Express, Angular, and Node. The reason this stack got so popular is because it has a catchy acronym. Them. It's important to make that acronym pop because it will automatically make other people in the tech industry think you know what you're doing. Like on Fireship IO, I made up my own tech stack called FANCY, which stands for Firebase, Hugo, Angular, Node, Stripe, and Express. It works great, but sometimes I do regret choosing my tech stack entirely for the acronym. Them. Others have realized this with the MEAN stack, and there are variations like MERN and Mevin, which use React and Vue respectively. The reality though is that these acronyms don't to really capture everything you really need in a tech stack. If you wanna see what other successful companies are using in their stacks, there's a website called stackshare.io. You can see how popular technologies are in which companies are using them. Let's go ahead and build our own from scratch. But the first time around, let's use the hottest of the hot technologies at every single point regardless of cost or complexity. Don't worry. By the end of the video, we'll come back and simplify things in a much more practical way. A. Let's imagine we're building the next MySpace, an app that requires user authentication, a database to store user generated data that needs to scale around the the world. Let's start by architecting the front end layer. The very first question you need to ask is where will my customers be consuming the application? It. Is it the web, iOS, Android, desktop, IoT, or something else? For this app, we'll assume that our customers are primarily it on the web. But we might also want to build a mobile app in the future. When targeting the web, the programming language in your front end layer will almost always be JavaScript. There are tools that can help you avoid JavaScript if you really want to, but if your goal is to build a killer web app, I would highly recommend embracing JavaScript. But we need this app to scale, so we're not just going to use vanilla JavaScript, but instead TypeScript. That adds a type system on top of JavaScript, which might help us catch bugs earlier and deliver more reliable code. The next thing we need is a UI framework, because trying to build a complex UI with vanilla JavaScript is very full. There's too many options to even analyze, but I have a video comparing 10 of them. I'm choosing React for this app, not because it's the best or the fastest, but because it's the most popular. Sadly, many decisions end up being a popularity contest. As much as I wanted to choose Svelte, I know that choosing React will give me a much larger pool of developers to higher in the future. On top of that, I can more easily add React Native to my stack to build a mobile app, but React on its own is still not enough for our web application. We heard on the street that we'll need a state management solution if our app has any hope to scale. There are dozens of different state management libraries for React alone, but we'll choose the most popular option that everybody also hates the most, Redux. It allows us to write a lot more boilerplate code, which is awesome because we all know that more code leads to better quality apps. Now, another glaring problem with our tech stack is that it's currently using vanilla CSS. It's basically impossible to make CSS look good on its own, so we're going to bring in Tailwind. That'll give us a bunch of pre built utility classes to style things quickly in exchange for some crazy looking HTML. We're also going to want a CSS preprocessor like Sass. Just like TypeScript, It provides some extra syntax to help us write code more efficiently. And we're also going to need post CSS to purge any unused styles from our code base and prepare our CSS for production. Now at this point, we have almost everything we need to build the front end. The only thing we're missing is a module bundler, which takes all of our raw Java script files and combines them into a single bundle that can be used in the browser. There's many options to choose from and they're notoriously frustrating to configure. I'm going with webpack, which is the most popular option today. That'll give us almost everything we need for the front end stack. Now it's time to switch gears to the hard part, the back end. The The most important decision you'll make here is the database for your user generated data. A good option for us might be a NoSQL document database like MongoDB or Firestore. They're easy to learn, inexpensive, and can scale to practically any workload, but they sometimes to model certain types of relationships, especially things like a social graph that we might want for our Myspace clone. The most popular database option out there is the relational database, this, like MySQL, Postgres, and many other options. These databases are great at handling relationships, but they're not quite as flexible to changing requirements and generally more expensive to operate. There's also more exotic graph database options out there, but in this demo, we'll go with the gold standard of MySQL. Now that we've chosen our database, we find an article on the web that says it's not going to be fast enough at scale. To address this, we're going to add a second database to our stack called redis, which is often used as a cache because it stores all of your data in memory as opposed to the disk, which is much faster to read from. But in order to put these databases to work, we need a server side runtime where we can write code to access data and then send it back to the front end. There are tons and tons of options to choose from and often the decision comes down to the programming language that you're most comfortable it. If you like Python, there are frameworks like Flask and Django that help you build server side web applications. There's Ruby on Rails, Laravel for PHP, Spring for Java, and so on. As a JavaScript developer, I'm going to go with Node. Js as my runtime, and then use a framework called Nest to handle the server side web application stuff because it supports TypeScript out of the box. We also don't wanna have to write raw SQL queries, so we're going to bring in an object relational mapper like type ORM. So that gives us a runtime for writing and executing code on a server. But in order to make that server available to the world on the Internet, that. We also need a web server like NGINX or Apache, so let's throw one of those on the stack as well. But now that we have a server framework, we need to figure out how to deploy it. Before we can do that, we need to standardize the environment for our code by containerizing it with Docker. This creates a standard Linux environment that we can then use to deploy our code to any cloud server. But as our app scales, we'll need to orchestrate multiple containers. So for that, we're going to bring in Kubernetes. Then we'll need to choose 1 or more cloud providers to host all this infrastructure. Let's Let's go with Amazon Web Services to give us the most complicated user experience. Now because we're smart, we're not going to just go on AWS and click on buttons. Instead, we'll use Terraform to programmatically create our infrastructure and version it for better reliability. Now we also need a place to host our actual source code, and I can think of no better place than GitHub. The reason we want to host our source code in the cloud is to set up a continuous integration pipeline. We can add GitHub actions to the stack to automatically test and redeploy our code anytime we push an update to the repository. That gives us a solid back end, but there are many things our app needs to do that are just too complicated to handle from scratch. One of those things is building an API for our front end and back end to communicate. We heard on the Internet that GraphQL awesome. So we're going to add it to the stack along with a library called Apollo, which will provide code on both our front end and back end to help us build a SQL API, which allows the front end to securely communicate with the back end. Another thing we're not going to wanna do is deal with payments. So for that, we're going to bring in Stripe, which provides SDKs for both the server and front end to collect payments. We also don't wanna deal with user authentication, so we'll bring in auth0 to handle that. We also don't want dudes uploading dick pics to our platform, so we'll bring in Amazon Rekognition with its deep learning dick detection capabilities. We also have no idea how to send text messages to our users, so we'll bring in Twilio to help us with that. I could keep going here, but you get the idea. We use APIs to help us for the things that are too hard to do on our own. At this point, we have a nearly complete tech stack, but it's likely way more complicated than it needs to be. It's important to keep in mind that your end users don't care and will never know what technology you use to build the application. They just wanna have a good experience, and if you don't build a good experience at first, you'll never get to the point where you actually need something like Kubernetes. Let's go ahead and throw this entire tech stack in the garbage and start from a plain HTML file. Now our web app does need to be interactive, so we need some kind of JavaScript a framework. Instead of something big and heavy, let's throw in a new option called petite view. It has a syntax that's compatible with Vue. Js, which many developers out there already know. And we can drop it in with a script tag, so we're not even going to need a module bundler like webpack. When it comes to CSS, we'll throw in Bootstrap, which is a little a more cookie cutter than something like Tailwind, but it's probably the quickest way to get to a decent looking UI. If we decide we need a mobile app, we're going to bring in Ionic to wrap our application in a web view, allowing us to quickly ship it off to iOS and Android. That takes care of our front end stack. To simplify the back end, we'll bring in Firebase. It gives us a document database that choose a scale without any need for a back end server. It also handles user authentication, and we can include it in the application by simply adding a script tag to the document. It. Now we still might want to write some server side code, in which case we can use Firebase Cloud Functions, which is a serverless option that allows us to choose right code in Node. Js or Python or Go if you prefer, and deploy it with a single command without ever having to worry about the server a duration. It scales automatically without ever having to worry about Docker, Kubernetes, or Terraform. When it comes to continuous integration, we're just not going to worry about it. Unless you find yourself testing and redeploying your app every day, it's probably just a waste of time. We can also get rid of GraphQL because it's more well suited for complex apps that have multiple APIs to stitch together. And that leaves us with the petit Firestack, which is quite possibly the easiest way to build a full stack web application. I'm gonna gonna go ahead and wrap things up there. But if you wanna learn more about building full stack web applications with Firebase using multiple different front end frameworks, check out Fireship Pro to get access to my full courses. Thanks Thanks for watching, and I will see you in the next one.
If
if
you're
you're
learning
learning
to
to
code,
code
it
it
means
means
you
you
probably
probably
have
have
a
a
$1,000,000,000
$1,000,000,000
startup
startup
idea
idea
in
in
your
your
head.
head
But
but
before
before
you
you
can
can
execute
execute
that
that
idea,
idea
you'll
you'll
need
need
to
to
choose
choose
a
a
tech
tech
stack,
stack
and
and
you
you
better
better
choose
choose
choose
choose
wisely
wisely
because
because
it's
it's
a
a
real
real
pain
pain
in
in
the
the
ass
ass
if
if
you
you
decide
decide
to
to
change
change
it
it
later.
later
Every
every
app
app
is
is
actually
actually
just
just
a
a
technology
technology
sandwich.
sandwich
And
and
in
in
today's
today's
video,
video
cheat
cheat
out,
out
I
i
will
will
teach
teach
you
you
how
how
to
to
make
make
a
a
sandwich.
sandwich
We'll
we'll
look
look
at
at
popular
popular
stacks
stacks
like
like
lamp,
lamp
mean,
mean
mern,
mern
mevin,
mevin
fluff,
fluff
refi,
refi
fart,
fart
fancy,
fancy
and
and
so
so
on.
on
Then
then
we'll
we'll
architect
architect
our
our
own
own
tech
tech
stack
stack
from
from
scratch
scratch
and
and
look
look
at
at
the
the
decision
decision
making
making
process
process
for
for
each
each
layer
layer
in
in
the
the
stack.
stack
By
by
the
the
end
end
of
of
this
this
video,
video
you'll
you'll
know
know
how
how
to
to
over
over
engineer
engineer
a
a
website
website
like
like
a
a
true
true
professional.
professional
If
if
you're
you're
new
new
here,
here
like
like
and
and
subscribe,
subscribe
and
and
let
let
me
me
know
know
what
what
kind
kind
of
of
tech
tech
stack
stack
you're
you're
using
using
in
in
the
the
comments.
comments
The
the
OG
og
tech
tech
stack
stack
is
is
LAMP,
lamp
which
which
came
came
about
about
in
in
the
the
late
late
nineties
nineties
n
n
stands
stands
for
for
Linux,
linux
Apache,
apache
MySQL,
mysql
and
and
PHP.
php
Building
building
a
a
web
web
application
application
in
in
the
the
nineties
nineties
was
was
a
a
lot
lot
more
more
complicated
complicated
and
and
typically
typically
required
required
expensive
expensive
a
a
commercial
commercial
software.
software
LAMP
lamp
was
was
a
a
free
free
and
and
open
open
source
source
stack
stack
that
that
eventually
eventually
led
led
to
to
web
web
frameworks
frameworks
like
like
WordPress
wordpress
and
and
Joomla.
joomla
In
in
modern
modern
times,
times
building
building
a
a
web
web
application
application
is
is
much
much
easier,
easier
but
but
tech
tech
stacks
stacks
have
have
become
become
far
far
more
more
complicated
complicated
because
because
there's
there's
so
so
many
many
different
different
companies
companies
selling
selling
shovels
shovels
in
in
the
the
start
start
up
up
gold
gold
rush.
rush
That
that
begs
begs
the
the
question,
question
what
what
is
is
a
a
tech
tech
stack
stack
exactly?
exactly
There's
there's
no
no
official
official
definition,
definition
but
but
I
i
would
would
break
break
it
it
down
down
into
into
3
3
parts.
parts
1st,
1st
you
you
have
have
the
the
front
front
end
end
layer,
layer
which
which
includes
includes
the
the
tools
tools
required
required
to
to
build
build
a
a
user
user
interface
interface
for
for
the
the
end
end
user.
user
On
on
the
the
web,
web
that
that
likely
likely
means
means
a
a
JavaScript
javascript
framework,
framework
or
or
for
for
mobile,
mobile
it
it
might
might
be
be
iOS,
ios
Android,
android
or
or
a
a
cross
cross
platform
platform
tool
tool
like
like
Flutter.
flutter
At
at
the
the
other
other
end,
end
we
we
have
have
the
the
back
back
end
end
layer,
layer
cheater,
cheater
which
which
includes
includes
a
a
server
server
side
side
runtime
runtime
like
like
Node.
node
Js
js
or
or
Python
python
along
along
with
with
a
a
database
database
to
to
store
store
user
user
generated
generated
data.
data
In
in
addition,
addition
you'll
you'll
likely
likely
purchase
purchase
this
this
infrastructure
infrastructure
from
from
a
a
big
big
cloud
cloud
provider
provider
and
and
they'll
they'll
try
try
to
to
lock
lock
you
you
in,
in
so
so
I
i
would
would
consider
consider
them
them
as
as
part
part
of
of
your
your
tech
tech
stack
stack
as
as
well.
well
Now
now
the
the
3rd
3rd
and
and
final
final
layer
layer
is
is
APIs,
apis
which
which
are
are
the
the
tools
tools
used
used
to
to
connect
connect
the
the
front
front
end
end
to
to
the
the
back
back
end.
end
That
that
might
might
be
be
something
something
like
like
REST
rest
or
or
GraphQL
graphql
that
that
you
you
roll
roll
out
out
on
on
your
your
own,
own
But
but
mostly,
mostly
it
it
includes
includes
essential
essential
third
third
party
party
services
services
that
that
you
you
absolutely
absolutely
need
need
to
to
run
run
your
your
app,
app
like
like
Stripe
stripe
for
for
payments,
payments
Twilio
twilio
for
for
text
text
messaging,
messaging
SendGrid
sendgrid
for
for
email,
email
and
and
so
so
on.
on
These
these
tools
tools
often
often
do
do
things
things
that
that
fall
fall
into
into
both
both
the
the
back
back
end
end
and
and
front
front
end
end
categories,
categories
so
so
we
we
put
put
them
them
in
in
the
the
middle.
middle
Now
now
let's
let's
take
take
a
a
look
look
at
at
some
some
common
common
tech
tech
stacks
stacks
that
that
you've
you've
probably
probably
heard
heard
of.
of
Starting
starting
something
something
with
with
MEAN,
mean
which
which
stands
stands
for
for
MongoDB,
mongodb
Express,
express
Angular,
angular
and
and
Node.
node
The
the
reason
reason
this
this
stack
stack
got
got
so
so
popular
popular
is
is
because
because
it
it
has
has
a
a
catchy
catchy
acronym.
acronym
Them.
them
It's
it's
important
important
to
to
make
make
that
that
acronym
acronym
pop
pop
because
because
it
it
will
will
automatically
automatically
make
make
other
other
people
people
in
in
the
the
tech
tech
industry
industry
think
think
you
you
know
know
what
what
you're
you're
doing.
doing
Like
like
on
on
Fireship
fireship
IO,
io
I
i
made
made
up
up
my
my
own
own
tech
tech
stack
stack
called
called
FANCY,
fancy
which
which
stands
stands
for
for
Firebase,
firebase
Hugo,
hugo
Angular,
angular
Node,
node
Stripe,
stripe
and
and
Express.
express
It
it
works
works
great,
great
but
but
sometimes
sometimes
I
i
do
do
regret
regret
choosing
choosing
my
my
tech
tech
stack
stack
entirely
entirely
for
for
the
the
acronym.
acronym
Them.
them
Others
others
have
have
realized
realized
this
this
with
with
the
the
MEAN
mean
stack,
stack
and
and
there
there
are
are
variations
variations
like
like
MERN
mern
and
and
Mevin,
mevin
which
which
use
use
React
react
and
and
Vue
vue
respectively.
respectively
The
the
reality
reality
though
though
is
is
that
that
these
these
acronyms
acronyms
don't
don't
to
to
really
really
capture
capture
everything
everything
you
you
really
really
need
need
in
in
a
a
tech
tech
stack.
stack
If
if
you
you
wanna
wanna
see
see
what
what
other
other
successful
successful
companies
companies
are
are
using
using
in
in
their
their
stacks,
stacks
there's
there's
a
a
website
website
called
called
stackshare.io.
stackshare.io
You
you
can
can
see
see
how
how
popular
popular
technologies
technologies
are
are
in
in
which
which
companies
companies
are
are
using
using
them.
them
Let's
let's
go
go
ahead
ahead
and
and
build
build
our
our
own
own
from
from
scratch.
scratch
But
but
the
the
first
first
time
time
around,
around
let's
let's
use
use
the
the
hottest
hottest
of
of
the
the
hot
hot
technologies
technologies
at
at
every
every
single
single
point
point
regardless
regardless
of
of
cost
cost
or
or
complexity.
complexity
Don't
don't
worry.
worry
By
by
the
the
end
end
of
of
the
the
video,
video
we'll
we'll
come
come
back
back
and
and
simplify
simplify
things
things
in
in
a
a
much
much
more
more
practical
practical
way.
way
A.
a
Let's
let's
imagine
imagine
we're
we're
building
building
the
the
next
next
MySpace,
myspace
an
an
app
app
that
that
requires
requires
user
user
authentication,
authentication
a
a
database
database
to
to
store
store
user
user
generated
generated
data
data
that
that
needs
needs
to
to
scale
scale
around
around
the
the
the
the
world.
world
Let's
let's
start
start
by
by
architecting
architecting
the
the
front
front
end
end
layer.
layer
The
the
very
very
first
first
question
question
you
you
need
need
to
to
ask
ask
is
is
where
where
will
will
my
my
customers
customers
be
be
consuming
consuming
the
the
application?
application
It.
it
Is
is
it
it
the
the
web,
web
iOS,
ios
Android,
android
desktop,
desktop
IoT,
iot
or
or
something
something
else?
else
For
for
this
this
app,
app
we'll
we'll
assume
assume
that
that
our
our
customers
customers
are
are
primarily
primarily
it
it
on
on
the
the
web.
web
But
but
we
we
might
might
also
also
want
want
to
to
build
build
a
a
mobile
mobile
app
app
in
in
the
the
future.
future
When
when
targeting
targeting
the
the
web,
web
the
the
programming
programming
language
language
in
in
your
your
front
front
end
end
layer
layer
will
will
almost
almost
always
always
be
be
JavaScript.
javascript
There
there
are
are
tools
tools
that
that
can
can
help
help
you
you
avoid
avoid
JavaScript
javascript
if
if
you
you
really
really
want
want
to,
to
but
but
if
if
your
your
goal
goal
is
is
to
to
build
build
a
a
killer
killer
web
web
app,
app
I
i
would
would
highly
highly
recommend
recommend
embracing
embracing
JavaScript.
javascript
But
but
we
we
need
need
this
this
app
app
to
to
scale,
scale
so
so
we're
we're
not
not
just
just
going
going
to
to
use
use
vanilla
vanilla
JavaScript,
javascript
but
but
instead
instead
TypeScript.
typescript
That
that
adds
adds
a
a
type
type
system
system
on
on
top
top
of
of
JavaScript,
javascript
which
which
might
might
help
help
us
us
catch
catch
bugs
bugs
earlier
earlier
and
and
deliver
deliver
more
more
reliable
reliable
code.
code
The
the
next
next
thing
thing
we
we
need
need
is
is
a
a
UI
ui
framework,
framework
because
because
trying
trying
to
to
build
build
a
a
complex
complex
UI
ui
with
with
vanilla
vanilla
JavaScript
javascript
is
is
very
very
full.
full
There's
there's
too
too
many
many
options
options
to
to
even
even
analyze,
analyze
but
but
I
i
have
have
a
a
video
video
comparing
comparing
10
10
of
of
them.
them
I'm
i'm
choosing
choosing
React
react
for
for
this
this
app,
app
not
not
because
because
it's
it's
the
the
best
best
or
or
the
the
fastest,
fastest
but
but
because
because
it's
it's
the
the
most
most
popular.
popular
Sadly,
sadly
many
many
decisions
decisions
end
end
up
up
being
being
a
a
popularity
popularity
contest.
contest
As
as
much
much
as
as
I
i
wanted
wanted
to
to
choose
choose
Svelte,
svelte
I
i
know
know
that
that
choosing
choosing
React
react
will
will
give
give
me
me
a
a
much
much
larger
larger
pool
pool
of
of
developers
developers
to
to
higher
higher
in
in
the
the
future.
future
On
on
top
top
of
of
that,
that
I
i
can
can
more
more
easily
easily
add
add
React
react
Native
native
to
to
my
my
stack
stack
to
to
build
build
a
a
mobile
mobile
app,
app
but
but
React
react
on
on
its
its
own
own
is
is
still
still
not
not
enough
enough
for
for
our
our
web
web
application.
application
We
we
heard
heard
on
on
the
the
street
street
that
that
we'll
we'll
need
need
a
a
state
state
management
management
solution
solution
if
if
our
our
app
app
has
has
any
any
hope
hope
to
to
scale.
scale
There
there
are
are
dozens
dozens
of
of
different
different
state
state
management
management
libraries
libraries
for
for
React
react
alone,
alone
but
but
we'll
we'll
choose
choose
the
the
most
most
popular
popular
option
option
that
that
everybody
everybody
also
also
hates
hates
the
the
most,
most
Redux.
redux
It
it
allows
allows
us
us
to
to
write
write
a
a
lot
lot
more
more
boilerplate
boilerplate
code,
code
which
which
is
is
awesome
awesome
because
because
we
we
all
all
know
know
that
that
more
more
code
code
leads
leads
to
to
better
better
quality
quality
apps.
apps
Now,
now
another
another
glaring
glaring
problem
problem
with
with
our
our
tech
tech
stack
stack
is
is
that
that
it's
it's
currently
currently
using
using
vanilla
vanilla
CSS.
css
It's
it's
basically
basically
impossible
impossible
to
to
make
make
CSS
css
look
look
good
good
on
on
its
its
own,
own
so
so
we're
we're
going
going
to
to
bring
bring
in
in
Tailwind.
tailwind
That'll
that'll
give
give
us
us
a
a
bunch
bunch
of
of
pre
pre
built
built
utility
utility
classes
classes
to
to
style
style
things
things
quickly
quickly
in
in
exchange
exchange
for
for
some
some
crazy
crazy
looking
looking
HTML.
html
We're
we're
also
also
going
going
to
to
want
want
a
a
CSS
css
preprocessor
preprocessor
like
like
Sass.
sass
Just
just
like
like
TypeScript,
typescript
It
it
provides
provides
some
some
extra
extra
syntax
syntax
to
to
help
help
us
us
write
write
code
code
more
more
efficiently.
efficiently
And
and
we're
we're
also
also
going
going
to
to
need
need
post
post
CSS
css
to
to
purge
purge
any
any
unused
unused
styles
styles
from
from
our
our
code
code
base
base
and
and
prepare
prepare
our
our
CSS
css
for
for
production.
production
Now
now
at
at
this
this
point,
point
we
we
have
have
almost
almost
everything
everything
we
we
need
need
to
to
build
build
the
the
front
front
end.
end
The
the
only
only
thing
thing
we're
we're
missing
missing
is
is
a
a
module
module
bundler,
bundler
which
which
takes
takes
all
all
of
of
our
our
raw
raw
Java
java
script
script
files
files
and
and
combines
combines
them
them
into
into
a
a
single
single
bundle
bundle
that
that
can
can
be
be
used
used
in
in
the
the
browser.
browser
There's
there's
many
many
options
options
to
to
choose
choose
from
from
and
and
they're
they're
notoriously
notoriously
frustrating
frustrating
to
to
configure.
configure
I'm
i'm
going
going
with
with
webpack,
webpack
which
which
is
is
the
the
most
most
popular
popular
option
option
today.
today
That'll
that'll
give
give
us
us
almost
almost
everything
everything
we
we
need
need
for
for
the
the
front
front
end
end
stack.
stack
Now
now
it's
it's
time
time
to
to
switch
switch
gears
gears
to
to
the
the
hard
hard
part,
part
the
the
back
back
end.
end
The
the
The
the
most
most
important
important
decision
decision
you'll
you'll
make
make
here
here
is
is
the
the
database
database
for
for
your
your
user
user
generated
generated
data.
data
A
a
good
good
option
option
for
for
us
us
might
might
be
be
a
a
NoSQL
nosql
document
document
database
database
like
like
MongoDB
mongodb
or
or
Firestore.
firestore
They're
they're
easy
easy
to
to
learn,
learn
inexpensive,
inexpensive
and
and
can
can
scale
scale
to
to
practically
practically
any
any
workload,
workload
but
but
they
they
sometimes
sometimes
to
to
model
model
certain
certain
types
types
of
of
relationships,
relationships
especially
especially
things
things
like
like
a
a
social
social
graph
graph
that
that
we
we
might
might
want
want
for
for
our
our
Myspace
myspace
clone.
clone
The
the
most
most
popular
popular
database
database
option
option
out
out
there
there
is
is
the
the
relational
relational
database,
database
this,
this
like
like
MySQL,
mysql
Postgres,
postgres
and
and
many
many
other
other
options.
options
These
these
databases
databases
are
are
great
great
at
at
handling
handling
relationships,
relationships
but
but
they're
they're
not
not
quite
quite
as
as
flexible
flexible
to
to
changing
changing
requirements
requirements
and
and
generally
generally
more
more
expensive
expensive
to
to
operate.
operate
There's
there's
also
also
more
more
exotic
exotic
graph
graph
database
database
options
options
out
out
there,
there
but
but
in
in
this
this
demo,
demo
we'll
we'll
go
go
with
with
the
the
gold
gold
standard
standard
of
of
MySQL.
mysql
Now
now
that
that
we've
we've
chosen
chosen
our
our
database,
database
we
we
find
find
an
an
article
article
on
on
the
the
web
web
that
that
says
says
it's
it's
not
not
going
going
to
to
be
be
fast
fast
enough
enough
at
at
scale.
scale
To
to
address
address
this,
this
we're
we're
going
going
to
to
add
add
a
a
second
second
database
database
to
to
our
our
stack
stack
called
called
redis,
redis
which
which
is
is
often
often
used
used
as
as
a
a
cache
cache
because
because
it
it
stores
stores
all
all
of
of
your
your
data
data
in
in
memory
memory
as
as
opposed
opposed
to
to
the
the
disk,
disk
which
which
is
is
much
much
faster
faster
to
to
read
read
from.
from
But
but
in
in
order
order
to
to
put
put
these
these
databases
databases
to
to
work,
work
we
we
need
need
a
a
server
server
side
side
runtime
runtime
where
where
we
we
can
can
write
write
code
code
to
to
access
access
data
data
and
and
then
then
send
send
it
it
back
back
to
to
the
the
front
front
end.
end
There
there
are
are
tons
tons
and
and
tons
tons
of
of
options
options
to
to
choose
choose
from
from
and
and
often
often
the
the
decision
decision
comes
comes
down
down
to
to
the
the
programming
programming
language
language
that
that
you're
you're
most
most
comfortable
comfortable
it.
it
If
if
you
you
like
like
Python,
python
there
there
are
are
frameworks
frameworks
like
like
Flask
flask
and
and
Django
django
that
that
help
help
you
you
build
build
server
server
side
side
web
web
applications.
applications
There's
there's
Ruby
ruby
on
on
Rails,
rails
Laravel
laravel
for
for
PHP,
php
Spring
spring
for
for
Java,
java
and
and
so
so
on.
on
As
as
a
a
JavaScript
javascript
developer,
developer
I'm
i'm
going
going
to
to
go
go
with
with
Node.
node
Js
js
as
as
my
my
runtime,
runtime
and
and
then
then
use
use
a
a
framework
framework
called
called
Nest
nest
to
to
handle
handle
the
the
server
server
side
side
web
web
application
application
stuff
stuff
because
because
it
it
supports
supports
TypeScript
typescript
out
out
of
of
the
the
box.
box
We
we
also
also
don't
don't
wanna
wanna
have
have
to
to
write
write
raw
raw
SQL
sql
queries,
queries
so
so
we're
we're
going
going
to
to
bring
bring
in
in
an
an
object
object
relational
relational
mapper
mapper
like
like
type
type
ORM.
orm
So
so
that
that
gives
gives
us
us
a
a
runtime
runtime
for
for
writing
writing
and
and
executing
executing
code
code
on
on
a
a
server.
server
But
but
in
in
order
order
to
to
make
make
that
that
server
server
available
available
to
to
the
the
world
world
on
on
the
the
Internet,
internet
that.
that
We
we
also
also
need
need
a
a
web
web
server
server
like
like
NGINX
nginx
or
or
Apache,
apache
so
so
let's
let's
throw
throw
one
one
of
of
those
those
on
on
the
the
stack
stack
as
as
well.
well
But
but
now
now
that
that
we
we
have
have
a
a
server
server
framework,
framework
we
we
need
need
to
to
figure
figure
out
out
how
how
to
to
deploy
deploy
it.
it
Before
before
we
we
can
can
do
do
that,
that
we
we
need
need
to
to
standardize
standardize
the
the
environment
environment
for
for
our
our
code
code
by
by
containerizing
containerizing
it
it
with
with
Docker.
docker
This
this
creates
creates
a
a
standard
standard
Linux
linux
environment
environment
that
that
we
we
can
can
then
then
use
use
to
to
deploy
deploy
our
our
code
code
to
to
any
any
cloud
cloud
server.
server
But
but
as
as
our
our
app
app
scales,
scales
we'll
we'll
need
need
to
to
orchestrate
orchestrate
multiple
multiple
containers.
containers
So
so
for
for
that,
that
we're
we're
going
going
to
to
bring
bring
in
in
Kubernetes.
kubernetes
Then
then
we'll
we'll
need
need
to
to
choose
choose
1
1
or
or
more
more
cloud
cloud
providers
providers
to
to
host
host
all
all
this
this
infrastructure.
infrastructure
Let's
let's
Let's
let's
go
go
with
with
Amazon
amazon
Web
web
Services
services
to
to
give
give
us
us
the
the
most
most
complicated
complicated
user
user
experience.
experience
Now
now
because
because
we're
we're
smart,
smart
we're
we're
not
not
going
going
to
to
just
just
go
go
on
on
AWS
aws
and
and
click
click
on
on
buttons.
buttons
Instead,
instead
we'll
we'll
use
use
Terraform
terraform
to
to
programmatically
programmatically
create
create
our
our
infrastructure
infrastructure
and
and
version
version
it
it
for
for
better
better
reliability.
reliability
Now
now
we
we
also
also
need
need
a
a
place
place
to
to
host
host
our
our
actual
actual
source
source
code,
code
and
and
I
i
can
can
think
think
of
of
no
no
better
better
place
place
than
than
GitHub.
github
The
the
reason
reason
we
we
want
want
to
to
host
host
our
our
source
source
code
code
in
in
the
the
cloud
cloud
is
is
to
to
set
set
up
up
a
a
continuous
continuous
integration
integration
pipeline.
pipeline
We
we
can
can
add
add
GitHub
github
actions
actions
to
to
the
the
stack
stack
to
to
automatically
automatically
test
test
and
and
redeploy
redeploy
our
our
code
code
anytime
anytime
we
we
push
push
an
an
update
update
to
to
the
the
repository.
repository
That
that
gives
gives
us
us
a
a
solid
solid
back
back
end,
end
but
but
there
there
are
are
many
many
things
things
our
our
app
app
needs
needs
to
to
do
do
that
that
are
are
just
just
too
too
complicated
complicated
to
to
handle
handle
from
from
scratch.
scratch
One
one
of
of
those
those
things
things
is
is
building
building
an
an
API
api
for
for
our
our
front
front
end
end
and
and
back
back
end
end
to
to
communicate.
communicate
We
we
heard
heard
on
on
the
the
Internet
internet
that
that
GraphQL
graphql
awesome.
awesome
So
so
we're
we're
going
going
to
to
add
add
it
it
to
to
the
the
stack
stack
along
along
with
with
a
a
library
library
called
called
Apollo,
apollo
which
which
will
will
provide
provide
code
code
on
on
both
both
our
our
front
front
end
end
and
and
back
back
end
end
to
to
help
help
us
us
build
build
a
a
SQL
sql
API,
api
which
which
allows
allows
the
the
front
front
end
end
to
to
securely
securely
communicate
communicate
with
with
the
the
back
back
end.
end
Another
another
thing
thing
we're
we're
not
not
going
going
to
to
wanna
wanna
do
do
is
is
deal
deal
with
with
payments.
payments
So
so
for
for
that,
that
we're
we're
going
going
to
to
bring
bring
in
in
Stripe,
stripe
which
which
provides
provides
SDKs
sdks
for
for
both
both
the
the
server
server
and
and
front
front
end
end
to
to
collect
collect
payments.
payments
We
we
also
also
don't
don't
wanna
wanna
deal
deal
with
with
user
user
authentication,
authentication
so
so
we'll
we'll
bring
bring
in
in
auth0
auth0
to
to
handle
handle
that.
that
We
we
also
also
don't
don't
want
want
dudes
dudes
uploading
uploading
dick
dick
pics
pics
to
to
our
our
platform,
platform
so
so
we'll
we'll
bring
bring
in
in
Amazon
amazon
Rekognition
rekognition
with
with
its
its
deep
deep
learning
learning
dick
dick
detection
detection
capabilities.
capabilities
We
we
also
also
have
have
no
no
idea
idea
how
how
to
to
send
send
text
text
messages
messages
to
to
our
our
users,
users
so
so
we'll
we'll
bring
bring
in
in
Twilio
twilio
to
to
help
help
us
us
with
with
that.
that
I
i
could
could
keep
keep
going
going
here,
here
but
but
you
you
get
get
the
the
idea.
idea
We
we
use
use
APIs
apis
to
to
help
help
us
us
for
for
the
the
things
things
that
that
are
are
too
too
hard
hard
to
to
do
do
on
on
our
our
own.
own
At
at
this
this
point,
point
we
we
have
have
a
a
nearly
nearly
complete
complete
tech
tech
stack,
stack
but
but
it's
it's
likely
likely
way
way
more
more
complicated
complicated
than
than
it
it
needs
needs
to
to
be.
be
It's
it's
important
important
to
to
keep
keep
in
in
mind
mind
that
that
your
your
end
end
users
users
don't
don't
care
care
and
and
will
will
never
never
know
know
what
what
technology
technology
you
you
use
use
to
to
build
build
the
the
application.
application
They
they
just
just
wanna
wanna
have
have
a
a
good
good
experience,
experience
and
and
if
if
you
you
don't
don't
build
build
a
a
good
good
experience
experience
at
at
first,
first
you'll
you'll
never
never
get
get
to
to
the
the
point
point
where
where
you
you
actually
actually
need
need
something
something
like
like
Kubernetes.
kubernetes
Let's
let's
go
go
ahead
ahead
and
and
throw
throw
this
this
entire
entire
tech
tech
stack
stack
in
in
the
the
garbage
garbage
and
and
start
start
from
from
a
a
plain
plain
HTML
html
file.
file
Now
now
our
our
web
web
app
app
does
does
need
need
to
to
be
be
interactive,
interactive
so
so
we
we
need
need
some
some
kind
kind
of
of
JavaScript
javascript
a
a
framework.
framework
Instead
instead
of
of
something
something
big
big
and
and
heavy,
heavy
let's
let's
throw
throw
in
in
a
a
new
new
option
option
called
called
petite
petite
view.
view
It
it
has
has
a
a
syntax
syntax
that's
that's
compatible
compatible
with
with
Vue.
vue
Js,
js
which
which
many
many
developers
developers
out
out
there
there
already
already
know.
know
And
and
we
we
can
can
drop
drop
it
it
in
in
with
with
a
a
script
script
tag,
tag
so
so
we're
we're
not
not
even
even
going
going
to
to
need
need
a
a
module
module
bundler
bundler
like
like
webpack.
webpack
When
when
it
it
comes
comes
to
to
CSS,
css
we'll
we'll
throw
throw
in
in
Bootstrap,
bootstrap
which
which
is
is
a
a
little
little
a
a
more
more
cookie
cookie
cutter
cutter
than
than
something
something
like
like
Tailwind,
tailwind
but
but
it's
it's
probably
probably
the
the
quickest
quickest
way
way
to
to
get
get
to
to
a
a
decent
decent
looking
looking
UI.
ui
If
if
we
we
decide
decide
we
we
need
need
a
a
mobile
mobile
app,
app
we're
we're
going
going
to
to
bring
bring
in
in
Ionic
ionic
to
to
wrap
wrap
our
our
application
application
in
in
a
a
web
web
view,
view
allowing
allowing
us
us
to
to
quickly
quickly
ship
ship
it
it
off
off
to
to
iOS
ios
and
and
Android.
android
That
that
takes
takes
care
care
of
of
our
our
front
front
end
end
stack.
stack
To
to
simplify
simplify
the
the
back
back
end,
end
we'll
we'll
bring
bring
in
in
Firebase.
firebase
It
it
gives
gives
us
us
a
a
document
document
database
database
that
that
choose
choose
a
a
scale
scale
without
without
any
any
need
need
for
for
a
a
back
back
end
end
server.
server
It
it
also
also
handles
handles
user
user
authentication,
authentication
and
and
we
we
can
can
include
include
it
it
in
in
the
the
application
application
by
by
simply
simply
adding
adding
a
a
script
script
tag
tag
to
to
the
the
document.
document
It.
it
Now
now
we
we
still
still
might
might
want
want
to
to
write
write
some
some
server
server
side
side
code,
code
in
in
which
which
case
case
we
we
can
can
use
use
Firebase
firebase
Cloud
cloud
Functions,
functions
which
which
is
is
a
a
serverless
serverless
option
option
that
that
allows
allows
us
us
to
to
choose
choose
right
right
code
code
in
in
Node.
node
Js
js
or
or
Python
python
or
or
Go
go
if
if
you
you
prefer,
prefer
and
and
deploy
deploy
it
it
with
with
a
a
single
single
command
command
without
without
ever
ever
having
having
to
to
worry
worry
about
about
the
the
server
server
a
a
duration.
duration
It
it
scales
scales
automatically
automatically
without
without
ever
ever
having
having
to
to
worry
worry
about
about
Docker,
docker
Kubernetes,
kubernetes
or
or
Terraform.
terraform
When
when
it
it
comes
comes
to
to
continuous
continuous
integration,
integration
we're
we're
just
just
not
not
going
going
to
to
worry
worry
about
about
it.
it
Unless
unless
you
you
find
find
yourself
yourself
testing
testing
and
and
redeploying
redeploying
your
your
app
app
every
every
day,
day
it's
it's
probably
probably
just
just
a
a
waste
waste
of
of
time.
time
We
we
can
can
also
also
get
get
rid
rid
of
of
GraphQL
graphql
because
because
it's
it's
more
more
well
well
suited
suited
for
for
complex
complex
apps
apps
that
that
have
have
multiple
multiple
APIs
apis
to
to
stitch
stitch
together.
together
And
and
that
that
leaves
leaves
us
us
with
with
the
the
petit
petit
Firestack,
firestack
which
which
is
is
quite
quite
possibly
possibly
the
the
easiest
easiest
way
way
to
to
build
build
a
a
full
full
stack
stack
web
web
application.
application
I'm
i'm
gonna
gonna
gonna
gonna
go
go
ahead
ahead
and
and
wrap
wrap
things
things
up
up
there.
there
But
but
if
if
you
you
wanna
wanna
learn
learn
more
more
about
about
building
building
full
full
stack
stack
web
web
applications
applications
with
with
Firebase
firebase
using
using
multiple
multiple
different
different
front
front
end
end
frameworks,
frameworks
check
check
out
out
Fireship
fireship
Pro
pro
to
to
get
get
access
access
to
to
my
my
full
full
courses.
courses
Thanks
thanks
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The tech stack is becoming increasingly complex with many companies selling shovels in the start up gold rush, and the front end layer and UI framework are crucial for building a mobile app. recommends React, TypeScript, and Redux for building a full stack web app, including the use of a Postgres database and a serverless option for building a full stack web application. A steady environment and continuous integration are key factors for building a strong user experience. A serverless option for building a full stack web app is recommended, and AWS and AWS Web Services are recommended for developers.
How to OVER Engineer a Website // What is a Tech Stack?
If you're learning to code, it means you probably have a $1,000,000,000 startup idea in your head. But before you can execute that idea, you'll need to choose a tech stack, and you better choose choose wisely because it's a real pain in the ass if you decide to change it later. Every app is actually just a technology sandwich. And in today's video, cheat out, I will teach you how to make a sandwich. We'll look at popular stacks like lamp, mean, mern, mevin, fluff, refi, fart, fancy, and so on. Then we'll architect our own tech stack from scratch and look at the decision making process for each layer in the stack. By the end of this video, you'll know how to over engineer a website like a true professional. If you're new here, like and subscribe, and let me know what kind of tech stack you're using in the comments. The OG tech stack is LAMP, which came about in the late nineties n stands for Linux, Apache, MySQL, and PHP. Building a web application in the nineties was a lot more complicated and typically required expensive a commercial software. LAMP was a free and open source stack that eventually led to web frameworks like WordPress and Joomla. In modern times, building a web application is much easier, but tech stacks have become far more complicated because there's so many different companies selling shovels in the start up gold rush. That begs the question, what is a tech stack exactly? There's no official definition, but I would break it down into 3 parts. 1st, you have the front end layer, which includes the tools required to build a user interface for the end user. On the web, that likely means a JavaScript framework, or for mobile, it might be iOS, Android, or a cross platform tool like Flutter. At the other end, we have the back end layer, cheater, which includes a server side runtime like Node. Js or Python along with a database to store user generated data. In addition, you'll likely purchase this infrastructure from a big cloud provider and they'll try to lock you in, so I would consider them as part of your tech stack as well. Now the 3rd and final layer is APIs, which are the tools used to connect the front end to the back end. That might be something like REST or GraphQL that you roll out on your own, But mostly, it includes essential third party services that you absolutely need to run your app, like Stripe for payments, Twilio for text messaging, SendGrid for email, and so on. These tools often do things that fall into both the back end and front end categories, so we put them in the middle. Now let's take a look at some common tech stacks that you've probably heard of. Starting something with MEAN, which stands for MongoDB, Express, Angular, and Node. The reason this stack got so popular is because it has a catchy acronym. Them. It's important to make that acronym pop because it will automatically make other people in the tech industry think you know what you're doing. Like on Fireship IO, I made up my own tech stack called FANCY, which stands for Firebase, Hugo, Angular, Node, Stripe, and Express. It works great, but sometimes I do regret choosing my tech stack entirely for the acronym. Them. Others have realized this with the MEAN stack, and there are variations like MERN and Mevin, which use React and Vue respectively. The reality though is that these acronyms don't to really capture everything you really need in a tech stack. If you wanna see what other successful companies are using in their stacks, there's a website called stackshare.io. You can see how popular technologies are in which companies are using them. Let's go ahead and build our own from scratch. But the first time around, let's use the hottest of the hot technologies at every single point regardless of cost or complexity. Don't worry. By the end of the video, we'll come back and simplify things in a much more practical way. A. Let's imagine we're building the next MySpace, an app that requires user authentication, a database to store user generated data that needs to scale around the the world. Let's start by architecting the front end layer. The very first question you need to ask is where will my customers be consuming the application? It. Is it the web, iOS, Android, desktop, IoT, or something else? For this app, we'll assume that our customers are primarily it on the web. But we might also want to build a mobile app in the future. When targeting the web, the programming language in your front end layer will almost always be JavaScript. There are tools that can help you avoid JavaScript if you really want to, but if your goal is to build a killer web app, I would highly recommend embracing JavaScript. But we need this app to scale, so we're not just going to use vanilla JavaScript, but instead TypeScript. That adds a type system on top of JavaScript, which might help us catch bugs earlier and deliver more reliable code. The next thing we need is a UI framework, because trying to build a complex UI with vanilla JavaScript is very full. There's too many options to even analyze, but I have a video comparing 10 of them. I'm choosing React for this app, not because it's the best or the fastest, but because it's the most popular. Sadly, many decisions end up being a popularity contest. As much as I wanted to choose Svelte, I know that choosing React will give me a much larger pool of developers to higher in the future. On top of that, I can more easily add React Native to my stack to build a mobile app, but React on its own is still not enough for our web application. We heard on the street that we'll need a state management solution if our app has any hope to scale. There are dozens of different state management libraries for React alone, but we'll choose the most popular option that everybody also hates the most, Redux. It allows us to write a lot more boilerplate code, which is awesome because we all know that more code leads to better quality apps. Now, another glaring problem with our tech stack is that it's currently using vanilla CSS. It's basically impossible to make CSS look good on its own, so we're going to bring in Tailwind. That'll give us a bunch of pre built utility classes to style things quickly in exchange for some crazy looking HTML. We're also going to want a CSS preprocessor like Sass. Just like TypeScript, It provides some extra syntax to help us write code more efficiently. And we're also going to need post CSS to purge any unused styles from our code base and prepare our CSS for production. Now at this point, we have almost everything we need to build the front end. The only thing we're missing is a module bundler, which takes all of our raw Java script files and combines them into a single bundle that can be used in the browser. There's many options to choose from and they're notoriously frustrating to configure. I'm going with webpack, which is the most popular option today. That'll give us almost everything we need for the front end stack. Now it's time to switch gears to the hard part, the back end. The The most important decision you'll make here is the database for your user generated data. A good option for us might be a NoSQL document database like MongoDB or Firestore. They're easy to learn, inexpensive, and can scale to practically any workload, but they sometimes to model certain types of relationships, especially things like a social graph that we might want for our Myspace clone. The most popular database option out there is the relational database, this, like MySQL, Postgres, and many other options. These databases are great at handling relationships, but they're not quite as flexible to changing requirements and generally more expensive to operate. There's also more exotic graph database options out there, but in this demo, we'll go with the gold standard of MySQL. Now that we've chosen our database, we find an article on the web that says it's not going to be fast enough at scale. To address this, we're going to add a second database to our stack called redis, which is often used as a cache because it stores all of your data in memory as opposed to the disk, which is much faster to read from. But in order to put these databases to work, we need a server side runtime where we can write code to access data and then send it back to the front end. There are tons and tons of options to choose from and often the decision comes down to the programming language that you're most comfortable it. If you like Python, there are frameworks like Flask and Django that help you build server side web applications. There's Ruby on Rails, Laravel for PHP, Spring for Java, and so on. As a JavaScript developer, I'm going to go with Node. Js as my runtime, and then use a framework called Nest to handle the server side web application stuff because it supports TypeScript out of the box. We also don't wanna have to write raw SQL queries, so we're going to bring in an object relational mapper like type ORM. So that gives us a runtime for writing and executing code on a server. But in order to make that server available to the world on the Internet, that. We also need a web server like NGINX or Apache, so let's throw one of those on the stack as well. But now that we have a server framework, we need to figure out how to deploy it. Before we can do that, we need to standardize the environment for our code by containerizing it with Docker. This creates a standard Linux environment that we can then use to deploy our code to any cloud server. But as our app scales, we'll need to orchestrate multiple containers. So for that, we're going to bring in Kubernetes. Then we'll need to choose 1 or more cloud providers to host all this infrastructure. Let's Let's go with Amazon Web Services to give us the most complicated user experience. Now because we're smart, we're not going to just go on AWS and click on buttons. Instead, we'll use Terraform to programmatically create our infrastructure and version it for better reliability. Now we also need a place to host our actual source code, and I can think of no better place than GitHub. The reason we want to host our source code in the cloud is to set up a continuous integration pipeline. We can add GitHub actions to the stack to automatically test and redeploy our code anytime we push an update to the repository. That gives us a solid back end, but there are many things our app needs to do that are just too complicated to handle from scratch. One of those things is building an API for our front end and back end to communicate. We heard on the Internet that GraphQL awesome. So we're going to add it to the stack along with a library called Apollo, which will provide code on both our front end and back end to help us build a SQL API, which allows the front end to securely communicate with the back end. Another thing we're not going to wanna do is deal with payments. So for that, we're going to bring in Stripe, which provides SDKs for both the server and front end to collect payments. We also don't wanna deal with user authentication, so we'll bring in auth0 to handle that. We also don't want dudes uploading dick pics to our platform, so we'll bring in Amazon Rekognition with its deep learning dick detection capabilities. We also have no idea how to send text messages to our users, so we'll bring in Twilio to help us with that. I could keep going here, but you get the idea. We use APIs to help us for the things that are too hard to do on our own. At this point, we have a nearly complete tech stack, but it's likely way more complicated than it needs to be. It's important to keep in mind that your end users don't care and will never know what technology you use to build the application. They just wanna have a good experience, and if you don't build a good experience at first, you'll never get to the point where you actually need something like Kubernetes. Let's go ahead and throw this entire tech stack in the garbage and start from a plain HTML file. Now our web app does need to be interactive, so we need some kind of JavaScript a framework. Instead of something big and heavy, let's throw in a new option called petite view. It has a syntax that's compatible with Vue. Js, which many developers out there already know. And we can drop it in with a script tag, so we're not even going to need a module bundler like webpack. When it comes to CSS, we'll throw in Bootstrap, which is a little a more cookie cutter than something like Tailwind, but it's probably the quickest way to get to a decent looking UI. If we decide we need a mobile app, we're going to bring in Ionic to wrap our application in a web view, allowing us to quickly ship it off to iOS and Android. That takes care of our front end stack. To simplify the back end, we'll bring in Firebase. It gives us a document database that choose a scale without any need for a back end server. It also handles user authentication, and we can include it in the application by simply adding a script tag to the document. It. Now we still might want to write some server side code, in which case we can use Firebase Cloud Functions, which is a serverless option that allows us to choose right code in Node. Js or Python or Go if you prefer, and deploy it with a single command without ever having to worry about the server a duration. It scales automatically without ever having to worry about Docker, Kubernetes, or Terraform. When it comes to continuous integration, we're just not going to worry about it. Unless you find yourself testing and redeploying your app every day, it's probably just a waste of time. We can also get rid of GraphQL because it's more well suited for complex apps that have multiple APIs to stitch together. And that leaves us with the petit Firestack, which is quite possibly the easiest way to build a full stack web application. I'm gonna gonna go ahead and wrap things up there. But if you wanna learn more about building full stack web applications with Firebase using multiple different front end frameworks, check out Fireship Pro to get access to my full courses. Thanks Thanks for watching, and I will see you in the next one.
The tech stack is becoming increasingly complex with many companies selling shovels in the start up gold rush, and the front end layer and UI framework are crucial for building a mobile app. recommends React, TypeScript, and Redux for building a full stack web app, including the use of a Postgres database and a serverless option for building a full stack web application. A steady environment and continuous integration are key factors for building a strong user experience. A serverless option for building a full stack web app is recommended, and AWS and AWS Web Services are recommended for developers.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : How to OVER Engineer a Website // What is a Tech Stack? 
        and a small summary : The tech stack is becoming increasingly complex with many companies selling shovels in the start up gold rush, and the front end layer and UI framework are crucial for building a mobile app. recommends React, TypeScript, and Redux for building a full stack web app, including the use of a Postgres database and a serverless option for building a full stack web application. A steady environment and continuous integration are key factors for building a strong user experience. A serverless option for building a full stack web app is recommended, and AWS and AWS Web Services are recommended for developers.
        [/INST]
        
        Generate the video : If you're learning to code, it means you probably have a $1,000,000,000 startup idea in your head. But before you can execute that idea, you'll need to choose a tech stack, and you better choose choose wisely because it's a real pain in the ass if you decide to change it later. Every app is actually just a technology sandwich. And in today's video, cheat out, I will teach you how to make a sandwich. We'll look at popular stacks like lamp, mean, mern, mevin, fluff, refi, fart, fancy, and so on. Then we'll architect our own tech stack from scratch and look at the decision making process for each layer in the stack. By the end of this video, you'll know how to over engineer a website like a true professional. If you're new here, like and subscribe, and let me know what kind of tech stack you're using in the comments. The OG tech stack is LAMP, which came about in the late nineties n stands for Linux, Apache, MySQL, and PHP. Building a web application in the nineties was a lot more complicated and typically required expensive a commercial software. LAMP was a free and open source stack that eventually led to web frameworks like WordPress and Joomla. In modern times, building a web application is much easier, but tech stacks have become far more complicated because there's so many different companies selling shovels in the start up gold rush. That begs the question, what is a tech stack exactly? There's no official definition, but I would break it down into 3 parts. 1st, you have the front end layer, which includes the tools required to build a user interface for the end user. On the web, that likely means a JavaScript framework, or for mobile, it might be iOS, Android, or a cross platform tool like Flutter. At the other end, we have the back end layer, cheater, which includes a server side runtime like Node. Js or Python along with a database to store user generated data. In addition, you'll likely purchase this infrastructure from a big cloud provider and they'll try to lock you in, so I would consider them as part of your tech stack as well. Now the 3rd and final layer is APIs, which are the tools used to connect the front end to the back end. That might be something like REST or GraphQL that you roll out on your own, But mostly, it includes essential third party services that you absolutely need to run your app, like Stripe for payments, Twilio for text messaging, SendGrid for email, and so on. These tools often do things that fall into both the back end and front end categories, so we put them in the middle. Now let's take a look at some common tech stacks that you've probably heard of. Starting something with MEAN, which stands for MongoDB, Express, Angular, and Node. The reason this stack got so popular is because it has a catchy acronym. Them. It's important to make that acronym pop because it will automatically make other people in the tech industry think you know what you're doing. Like on Fireship IO, I made up my own tech stack called FANCY, which stands for Firebase, Hugo, Angular, Node, Stripe, and Express. It works great, but sometimes I do regret choosing my tech stack entirely for the acronym. Them. Others have realized this with the MEAN stack, and there are variations like MERN and Mevin, which use React and Vue respectively. The reality though is that these acronyms don't to really capture everything you really need in a tech stack. If you wanna see what other successful companies are using in their stacks, there's a website called stackshare.io. You can see how popular technologies are in which companies are using them. Let's go ahead and build our own from scratch. But the first time around, let's use the hottest of the hot technologies at every single point regardless of cost or complexity. Don't worry. By the end of the video, we'll come back and simplify things in a much more practical way. A. Let's imagine we're building the next MySpace, an app that requires user authentication, a database to store user generated data that needs to scale around the the world. Let's start by architecting the front end layer. The very first question you need to ask is where will my customers be consuming the application? It. Is it the web, iOS, Android, desktop, IoT, or something else? For this app, we'll assume that our customers are primarily it on the web. But we might also want to build a mobile app in the future. When targeting the web, the programming language in your front end layer will almost always be JavaScript. There are tools that can help you avoid JavaScript if you really want to, but if your goal is to build a killer web app, I would highly recommend embracing JavaScript. But we need this app to scale, so we're not just going to use vanilla JavaScript, but instead TypeScript. That adds a type system on top of JavaScript, which might help us catch bugs earlier and deliver more reliable code. The next thing we need is a UI framework, because trying to build a complex UI with vanilla JavaScript is very full. There's too many options to even analyze, but I have a video comparing 10 of them. I'm choosing React for this app, not because it's the best or the fastest, but because it's the most popular. Sadly, many decisions end up being a popularity contest. As much as I wanted to choose Svelte, I know that choosing React will give me a much larger pool of developers to higher in the future. On top of that, I can more easily add React Native to my stack to build a mobile app, but React on its own is still not enough for our web application. We heard on the street that we'll need a state management solution if our app has any hope to scale. There are dozens of different state management libraries for React alone, but we'll choose the most popular option that everybody also hates the most, Redux. It allows us to write a lot more boilerplate code, which is awesome because we all know that more code leads to better quality apps. Now, another glaring problem with our tech stack is that it's currently using vanilla CSS. It's basically impossible to make CSS look good on its own, so we're going to bring in Tailwind. That'll give us a bunch of pre built utility classes to style things quickly in exchange for some crazy looking HTML. We're also going to want a CSS preprocessor like Sass. Just like TypeScript, It provides some extra syntax to help us write code more efficiently. And we're also going to need post CSS to purge any unused styles from our code base and prepare our CSS for production. Now at this point, we have almost everything we need to build the front end. The only thing we're missing is a module bundler, which takes all of our raw Java script files and combines them into a single bundle that can be used in the browser. There's many options to choose from and they're notoriously frustrating to configure. I'm going with webpack, which is the most popular option today. That'll give us almost everything we need for the front end stack. Now it's time to switch gears to the hard part, the back end. The The most important decision you'll make here is the database for your user generated data. A good option for us might be a NoSQL document database like MongoDB or Firestore. They're easy to learn, inexpensive, and can scale to practically any workload, but they sometimes to model certain types of relationships, especially things like a social graph that we might want for our Myspace clone. The most popular database option out there is the relational database, this, like MySQL, Postgres, and many other options. These databases are great at handling relationships, but they're not quite as flexible to changing requirements and generally more expensive to operate. There's also more exotic graph database options out there, but in this demo, we'll go with the gold standard of MySQL. Now that we've chosen our database, we find an article on the web that says it's not going to be fast enough at scale. To address this, we're going to add a second database to our stack called redis, which is often used as a cache because it stores all of your data in memory as opposed to the disk, which is much faster to read from. But in order to put these databases to work, we need a server side runtime where we can write code to access data and then send it back to the front end. There are tons and tons of options to choose from and often the decision comes down to the programming language that you're most comfortable it. If you like Python, there are frameworks like Flask and Django that help you build server side web applications. There's Ruby on Rails, Laravel for PHP, Spring for Java, and so on. As a JavaScript developer, I'm going to go with Node. Js as my runtime, and then use a framework called Nest to handle the server side web application stuff because it supports TypeScript out of the box. We also don't wanna have to write raw SQL queries, so we're going to bring in an object relational mapper like type ORM. So that gives us a runtime for writing and executing code on a server. But in order to make that server available to the world on the Internet, that. We also need a web server like NGINX or Apache, so let's throw one of those on the stack as well. But now that we have a server framework, we need to figure out how to deploy it. Before we can do that, we need to standardize the environment for our code by containerizing it with Docker. This creates a standard Linux environment that we can then use to deploy our code to any cloud server. But as our app scales, we'll need to orchestrate multiple containers. So for that, we're going to bring in Kubernetes. Then we'll need to choose 1 or more cloud providers to host all this infrastructure. Let's Let's go with Amazon Web Services to give us the most complicated user experience. Now because we're smart, we're not going to just go on AWS and click on buttons. Instead, we'll use Terraform to programmatically create our infrastructure and version it for better reliability. Now we also need a place to host our actual source code, and I can think of no better place than GitHub. The reason we want to host our source code in the cloud is to set up a continuous integration pipeline. We can add GitHub actions to the stack to automatically test and redeploy our code anytime we push an update to the repository. That gives us a solid back end, but there are many things our app needs to do that are just too complicated to handle from scratch. One of those things is building an API for our front end and back end to communicate. We heard on the Internet that GraphQL awesome. So we're going to add it to the stack along with a library called Apollo, which will provide code on both our front end and back end to help us build a SQL API, which allows the front end to securely communicate with the back end. Another thing we're not going to wanna do is deal with payments. So for that, we're going to bring in Stripe, which provides SDKs for both the server and front end to collect payments. We also don't wanna deal with user authentication, so we'll bring in auth0 to handle that. We also don't want dudes uploading dick pics to our platform, so we'll bring in Amazon Rekognition with its deep learning dick detection capabilities. We also have no idea how to send text messages to our users, so we'll bring in Twilio to help us with that. I could keep going here, but you get the idea. We use APIs to help us for the things that are too hard to do on our own. At this point, we have a nearly complete tech stack, but it's likely way more complicated than it needs to be. It's important to keep in mind that your end users don't care and will never know what technology you use to build the application. They just wanna have a good experience, and if you don't build a good experience at first, you'll never get to the point where you actually need something like Kubernetes. Let's go ahead and throw this entire tech stack in the garbage and start from a plain HTML file. Now our web app does need to be interactive, so we need some kind of JavaScript a framework. Instead of something big and heavy, let's throw in a new option called petite view. It has a syntax that's compatible with Vue. Js, which many developers out there already know. And we can drop it in with a script tag, so we're not even going to need a module bundler like webpack. When it comes to CSS, we'll throw in Bootstrap, which is a little a more cookie cutter than something like Tailwind, but it's probably the quickest way to get to a decent looking UI. If we decide we need a mobile app, we're going to bring in Ionic to wrap our application in a web view, allowing us to quickly ship it off to iOS and Android. That takes care of our front end stack. To simplify the back end, we'll bring in Firebase. It gives us a document database that choose a scale without any need for a back end server. It also handles user authentication, and we can include it in the application by simply adding a script tag to the document. It. Now we still might want to write some server side code, in which case we can use Firebase Cloud Functions, which is a serverless option that allows us to choose right code in Node. Js or Python or Go if you prefer, and deploy it with a single command without ever having to worry about the server a duration. It scales automatically without ever having to worry about Docker, Kubernetes, or Terraform. When it comes to continuous integration, we're just not going to worry about it. Unless you find yourself testing and redeploying your app every day, it's probably just a waste of time. We can also get rid of GraphQL because it's more well suited for complex apps that have multiple APIs to stitch together. And that leaves us with the petit Firestack, which is quite possibly the easiest way to build a full stack web application. I'm gonna gonna go ahead and wrap things up there. But if you wanna learn more about building full stack web applications with Firebase using multiple different front end frameworks, check out Fireship Pro to get access to my full courses. Thanks Thanks for watching, and I will see you in the next one.
        