2023/09/12
- web system design refers to planning the web based software to meet specific requirements
- design phase is critical to the software dev lifecycle and lays foundation for building a functional, scalable, and maintainable web application
- whenever we design a system it's not necessary that all designs be similar e.g. requirements will be different
terms:
- requirements analysis
→ initial conversation about what is needed and why
- architecture design
→ deciding how many servers.. how users will connect... nitty gritty physical stuff
- UI design
→ how things will look at the presentation level
- backend dev
- frontend dev
- database design
- data management
→ how data will be stored, backups, recovery strategies...
- authentication and authorization
→ sign in handling etc
→ making sure siteo nly accessible to legitimate users
- security considerations
→ which security protocols are necessary
→ certificates, https..
- performance optimization
→ reducing delay, increasing efficiency etc
- testing and QA
- scalability and deployment
→ how big is your product.. how many users
→ horizontal and vertical scaling:
⇒ horizontal - increasing number of servers based on the workload
⇒ vertical - increasing the capacity of the servers
- monitoring and analytics
→ keeping an eye on performance metrics
- documentation
- deployment and maintenance
What is a load balancer?
When load is reached, it will distribute the load across all the servers so no single one is overloaded
Cache:
Browser will save copies of data instead of repeatedly requesting source
Middleware also can have caches
Types of Architectures
Modular Design
- its important to balance the flexibility of modular design with the performance demands of the real application
- 2 problems that arise with modular design:
→ cohesion : how much relevant functions are separated into their own modules
→ coupling : how much modules depend on one another
→ coupling should be low in a good design
→ cohesion should be high
Service oriented architecture
Tiered architecture design
- modular design approach
- divide project into layers/tiers, each responsible for specific functions/interactions
- enhances modularity, maintainability, scalability and flexibility
- The more modules in the system, the more restrictions on functionality
- reusability is a big reason for modular architectures
- Tiers:
→ Client/UI/Presentation tier
⇒ topmost layer, responsible for handling user interaction and displaying information to users
⇒ Includes UI, webpages, components for rendering data
⇒ This tier communicates with application tier to retrieve and send data
⇒ in web applications, this tier often runs on clients devices e.g. web browser
→ Application logic/ business layer
⇒ contians core business logic of the application
⇒ business logic: the actual purpose of the website, what it is actually doing.
⇒ handles user requests, enforces business rules, orchestrates data interactions, and controls application
⇒ typucally hosted on application servers
⇒ processes commands, makes logical decisions and evaluations.
⇒ moves processes between the two other layers
→ Resource manager/data tier
⇒ stores the applications data
⇒ stored in the application's server
⇒ information is stored and retrieved from a database or file system
⇒ infomration is passed back to the logic tier for processing, and the result of that would be passed to the user
⇒ data is stored, retrieved and manipulated in this layer based on requests from the application tier
⇒ this tier ensures data consistency, durability, and integrity
- Question: what if you're adding a + b. but then the user says they want multiplication ability added to the software. Which layer would the change take place?
→ Logic/application tier
1-Tiered/Monolithic architectire
- everything is jammed into one layer
- a fully centralized architecture where the client, application logic, and resource manager are built as a monolithic entity
- these are considered “dumb” terminals
→ browser doesnt do anything except display the data, doesnt do any cacheing
- everything is so tightly packed that making changes causes problems
2-Tiered architecture
- aka client-server architecture
- client tier: front end component of application that user interacts with
- server tier: back end is responsible for processing requests from clients, doing business logic, and managing data
As web systems evolved from a centralized architecture to a 2-tiered architecture, the concept of web services began to emerge
- Every web service is an API, but not every API is a web service
- APIs connect applications, web services connect machines
Wrappers:
- a design pattern or component that sits on top of an existing API, library, or system to provide a simplified or more user-friendly interface for interacting with it
- wrappers encapsulate the complexity of the underlying API or system, abstract away implementation details, and provide higher level, easier to use interface
- wrappers are often used to make APIs or systems more convenient, inmprove concistency and provide and intuitive API for developers
CONTINUED 2023/09/14 - 10:09
3-Tiered architecture
- client handles presentation layer
- application server handles application layer
- server handles the data layer
- take full advantage of of the modularity of the design
Question: What is middleware?
- Some 3-tier designs make use of middleware, the use depends on the context
- can say it's like a bridge between the client and application tier
- responsibilities include routing and managing requests from the presentation tier to the application tier and vice versa
- often handles tasks such as load balancing, authenticaiton, authorization, and session management
- web servers, api gateways, message brokers can be part of this tier.
Why is middleware added?
- request routing
- load balancing
- security
- caching
- data transformation and validation
→ input sanitization: process input data and remove characters so it cannot lead to attacks
- session management
- interoperability
- logging and monitoring
- scalability management
- 3 tier architecture introduced the concept of middleware
Middleware is not a complete system.
Question: which layer is responsible for executing business logic and application specific tasks?
- Application tier
N-Tiered architecture
- connecting several 3-tiered architectures together
- or: adding an additional layer in order to allow clients to access the system through a web server
Part 2:
HTTP Methods
- GET:
→ request data from a specific resource. does not change the state of the resource
- PUT
→ update or replace information on the resource. server replaces the existing resource with the new data
- POST
→ submit data to be processed by the resource. Can create new resources or perform actions that have side effects on th server like uploading files or submitting forms
- DELETE
→ request removal or deletion of a resource at a specific URL
- PATCH
→ apply partial modifications to a resource, unlike PUT, which will replace the whole resource
Microservice Architecture
- implmement everything in the form of microservices
- appilcation is divided into small, loosely coupled and independently deployable services, each responsble for specific business capabilities
- unlike traditional monolithic architectures where components are tightly integrated, microservices break an application into discrete, autonomous services that can be developed, deployed, and scaled independently
- Client apps connect to an API gateway, which interacts with the different microservices based on what activity the client wants.
- Each microservice has its own database - fully independent
- Microservices communicate with each other using API calls
- Message brokers communicate with the microservices...
Characteristics:
- componentization via services
- organized around business capabilities
- decentralized data management
- design for failure
- polyglot architecture
→ in a single project you use different tools, frameworks, database types ..?
Key benefits:
- code can be updated more easily, new features can be added without messing with the whole thing
- other stuff i didnt write down
Serverless Architecture
- server stuff is handled by someone else
- often referred to as Fuction as a Service
- allows developers to build and run applications without needing to manage server infrasrtucture
- cloud provider dynamically manages the allocation of server resources, scaling up or down based on the application's needs
- abstracts away many of the traditional server management tasks. allowing developers to focus solely on writing code for their application's functions
- Example:
→ an image processing service using AWS Lambda, where image uploads trigger serverless functions to resize, compress, and store images without managing servers.
- Real life applications:
→ scalable on-demand media delivery by Netflix
→ rapid application development and deployment by autodesk
→ dynamic and responsive chatbots by Slack and more..
Fundamental concepts:
- invocation:
→ a single function execution
- Duration:
→ time it takes for serverless function to execute
- cold start:
→ first time you run a lambda function it will take time.
→ latency that occurs when a function is triggered for the first time or after a period of inactivity
- concurrency limit:
→ number of function instances that can run simultaneously in one region, as determined by the cloud provider. a function will be throttled if ti exceeds this limit
- timeout:
→ the amount of time tat a cloud provider allows a function to run before terminating it. most providers set a default min and max timeout.
Benefits:
- cost
→ charged based on use so when your server use is low you will save money
- scalability
→ server providers can dynamically allocate your resources
- productivity
Challenges:
- loss of control
→ less customizability over the serverside
- security
→ the machines are used by many people which introduces risks
- performance impact
- testing
- vendor lock-in
→ compatibility issues arise if you try to switch between service providers
Service world in the WWW Index