Resources

• Project Spec

Transcript

[00:03] We’re finally ready to get started. We want to start by taking a look at the actual project that we’re going to be working with throughout this entire course. We’re going to be using this fictitious project called FullSnack. This is a food delivery web application. Mainly we’re going to use this as an example, something that can help us illustrate and visualize how all of these different concepts and techniques and tools that we’re going to be talking about, how they apply in practice.

[00:31] You might notice that this application looks very similar to Uber Eats, and that is because it is in fact Uber eats. It just has a different logo. The reason that I wanted to use a real application to illustrate the concepts of the course is that if we had any questions while we are designing the architecture or implementing something in a real project, we would reach out to a PM or a designer to just clarify how a particular feature works. But here we don’t have any of those roles and I’m not going to play the role of our designer here.

[01:04] So instead of using a fictitious application where we have to make things up as we go, I thought we could use a real app that exists. So if we have any questions, we can go to the actual app and click around and figure out how things actually are supposed to work. So feel free to click around Uber Eats if you’ve never purchased any of the delicious food that they have here, or which is I guess it’s mostly just fast food here, but feel free to click around.

[01:31] This is a standard website, an e-commerce application. You can think of it. It has a concept of restaurants and food items and you can add items to a shopping cart and check them out and so on. But again, all of the concepts that we’re going to see are really universal. They don’t depend on this particular type of application. This is just an example that will help us go through the contents and solve some of the exercises that we’re going to be looking at.

[01:57] So I put together this project spec doc, this is a markdown file that you can access on the GitHub repo for the course, which you’ll find a link in the description here. And it’s a good overview, good high level overview of the project that you are going to be working with. So it’s not a very long document, so feel free to go through it right after you watch this video. But for now, we’re just going to focus on some of the high level information.

[02:25] So we’re going to be working with this FullSnack project, and we’re going to be building an architecture, designing an architecture for the customer facing web application. We’re going to see what that means, but that is essentially this type of application, the application that customers will use to purchase food. And we can see some information about the company that we’re working with or the team that we’re going to be working with, which is made of four frontend engineers. Although the team is expected to triple in size in the next 12 months.

[02:56] And essentially our role here is as our tech lead or as an architect that we’re trying to come up with, you know, sort of a foundation for the rest of the team to build the application on top of. So this will include gathering requirements and actually designing the architecture and supporting the team during the implementation.

[03:15] So in the doc you’ll find details about the FullSnack system first, the software system as a whole, and then at the bottom you’ll find more information about the customer web application specifically, which is the one that we’re going to be building. Right now I want to focus on this first section right here to talk about a little bit about this, the software system. And in particular, I want to take a look at this diagram that we have here. This is a system context diagram.

[03:41] It shows us the entire software system that we’re going to be working with. And a software system is essentially a collection of different applications and databases and APIs that kind of all shared the same goal. And then here we see that system represented as a box in the middle of the diagram and we see the context around it, which is essentially two things: the users of the system and other external systems that might be related to the system that we’re working with.

[04:09] In this case, we have three users of the system. We have the customer who is the person who purchases food items through the app, the restaurant, who is the restaurant owner or employee who manages the orders incoming from customers, and then the driver who is the person, the delivery driver who collects the orders from restaurants and delivers them to the customers.

[04:30] This doesn’t mean that they all use the same application, though. They all use the same system. They’re all users of the system. But they might, and in fact, they do use different applications depending on who they are, and which purpose they are using the system for. And then finally, we have two external systems. These are the third party payment systems. This is something like Stripe, for example, that manages credit card information or payments and refunds and so on.

[04:56] And then the admin system, which it’s still part of FullSnack, the company, but it’s managed by a different team. It has a different purpose, but we don’t share really applications between the FullSnack system and the admin system. So for our purposes it is external to the boundaries of our system.

[05:13] In the next section we have information about the system container. These are the building blocks that make up our system. Those are we mentioned before, these are applications and databases and APIs and so on. So it would be really great if we could sort of zoom in to this diagram, because we grab that FullSnack system box here and open it up and see what’s inside of it.

[05:36] See a diagram of all these different containers, and we’re in luck because that’s exactly what the C4 model allows us to do, which is we’re going to see in the next video.