contents: add more system design content
This commit is contained in:
Yangshun
parent
8e6e35241a
commit
64d3836399
|
|
@ -0,0 +1,77 @@
|
|||
---
|
||||
title: Front End System Design - Applications
|
||||
slug: front-end-system-design/applications
|
||||
sidebar_label: Applications
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
- News feed
|
||||
- Video watching website
|
||||
- Chat application
|
||||
|
||||
## Framework
|
||||
|
||||
1. Requirements clarifications/alignment
|
||||
1. Architecture
|
||||
1. Data Model Design
|
||||
1. API Design
|
||||
1. Extra Stuff
|
||||
- User Experience
|
||||
- Performance
|
||||
- Accessibility (a11y)
|
||||
- Internationalization (i18n)
|
||||
- Security
|
||||
- Multi-device support
|
||||
|
||||
### Requirements clarification
|
||||
|
||||
Every system design interview should start with clarifying requirements about the question, which is usually left vague intentionally. Some considerations:
|
||||
|
||||
- What devices should the system support? Desktop web, mobile web, etc
|
||||
- What's the primary device that users will access the system on?
|
||||
- Which browsers should we support?
|
||||
- Do we need to support internationalization?
|
||||
- Does the app need to work offline?
|
||||
|
||||
### Architecture
|
||||
|
||||
Architecture for front end interviews are typically focused on the client-side architecture, and not on large scale distributed systems where databases, load balancers and servers are involved.
|
||||
|
||||
For applications, common architectures include Model-View-Controller, Model-View-ViewModel, Flux, N-tier (where data tier is on the client) etc.
|
||||
|
||||
### Data model
|
||||
|
||||
Client app state.
|
||||
|
||||
### API design
|
||||
|
||||
API design for applications will refer to the HTTP/network API parameters and the shape of the responses.
|
||||
|
||||
### Extra stuff
|
||||
|
||||
TODO
|
||||
|
||||
<!-- #### User experience
|
||||
|
||||
#### Performance
|
||||
|
||||
#### Accessibility (a11y)
|
||||
|
||||
#### Internationalization (i18n)
|
||||
|
||||
#### Security
|
||||
|
||||
#### Multi-device support -->
|
||||
|
||||
## Helpful articles
|
||||
|
||||
Many companies blog about their technical challenges in the front end domain and these are great content to learn more about designing front end systems.
|
||||
|
||||
- [Building the Google Photos Web UI](https://medium.com/google-design/google-photos-45b714dfbed1)
|
||||
- [Twitter Lite and High Performance React Progressive Web Apps at Scale](https://medium.com/@paularmstrong/twitter-lite-and-high-performance-react-progressive-web-apps-at-scale-d28a00e780a3)
|
||||
- [A Netflix Web Performance Case Study](https://medium.com/dev-channel/a-netflix-web-performance-case-study-c0bcde26a9d9)
|
||||
- [A Tinder Progressive Web App Performance Case Study](https://medium.com/@addyosmani/a-tinder-progressive-web-app-performance-case-study-78919d98ece0)
|
||||
- [A Pinterest Progressive Web App Performance Case Study](https://medium.com/dev-channel/a-pinterest-progressive-web-app-performance-case-study-3bd6ed2e6154)
|
||||
- [A React And Preact Progressive Web App Performance Case Study: Treebo](https://medium.com/dev-channel/treebo-a-react-and-preact-progressive-web-app-performance-case-study-5e4f450d5299)
|
||||
- [Rebuilding our tech stack for the new Facebook.com](https://engineering.fb.com/2020/05/08/web/facebook-redesign/)
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
---
|
||||
title: Front End System Design - UI Components
|
||||
slug: front-end-system-design/ui-components
|
||||
sidebar_label: UI Components
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
- Photo gallery
|
||||
- Selector
|
||||
|
||||
## Framework
|
||||
|
||||
1. Requirements clarifications/alignment
|
||||
1. Architecture
|
||||
1. Data Model Design
|
||||
1. API Design
|
||||
1. Extra Stuff
|
||||
- Multi-device support
|
||||
- User Experience
|
||||
- Performance
|
||||
- Accessibility
|
||||
- i18n
|
||||
- Security
|
||||
|
||||
### Requirements clarification
|
||||
|
||||
Every system design interview should start with clarifying requirements about the question, which is usually left vague intentionally. Components have well-defined scope and not try to do too many things.
|
||||
|
||||
Some considerations:
|
||||
|
||||
- What devices should the system support? Desktop web, mobile web, etc
|
||||
- What's the primary device that users will access the system on?
|
||||
- Which browsers should we support?
|
||||
- Do we need to support internationalization?
|
||||
- How much styling customization do we want to allow?
|
||||
|
||||
### Architecture
|
||||
|
||||
Architecture for front end interviews are typically focused on the client-side architecture, and not on large scale distributed systems where databases, load balancers and servers are involved.
|
||||
|
||||
For components, list down the various sub-components that will exist within it, what data is being passed among each component (e.g. in a Photo Gallery, there are the Image, Thumbnail, Paginator, etc sub-components). If you have a whiteboard/online drawing tool, it would also be helpful to draw diagrams to illustrate the entities and their relationships.
|
||||
|
||||
### Data model
|
||||
|
||||
Data model for components will refer to the component state. The concept of state should be familiar to most front end developers who have used front end UI libraries/frameworks such as React, Angular, Vue, Svelte, etc. In every of these libraries/frameworks, state is a common concept.
|
||||
|
||||
Deciding what data to put in state is essential to doing well for this portion. Few factors to consider when deciding what goes into component state:
|
||||
|
||||
- State is allowed to change over time during the lifecycle of the component, typically as a result of user interactions
|
||||
- Each component has its own state which allows _multiple instances_ of the component to coexist on a single page. The state of a component instance should not affect the state of another instance
|
||||
|
||||
### API design
|
||||
|
||||
- Configuration options for the component (props in React)
|
||||
|
||||
### Extra stuff
|
||||
|
||||
<!-- #### User experience
|
||||
|
||||
#### Performance
|
||||
|
||||
#### Accessibility (a11y)
|
||||
|
||||
#### Internationalization (i18n)
|
||||
|
||||
#### Security
|
||||
|
||||
#### Multi-device support -->
|
||||
|
||||
## Helpful articles
|
||||
|
||||
- [Buillding an accessible autocomplete control](https://adamsilver.io/blog/building-an-accessible-autocomplete-control/)
|
||||
|
|
@ -1,42 +1,42 @@
|
|||
---
|
||||
title: Front End System Design
|
||||
sidebar_label: System Design
|
||||
title: Front End System Design Overview
|
||||
sidebar_label: Overview
|
||||
---
|
||||
|
||||
"System" here typically refers to front end systems, which are different from the typical distributed system design questions for Software Engineering interviews. The question topic asked is quite similar to the ["Build User Interface" format](./build-user-interfaces.md) but with more focus on architecture and design. There's a significant amount of overlap between that and this - you will likely need to do some design in that and also do some coding here to illustrate your ideas/app state format.
|
||||
There are shockingly few front end system design resources out there, probably because there's a lower demand and supply for front end engineer candidates.
|
||||
|
||||
"System" here typically refers to front end systems, which are quite different from the typical distributed system design questions for Software Engineering interviews. The question topic asked is quite similar to the ["Build User Interface" format](./build-user-interfaces.md) but with more focus on architecture and design. There's a significant amount of overlap between that and this - you will likely need to do some design in that and also do some coding here to illustrate your ideas/app state format.
|
||||
|
||||
The difference between this section and the ["Build User Interface" format](./build-user-interfaces.md) is that the questions here are usually larger. If the session is only half an hour, candidates are expected to talk about the design tradeoffs, possible implementations, instead of coding it out. Because this format of questions involve multiple components and knowledge across the web stack, candidates usually do not have to go very deep into the lower-level details and can keep the discussion at a higher level.
|
||||
|
||||
Many of the topics mentioned in the ["Build User Interface" format](./build-user-interfaces.md) are also relevant for front end system design - API design, scalability, performance, user experience, i18n, accessibility, security. Candidates should take the initiative and bring these topics up and lead the discussion with the interviewer. The more advanced topics such as performance, accessibility and i18n are what differentiates senior candidates from the junior ones.
|
||||
|
||||
The two main kinds of front end system design interviews are UI components and applications.
|
||||
|
||||
## Examples
|
||||
|
||||
- UI Components
|
||||
- Photo gallery
|
||||
- Selector
|
||||
- Applications
|
||||
- News feed
|
||||
- Video watching website
|
||||
- Chat application
|
||||
|
||||
## Structure
|
||||
|
||||
System design interview questions tend to be open ended and vague, leaving you with lots of room to explore. If the interviewer tells you which specific areas to focus on, that's great! Otherwise, here's a framework you can consider for front end interviews, which is also helpful when working on new front end projects at work.
|
||||
|
||||
1. Requirements clarifications/alignment
|
||||
1. Components Architecture
|
||||
1. API Design
|
||||
1. Architecture
|
||||
1. Data Model Design
|
||||
1. API Design
|
||||
1. Extra Stuff
|
||||
- Multi-device support
|
||||
- User Experience
|
||||
- Performance
|
||||
- Accessibility
|
||||
- i18n
|
||||
- Security
|
||||
|
||||
## Examples
|
||||
|
||||
- Photo gallery
|
||||
- Chat application
|
||||
- News feed
|
||||
- Video watching application
|
||||
|
||||
## Helpful Articles
|
||||
|
||||
Many companies blog about their technical challenges in the front end domain and these are great content to learn more about designing front end systems.
|
||||
|
||||
- [Building the Google Photos Web UI](https://medium.com/google-design/google-photos-45b714dfbed1)
|
||||
- [Twitter Lite and High Performance React Progressive Web Apps at Scale](https://medium.com/@paularmstrong/twitter-lite-and-high-performance-react-progressive-web-apps-at-scale-d28a00e780a3)
|
||||
- [A Netflix Web Performance Case Study](https://medium.com/dev-channel/a-netflix-web-performance-case-study-c0bcde26a9d9)
|
||||
- [A Tinder Progressive Web App Performance Case Study](https://medium.com/@addyosmani/a-tinder-progressive-web-app-performance-case-study-78919d98ece0)
|
||||
- [A Pinterest Progressive Web App Performance Case Study](https://medium.com/dev-channel/a-pinterest-progressive-web-app-performance-case-study-3bd6ed2e6154)
|
||||
- [A React And Preact Progressive Web App Performance Case Study: Treebo](https://medium.com/dev-channel/treebo-a-react-and-preact-progressive-web-app-performance-case-study-5e4f450d5299)
|
||||
- [Rebuilding our tech stack for the new Facebook.com](https://engineering.fb.com/2020/05/08/web/facebook-redesign/)
|
||||
How to approach system design questions for applications and UI components can differ significantly, and we'll go through them in more detail in subsequent pages.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,15 @@ module.exports = {
|
|||
label: 'Coding Round',
|
||||
items: ['utility-function', 'build-user-interfaces', 'algorithms'],
|
||||
},
|
||||
'front-end-system-design',
|
||||
{
|
||||
type: 'category',
|
||||
label: 'System Design',
|
||||
items: [
|
||||
'front-end-system-design',
|
||||
'front-end-system-design-ui-components',
|
||||
'front-end-system-design-applications',
|
||||
],
|
||||
},
|
||||
'behavioral',
|
||||
],
|
||||
};
|
||||
|
|
|
|||
Loading…
Reference in New Issue