├── README.md ├── assets ├── class-diagram.png ├── container-diagram.png ├── cover.png ├── figma-ui.png ├── sequence-diagram-1.png └── system-context-diagram.png ├── documents ├── adr.md ├── design-doc.md ├── domain-model.md ├── project-spec.md ├── requirements.md └── sequence-diagram-1.md ├── exercise-solutions ├── container-diagram-draft.png ├── domain-model-final.md ├── requirements-final.md ├── sequence-diagram-2.md └── sequence-diagram-2.png └── slides ├── 1.2 Course Overview.pdf ├── 1.3 What is Software Architecture.pdf ├── 1.4 What is Frontend Architecture.pdf ├── 1.5 Architecture vs Software Design.pdf ├── 1.6 The Frontend Architect Role.pdf ├── 2.1 Before We Start.pdf ├── 2.10 Architectural Decisions.pdf ├── 2.3 The C4 Model.pdf ├── 2.4 Exercise 1.pdf ├── 2.6 Architectural Drivers.pdf ├── 3.10 Design Docs.pdf ├── 3.2 Entities, Modules, and Components.pdf ├── 3.3 Domain Modeling.pdf └── 3.6 Breaking Things Down.pdf /README.md: -------------------------------------------------------------------------------- 1 | # Fundamentals of Frontend Architecture 2 | 3 | This repo contains some of the resources we cover in the Fundamentals of Frontend Architecture Course. 4 | 5 | You can take the course for free at [https://frontendatscale.com/courses/frontend-architecture](https://frontendatscale.com/courses/frontend-architecture) 6 | -------------------------------------------------------------------------------- /assets/class-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/assets/class-diagram.png -------------------------------------------------------------------------------- /assets/container-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/assets/container-diagram.png -------------------------------------------------------------------------------- /assets/cover.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/assets/cover.png -------------------------------------------------------------------------------- /assets/figma-ui.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/assets/figma-ui.png -------------------------------------------------------------------------------- /assets/sequence-diagram-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/assets/sequence-diagram-1.png -------------------------------------------------------------------------------- /assets/system-context-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/assets/system-context-diagram.png -------------------------------------------------------------------------------- /documents/adr.md: -------------------------------------------------------------------------------- 1 | # ADR 1: Using Next.js for FullSnack's Customer Web Application 2 | 3 | ## Status 4 | 5 | Accepted 6 | 7 | ## Context 8 | 9 | As we prepare to begin development of FullSnack's new customer web application, one key decision that we need to make is which UI framework we're going to use and what infrastructure we need to deploy it. 10 | 11 | The objective is to create a robust, scalable, and performant web application that can meet our customers' needs efficiently, and given our tight timeline of 4 months, we need to be strategic about tech stack decisions to ensure rapid development and high-quality output. 12 | 13 | ## Decision 14 | 15 | We have decided to use Next.js as the framework for developing FullSnack's new customer web application and host it on our own AWS infrastructure using SST. 16 | 17 | ## Consequences 18 | 19 | ### Positive Consequences 20 | 21 | - **Rapid Development:** Given that all team members are already familiar with Next.js, we can leverage this expertise to accelerate the development process. This will help us meet our tight deadlines without sacrificing quality. 22 | 23 | - **Feature-Rich Framework:** Next.js offers a range of features that are beneficial for modern web development, including server-side rendering, static site generation, and API routes. These features will enable us to build a performant and SEO-friendly application. 24 | 25 | - **Flexibility in Deployment:** Although we cannot use Vercel for deployment, our prototype with the devops team using SST (Serverless Stack) on AWS has shown that we can successfully deploy Next.js applications on our own infrastructure. This ensures that we can leverage Next.js features without being dependent on a specific hosting provider. 26 | 27 | - **Community and Ecosystem:** Next.js has a strong community and ecosystem, providing us with a wealth of resources, plugins, and third-party integrations that can enhance our development process and application capabilities. 28 | 29 | ### Negative Consequences 30 | 31 | - **Initial Setup and Configuration:** Deploying Next.js on our own AWS infrastructure requires an initial setup and configuration phase. While our prototype indicates feasibility, this setup will still require coordination with the devops team and some initial effort. 32 | 33 | - **Learning Curve for Custom Deployment:** The team will need to familiarize themselves with SST and the specifics of deploying Next.js on AWS, which may take some time initially, even though it won’t affect the overall development timeline significantly. 34 | 35 | - **Dependence on Internal Infrastructure:** By choosing to deploy on our own infrastructure, we assume full responsibility for the management, scaling, and maintenance of the deployment environment. This requires a reliable and well-coordinated devops team to ensure smooth operations. 36 | 37 | Overall, the decision to use Next.js aligns well with our current capabilities, resources, and project requirements, allowing us to deliver a high-quality customer web application within the desired timeline. 38 | -------------------------------------------------------------------------------- /documents/design-doc.md: -------------------------------------------------------------------------------- 1 | # FullSnack Customer Web Application High-Level Design Doc 2 | 3 | ## 1. Overview 4 | 5 | This document outlines the high-level architecture design for FullSnack's customer-facing web application. FullSnack aims to rebuild its current MVP web application to support future growth and scalability, and the team is preparing to do so in time for the big marketing launch at the end of the year. 6 | 7 | This design document addresses the architectural requirements, provides a high-level design, considers alternatives, and outlines a timeline for implementation. 8 | 9 | ## 2. Context 10 | 11 | FullSnack's current MVP web application has limitations that prevent it from scaling with the anticipated growth in both team size and user base. The goal is to design a new architecture that is scalable, modular, and maintainable, allowing the frontend team to work efficiently and deliver new features quickly. The new architecture must also meet the business goals and technical constraints outlined by the stakeholders. 12 | 13 | The new customer web application is part of the **FullSnack System**, which is the software system that allows customers to make and track orders, resturants to manage orders, and drivers to collect and deliver orders. 14 | 15 | ![System Context Diagram](../assets/system-context-diagram.png) 16 | 17 | ## 3. Goals and Non-Goals 18 | 19 | ### Goals 20 | 21 | - **Scalability**: Design an architecture that can support a growing team and an increasing number of users. 22 | - **Modularity**: Ensure the codebase is modular to allow multiple developers to work in parallel without conflicts. 23 | - **Performance**: Optimize the application for quick load times and smooth user interactions, especially on mobile devices. 24 | - **Accessibility**: Ensure compliance with WCAG 2.2 accessibility standards. 25 | - **Real-Time Updates**: Implement real-time updates for order tracking and delivery status. 26 | 27 | ### Non-Goals 28 | 29 | - **Backend System Overhaul**: This project focuses solely on the frontend architecture. The backend system will remain as is, with only necessary integrations. 30 | - **Native Mobile App Development**: The scope is limited to the web application, and does not include development of native mobile apps. 31 | 32 | ## 4. High Level Design 33 | 34 | We're going to build the Customer Web Application as a monolothic server-side rendered React app using Next.js. Like other app clients, the customer web app will communicate with the core database and any external services using the existing Core API. It will also subscribe to channels on the Web Sockets Server for any features that require real-time communication. 35 | 36 | ### Container Diagram 37 | 38 | ![Container Diagram](../assets/container-diagram.png) 39 | 40 | ### Architectural Style 41 | 42 | - **Component-Based Architecture**: Utilize a component-based architecture using React to create reusable UI components. 43 | - **Server-Side Rendered Application**: Use Next.js for server-side rendering, static site generation, and improved performance. 44 | - **Monorepo**: Develop our frontend apps and packages in a monorepo to speed up development and remove friction when sharing code. 45 | - **TypeScript**: Use TypeScript for type safety and better developer experience, while allowing gradual adoption to accommodate all team members. 46 | - **Real-Time Communication**: Integrate WebSockets via Socket.io for real-time updates on order status and driver location. 47 | 48 | ### Key Components 49 | 50 | 1. **Home Module**: Serves as the landing page, displaying featured restaurants, promotional banners, and personalized recommendations. 51 | 52 | 2. **Login Module**: Manages user registration, login, and password recovery. 53 | 54 | 3. **Delivery Module**: Handles delivery options and real-time order tracking. 55 | 56 | 4. **Pickup Module**: Manages the process for users to pick up their orders from restaurants. 57 | 58 | 5. **Restaurant Module**: Displays detailed information about individual restaurants and their menus. 59 | 60 | 6. **Shopping Cart Module**: Manages user-selected items before finalizing the order. 61 | 62 | 7. **Menu Item Module**: Displays detailed information and customization options for each menu item. 63 | 64 | 8. **Search Module**: Enables users to search and filter restaurants and food items. 65 | 66 | 9. **Profile Module**: Manages user profile information and settings. 67 | 68 | ### Technology Stack 69 | 70 | - **Frontend**: React, Next.js, TypeScript, Redux, Socket.io 71 | - **Backend**: Java Spring Boot (existing), MySQL (existing), WebSockets (existing) 72 | - **Deployment**: AWS infrastructure 73 | 74 | ## 5. Alternatives Considered 75 | 76 | 1. **Single Page Application (SPA) with React**: While a client-side rendered SPA provides a smooth user experience, it lacks the page load performance and scalability benefits of server-side rendering offered by Next.js. 77 | 2. **Vue.js**: Although some team members are familiar with Vue.js, the majority have experience with React and Next.js, making it a more suitable choice. 78 | 3. **Remix**: Remix was another good candidate, but no one on the team was familiar with it and the unknown unknowns posed a bigger risk than using Next.js given the tight deadline. 79 | 80 | ## 6. Timeline 81 | 82 | ### Phase 1: Discovery and Planning (July 2024 - August 2024) 83 | 84 | - Finalize requirements and gather detailed specifications. 85 | - Design the architecture and create detailed technical documentation. 86 | 87 | ### Phase 2: Initial Development (September 2024 - October 2024) 88 | 89 | - Set up the project structure and configure the development environment. 90 | - Implement core modules: Home, Login, Search, and Profile. 91 | 92 | ### Phase 3: Feature Development (October 2024 - November 2024) 93 | 94 | - Implement remaining modules: Delivery, Pickup, Restaurant, Shopping Cart, and Menu Item. 95 | - Integrate real-time updates using WebSockets. 96 | - Conduct performance and scalability testing. 97 | 98 | ### Phase 4: Testing and Deployment (November 2024) 99 | 100 | - Perform comprehensive end-to-end testing (manual and automated.) 101 | - Deploy to staging environment. 102 | - Deploy to production and monitor for issues. 103 | 104 | ## 7. Risks and Open Questions 105 | 106 | ### Risks 107 | 108 | - **Team Scaling**: As the team triples in size, coordination and communication may become challenging. 109 | - **Performance Bottlenecks**: Ensuring optimal performance for all users, especially on mobile devices, may require significant optimization efforts. 110 | - **Real-Time Updates**: Implementing and testing real-time features can be complex and prone to issues. 111 | 112 | ### Open Questions 113 | 114 | - **Shopping Cart Persistence**: Should the shopping cart contents be persisted for authenticated users? 115 | - **Search Auto-Complete**: Will the search feature include auto-complete functionality, and is there an API endpoint for this? 116 | - **Additional Real-Time Features**: Are there other features requiring real-time functionality beyond order tracking and delivery status? 117 | 118 | ## 8. Appendix 119 | 120 | ### References 121 | 122 | - [Figma UI Designs](https://www.figma.com/design/cKot2kO0cg2PpR3QwgppXm/FullSnack-Spec?node-id=0-1&t=gBOwglj8jVc5t9JR-1) 123 | - [Architectural Requirements Document](../exercise-solutions/requirements-final.md) 124 | - [Domain Model](../exercise-solutions/domain-model-final.md) 125 | - [ADR1: Using Next.js](./adr.md) 126 | -------------------------------------------------------------------------------- /documents/domain-model.md: -------------------------------------------------------------------------------- 1 | # Domain Model 2 | 3 | ## Entities 4 | 5 | - `Customer` 6 | - `Restaurant` 7 | - `RestaurantCategory` 8 | - `ShoppingCart` 9 | 10 | ## Attributes and Operations 11 | 12 | ### `Customer` 13 | 14 | - ID: string 15 | - Name: string 16 | - Email: string 17 | - `addToFavorites(Restaurant.ID)` 18 | 19 | ### `Restaurant` 20 | 21 | - ID: string 22 | - Name: string 23 | - Description: string 24 | - Logo URL: string 25 | - Address: string 26 | - `searchMenuItems(string)` 27 | -------------------------------------------------------------------------------- /documents/project-spec.md: -------------------------------------------------------------------------------- 1 | # Project Spec 2 | 3 | ![Cover](../assets/cover.png) 4 | 5 | ## 0. Project Overview 6 | 7 | **FullSnack** is a recently launched **food delivery service** (similar to Uber Eats, or DoorDash) that is looking to **rebuild their customer-facing web application**, following a successful MVP. 8 | 9 | FullSnack currently has a small team of four frontend engineers, but the team is expected to triple in size in the next 12 months. It's clear that the current customer-facing web app used for the MVP will not scale to the needs of a larger team. 10 | 11 | Your goal as the frontend architect of this project is to **design the architecture of FullSnack's customer-facing web application**. This includes gathering requirements, designing an architecture that meets those requirements, and support the frontend team during implementation. 12 | 13 | ## 1. FullSnack Software System 14 | 15 | _This section describers the entire FullSnack software system. This includes the users of the system, as well as all the applications, databases, and APIs the system is made of. The application that we're building (the customer-facing web app) is a part of this system._ 16 | 17 | ### System Context 18 | 19 | _This is a zoomed out view of the FullSnack system and the context around it. The system context diagram below follows the guidelines of the C4 Model for visualizing software architecture._ 20 | 21 | #### System Users 22 | 23 | - **👩🏻 Customer** — Buyers purchasing food through FullSnack. They use the Customer Web App client to search restaurants and food options, make orders, pay for them, and keep track of the order status. 24 | - **🧑🏽‍🍳 Restaurant** — Restaurant owners and employees. They use the Restaurant Web App client to receive orders made by customers, update the order's status, and update their menu options in the system. 25 | - **🛵 Driver** — Delivery drivers. They use the Driver Mobile App client to collect orders from restaurants and deliver them to customers. 26 | 27 | #### External Systems 28 | 29 | - **Third-party Payment System** — Third-party software system used by FullSnack's applications to manage payments, refunds, and credit card information. 30 | - **FullSnack Admin System** — Software system used by FullSnack's employees such as system administrators and customer support agents to manage and moderate the FullSnack system. 31 | 32 | #### System Context Diagram 33 | 34 | ![System Context Diagram](../assets/system-context-diagram.png) 35 | 36 | ### System Containers 37 | 38 | _These are the building blocks of the system. Use this list as well as the system context diagram above to build the container diagram for the FullSnack software system._ 39 | 40 | - **Customer Web App** — This is the app that we're designing the architecture for. It's a web application used by customers to search for restaurants and make food delivery orders. 41 | - **Restaurant Web App** [React SPA] — The web application used by restaurants to receive orders and update their status and manage their menu options. 42 | - **Driver Mobile App** [Native iOS + Android] — The app used by Drivers to collect orders from restaurants and deliver them to customers. 43 | - **Core API** [Java Spring Boot] — REST API used by all mobile and web apps within the system to manage customer information, orders, and restaurant menu items. The Core API also acts as a gateway to external systems (i.e. third-party payment and admin systems.) 44 | - **Core Database** [MySQL] — Main data store for the application. The Core API reads from and writes to this database. 45 | - **WebSockets Server** [Socket.io] — Used to communicate real-time events with registered clients (e.g. updating order status or broadcasting a driver's location.) 46 | 47 | #### Container Diagram 48 | 49 | _To be completed... by you! See Exercise 1 for more details._ 50 | 51 | --- 52 | 53 | ## 2. FullSnack Customer Web Application 54 | 55 | _This section describes the customer-facing application in more detail. It's meant to give you a high-level understanding of the app we're designing the architecture for, and it should have enough information to complete the exercises in the workshop._ 56 | 57 | ### UI Designs 58 | 59 | 👉🏽 Check out the [Figma spec](https://www.figma.com/design/cKot2kO0cg2PpR3QwgppXm/FullSnack-Spec?node-id=0-1&t=gBOwglj8jVc5t9JR-1). 60 | 61 | _Note: This is not an **actual** UI spec—it's just screenshots from Uber Eats with a different logo. We'll refer to the spec in a few modules, but it's provided mainly for illustration purposes. UI copyright belongs to Uber Eats._ 62 | 63 | ![Screenshot of Figma Spec](../assets/figma-ui.png) 64 | 65 | ### Functional Requirements 66 | 67 | _This section lists some of the main functional requirements of FullSnack's web app. This is more of a functionality overview to help guide some of your architectural decisions._ 68 | 69 | #### Authentication 70 | 71 | - Customers can browse the app without being authenticated. 72 | - Customers can create an account using email, phone number, or social media accounts. 73 | - Customers can authenticate using their created account credentials. 74 | - Authenticated customers can update their profile information. 75 | - Authenticated customers can reset their passwords if forgotten. 76 | 77 | #### Browsing and Searching 78 | 79 | - Customers can browse restaurants and food items without authentication. 80 | - Customers can search for restaurants by name. 81 | - Customers can search for restaurants by type of food. 82 | - Customers can filter search results by various criteria (e.g., ratings, delivery time, distance). 83 | 84 | #### Favorites and Recommendations 85 | 86 | - Authenticated customers can add restaurants to their favorites. 87 | - Authenticated customers can add food items to their favorites. 88 | - The app can provide personalized restaurant and food item recommendations based on customer preferences and order history. 89 | 90 | #### Ordering Food 91 | 92 | - Customers can add food items to a shopping cart (with or without authentication). 93 | - Customers can customize food items (e.g., add toppings, select portion size). 94 | - Customers can apply promo codes or discounts to their orders. 95 | - Customers can place an order from a restaurant, including multiple items per order (only authenticated customers). 96 | - Customers can schedule orders for later delivery or pickup. 97 | 98 | #### Payment 99 | 100 | - Customers can choose from multiple payment methods (e.g., credit/debit cards, digital wallets). 101 | - Customers can save payment information for future orders. 102 | - Customers can view an order summary and total cost before confirming the order. 103 | - Customers can receive an email confirmation with a digital receipt after placing an order. 104 | 105 | #### Order Tracking 106 | 107 | - After placing an order, customers can see a real-time tracker of their order status. 108 | - Customers receive notifications about their order status (e.g., order confirmed, food being prepared, out for delivery). 109 | - Once an order is out for delivery, customers can see a real-time map showing the driver's current location. 110 | - Customers can contact the delivery driver or the restaurant in case of issues. 111 | 112 | #### Ratings and Reviews 113 | 114 | - Customers can rate and review restaurants and food items after receiving their orders. 115 | - Customers can view ratings and reviews from other users. 116 | - Customers can receive a notification if a restaurant responds to one of their reviews. 117 | 118 | ### Architectural Requirements 119 | 120 | 👉🏽 Check out the [requirements doc](requirements.md). 121 | -------------------------------------------------------------------------------- /documents/requirements.md: -------------------------------------------------------------------------------- 1 | # Architectural Requirements 2 | 3 | This is a living document with the architectural requirements of FullSnack's new customer-facing web application. 4 | 5 | For more information, check out the [Project Spec](./project-spec.md). 6 | 7 | ## Business Goals 8 | 9 | | Stakeholder | Goal | Context | 10 | | --------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | 11 | | Julio (CEO) | Increase number of customer orders by 100% in one year | As a new player in the market, FullSnack needs to attract new customers with their exciting new app. | 12 | | Megan (VP of Engineering) | Improve team velocity and cycle time by 25% | The new architecture should allow developers to ship features faster without compromising quality. | 13 | | Lauren (Frontend Developer) | Ship code to production confidently, without fear of breaking her teammate's features | The current big ball of mud architecture makes it hard to visualize the impact of a code change. | 14 | | Maxi (Customer Persona) | Order delicious food from his phone or computer and have it delivered as quickly as possible | Maxi is hungry and wants to eat a taco plate right now. | 15 | 16 | ## Contraints 17 | 18 | | Constraint | Context | 19 | | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | 20 | | [Technical] Must be deployed on AWS infrastructure | Our DevOps team only provides support and monitoring for AWS services. | 21 | | [Technical] Must be responsive and fully functional on mobile devices | Over half of our traffic comes from mobile devices and our native mobile application won't be ready to launch for at least 6 months. | 22 | | [Business] Must ship to production by November 2024 (4 months from now) | FullSnack is planning a massive marketing launch in November and this product is a key component of the marketing strategy. | 23 | 24 | ## Quality Attributes 25 | 26 | | Quality Attribute | Scenario | Priority | 27 | | ----------------- | ------------------------------------------------------------------------------------------------------------- | -------- | 28 | | Performance | A user on a mobile device with a 4G connection can load the app in 5 seconds or less. | High | 29 | | Scalability | The codebase should be modularized to allow and increasing number of frontend developers to work in parallel. | High | 30 | | Accessibility | The app should comply with WCAG 2.2 accessibility standards. | Medium | 31 | | Performance | Real-time updates should be broadcast to all listening clients within 15 seconds. | Low | 32 | | Deployability | Code changes should be deployed to production within 10 minutes of starting a release. | Low | 33 | 34 | ## Influential Functional Requirements 35 | 36 | _To be completed... by you! See Exercise 2 for more details._ 37 | 38 | ## Other Influencers 39 | 40 | - Currently, the frontend team is a single team of 4 developers, but this is expected to change as the number of developers is expected to triple in size over the next year. 41 | - Every frontend developer on the team has experience working with React and Next.js, and some of them are also comfortable working with Vue.js and Laravel. 42 | - Not everyone on the team is comfortable working with TypeScript. 43 | -------------------------------------------------------------------------------- /documents/sequence-diagram-1.md: -------------------------------------------------------------------------------- 1 | # Order Placement Sequence 2 | 3 | ```mermaid 4 | sequenceDiagram 5 | title Order Placement Sequence 6 | participant Customer 7 | participant Web App 8 | participant Core API 9 | participant DB 10 | participant Payments System 11 | 12 | Customer->>Web App: Click order button 13 | Web App->>Core API: Sends Order ID and
payment information 14 | Core API->>DB: Get total by order ID 15 | DB-->>Core API: Return order total 16 | Core API->>Payments System: Send payment request 17 | Payments System-->>Core API: Return payment confirmation 18 | Core API-->>Web App: Return confirmation 19 | Web App-->>Customer: Show confirmation message 20 | ``` 21 | 22 | ## Mermaid Live URL 23 | 24 | https://mermaid.live/edit#pako:eNptUkuPmzAQ_iuWz3nZJBCsKtJmqaqcGjWHSlUuBjtgLWBqD21plP9eAybqbsLJzHyvGc0VZ1pIzLCVP1tZZzJRPDe8OtfIfaCglOirEdKgY8kzWcka0MlDR0zDDahMNdx1XlsLupLmsfNdpuilaZ5QtJHo5Xh47CT7x9qRd30Ei06dBelSjpDJd77beSOGXkuVvSE9ZE9bAO2xHuCgkzVzE9XC-jkPCeK1QJ9Sg5Y7Zz4YIlVftKk4qElmIjudZM_QFwkINPASpZ03PSQjMtnP35l9k9Ca2oMGzoPihzHHgPcspt-_hZH1AfrUaiJmur6o51P8vznPekRPq-s9_MZdtEL_fodFlbSW5xLPsANUXAl3Xtde4YyhcCd0xsw9BTdvZ3yubw7HW9Cnrs4wA9PKGW4bwWE6RcwuvLT36mehQJt7sdTc7RGzK4au6Q85Vxac5JAo7-utKV25AGgsWy779iJXULTpItPV0ipRuAMrfsXhMqThltNAhlHAN0EgspTE2wtdk4uIVoRyfLvNsLvDXvUPZoQEi3hL400Urkm8opt4hjvM5pQsAhputiQOwiAgQRA52l-t3SRkQcmW0nAVbUhE13Q96P0Yen4go9u88H-3f0QMLqc 25 | 26 | ![Sequence Diagram](../assets/sequence-diagram-1.png) 27 | -------------------------------------------------------------------------------- /exercise-solutions/container-diagram-draft.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/exercise-solutions/container-diagram-draft.png -------------------------------------------------------------------------------- /exercise-solutions/domain-model-final.md: -------------------------------------------------------------------------------- 1 | # Domain Model 2 | 3 | ## Entities 4 | 5 | - `Customer` 6 | - `Restaurant` 7 | - `RestaurantCategory` 8 | - `Review` 9 | - `MenuItem` 10 | - `MenuItemCategory` 11 | - `MenuItemOption` 12 | - `ShoppingCart` 13 | 14 | ## Attributes and Operations 15 | 16 | ### `Customer` 17 | 18 | - ID: string 19 | - Name: string 20 | - Email: string 21 | - Address: string 22 | - `addToFavorites(Restaurant.ID)` 23 | - `addToCart(MenuItem.ID, MenuItemOption[])` 24 | 25 | ### `Restaurant` 26 | 27 | - ID: string 28 | - Name: string 29 | - Description: string 30 | - Logo URL: string 31 | - Address: string 32 | - Categories: RestaurantCategory[] 33 | - Delivery Fee: number 34 | - Delivery Time: [number, number] 35 | - Offers Delivery: boolean 36 | - Offers Pickup: boolean 37 | - Offers Group Orders: boolean 38 | - Business Hours: [date, date] 39 | - Rating: number 40 | - Reviews: Review[] 41 | - Menu Items: MenuItem[] 42 | - `searchMenuItems(string)` 43 | 44 | ### `RestaurantCategory` 45 | 46 | - ID: string 47 | - Name: string 48 | 49 | ### `Review` 50 | 51 | - ID: string 52 | - Rating: number 53 | - Customer ID: string 54 | - Date: date 55 | - Comment: string 56 | 57 | ### `MenuItem` 58 | 59 | - ID: string 60 | - Name: string 61 | - Description: string 62 | - Price: number 63 | - Customer Likes: number 64 | - Categories: MenuItemCategory[] 65 | - Options: MenuItemOption[] 66 | 67 | ### `MenuItemCategory` 68 | 69 | - ID: string 70 | - Name: string 71 | 72 | ### `MenuItemOption` 73 | 74 | - ID: string 75 | - Name: string 76 | - Price: number 77 | - Is Popular: boolean 78 | 79 | ### `ShoppingCart` 80 | 81 | - Restaurant ID: string 82 | - Items: [MenuItem, number][] 83 | - Subtotal: number 84 | 85 | ## Class Diagram 86 | 87 | ![Class Diagram](../assets/class-diagram.png) 88 | -------------------------------------------------------------------------------- /exercise-solutions/requirements-final.md: -------------------------------------------------------------------------------- 1 | # Architectural Requirements 2 | 3 | This is a living document with the architectural requirements of FullSnack's new customer-facing web application. 4 | 5 | For more information, check out the [Project Spec](./project-spec.md). 6 | 7 | ## Business Goals 8 | 9 | | Stakeholder | Goal | Context | 10 | | --------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | 11 | | Julio (CEO) | Increase number of customer orders by 100% in one year | As a new player in the market, FullSnack needs to attract new customers with their exciting new app. | 12 | | Megan (VP of Engineering) | Improve team velocity and cycle time by 25% | The new architecture should allow developers to ship features faster without compromising quality. | 13 | | Lauren (Frontend Developer) | Ship code to production confidently, without fear of breaking her teammate's features | The current big ball of mud architecture makes it hard to visualize the impact of a code change. | 14 | | Maxi (Customer Persona) | Order delicious food from his phone or computer and have it delivered as quickly as possible | Maxi is hungry and wants to eat a taco plate right now. | 15 | 16 | ## Contraints 17 | 18 | | Constraint | Context | 19 | | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | 20 | | [Technical] Must be deployed on AWS infrastructure | Our DevOps team only provides support and monitoring for AWS services. | 21 | | [Technical] Must be responsive and fully functional on mobile devices | Over half of our traffic comes from mobile devices and our native mobile application won't be ready to launch for at least 6 months. | 22 | | [Business] Must ship to production by November 2024 (4 months from now) | FullSnack is planning a massive marketing launch in November and this product is a key component of the marketing strategy. | 23 | 24 | ## Quality Attributes 25 | 26 | | Quality Attribute | Scenario | Priority | 27 | | ----------------- | ------------------------------------------------------------------------------------------------------------- | -------- | 28 | | Performance | A user on a mobile device with a 4G connection can load the app in 5 seconds or less. | High | 29 | | Scalability | The codebase should be modularized to allow and increasing number of frontend developers to work in parallel. | High | 30 | | Accessibility | The app should comply with WCAG 2.2 accessibility standards. | Medium | 31 | | Performance | Real-time updates should be broadcast to all listening clients within 15 seconds. | Low | 32 | | Deployability | Code changes should be deployed to production within 10 minutes of starting a release. | Low | 33 | 34 | ## Influential Functional Requirements 35 | 36 | - Customers can browse the app without being authenticated. 37 | - Customers can add food items to a shopping cart (with or without authentication). 38 | - We won't be able to assume a logged in customer at all times, so we might need to come up with the concept of a "visitor" customer to keep track of their actions (like adding items to the shopping cart). 39 | - Follow-up question: Do we need to persist the contents of the shopping cart for authenticated users? 40 | - Customers can search for restaurants by name. 41 | - Customers can search for restaurants by type of food. 42 | - Does search has an auto-complete UI? If so, do we have an API endpoint for the auto-complete feature? 43 | - After placing an order, customers can see a real-time tracker of their order status. 44 | - Once an order is out for delivery, customers can see a real-time map showing the driver's current location. 45 | - We'll need to connect to the web sockets server to show the real-time tracker and map. 46 | - Follow-up question: Are there any other features that need real-time functionality? 47 | - Customers can view ratings and reviews from other users. 48 | - Fetching reviews should not block the rendering of the restaurant page. 49 | 50 | ## Other Influencers 51 | 52 | - Currently, the frontend team is a single team of 4 developers, but this is expected to change as the number of developers is expected to triple in size over the next year. 53 | - Every frontend developer on the team has experience working with React and Next.js, and some of them are also comfortable working with Vue.js and Laravel. 54 | - Not everyone on the team is comfortable working with TypeScript. 55 | -------------------------------------------------------------------------------- /exercise-solutions/sequence-diagram-2.md: -------------------------------------------------------------------------------- 1 | # Real-Time Order Status Sequence 2 | 3 | ## Description 4 | 5 | When a customer places an order, the web app makes a request to the Core API which creates the order and returns a channel id. The web app then uses this channel ID to subscribe to the web sockets server, which emits real-time events when the order status changes. If the connection with the web socket server drops at any point, the web app will start polling Core API with the latest order status. 6 | 7 | ```mermaid 8 | sequenceDiagram 9 | title Real-Time Order Status Sequence 10 | participant Customer 11 | participant Web App 12 | participant Core API 13 | participant Web Sockets Server 14 | 15 | Customer->>Web App: Place order 16 | Web App->>Core API: Send order request 17 | Core API-->>Web App: Return channel id 18 | Web App->>Web Sockets Server: Register using channel id 19 | loop Real-Time 20 | Web Sockets Server-->>Web App: Emit real time event 21 | Web App-->>Customer: Receive real-time update 22 | end 23 | Web Sockets Server--xWeb App: Connection fails 24 | loop Long Polling 25 | Web App->>Core API: Get order status 26 | Core API-->>Web App: Order status 27 | Web App-->>Customer: Receive order update 28 | end 29 | ``` 30 | 31 | ## Mermaid.Live URL 32 | 33 | https://mermaid.live/edit#pako:eNp9U12L2zAQ_CtCz_mSnNixHw6O61EKhQuXQqHkRZEVW5wsufI6XBry37uKneaT5snZnZmdWUl7Kl2uaEYb9btVVqovWhReVCtL8AcajCLvSpjhD10p8uZz5ckSBLQNWfaMDloLD1rqWlggL20DrlL-vvNTrclzXT-gOK_I8-LbY8rSyQ8FYaTfBtkOdRozfHrqdTOyMEIq4oLPDtR3EHMakaGMzTsM8SFEA71gjxheKr4raL0lshTWKkN0fqt7bzCQCt0A6reNtsUd2ThXn9fa1U6i11JXVl4rDehYGDwYPA21VRauycFRiNpvJhiRSm_VkTU8sto6F9DPxD2c09wO_vw398WhewnaWbIR2jQXIb47jLdwxmDMeyuXS_-qoN95c7w_Z_TDtb89hP43Y6d-k48OKIIqoXO85PtQXlEoFW6dZviZC_-xoit7QJxowS13VtIMfKsGtFPqH8R18TXX4DzNNsI0WDRO4Gia7Sns6vCawumjonR2o4tQb73BcglQN9l4HNqjQkPZrkfSVeNG5yVe-XKbxuOYx3PBIxUnkZhFUS7XLJ1v-JRt8mTCuKCHw4DiywiqnzRjLBqlc57OknjK0gmfpQO6o9mQs1HE49mcpVEcRSyKEqT9cQ6DsBFnc87jSTJjCZ_y6VHv17HXB_KuLcr-3-Evcl9UFQ 34 | 35 | ![Sequence Diagram](./sequence-diagram-2.png) 36 | -------------------------------------------------------------------------------- /exercise-solutions/sequence-diagram-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/exercise-solutions/sequence-diagram-2.png -------------------------------------------------------------------------------- /slides/1.2 Course Overview.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/slides/1.2 Course Overview.pdf -------------------------------------------------------------------------------- /slides/1.3 What is Software Architecture.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/slides/1.3 What is Software Architecture.pdf -------------------------------------------------------------------------------- /slides/1.4 What is Frontend Architecture.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/slides/1.4 What is Frontend Architecture.pdf -------------------------------------------------------------------------------- /slides/1.5 Architecture vs Software Design.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/slides/1.5 Architecture vs Software Design.pdf -------------------------------------------------------------------------------- /slides/1.6 The Frontend Architect Role.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/slides/1.6 The Frontend Architect Role.pdf -------------------------------------------------------------------------------- /slides/2.1 Before We Start.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/slides/2.1 Before We Start.pdf -------------------------------------------------------------------------------- /slides/2.10 Architectural Decisions.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/slides/2.10 Architectural Decisions.pdf -------------------------------------------------------------------------------- /slides/2.3 The C4 Model.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/slides/2.3 The C4 Model.pdf -------------------------------------------------------------------------------- /slides/2.4 Exercise 1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/slides/2.4 Exercise 1.pdf -------------------------------------------------------------------------------- /slides/2.6 Architectural Drivers.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/slides/2.6 Architectural Drivers.pdf -------------------------------------------------------------------------------- /slides/3.10 Design Docs.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/slides/3.10 Design Docs.pdf -------------------------------------------------------------------------------- /slides/3.2 Entities, Modules, and Components.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/slides/3.2 Entities, Modules, and Components.pdf -------------------------------------------------------------------------------- /slides/3.3 Domain Modeling.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/slides/3.3 Domain Modeling.pdf -------------------------------------------------------------------------------- /slides/3.6 Breaking Things Down.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Charca/frontend-architecture-workshop/ed56b26271a64211ed629cb4af610be9602bd0ff/slides/3.6 Breaking Things Down.pdf --------------------------------------------------------------------------------