Application Development
Websites
A website is a collection of interlinked web pages(written in HTML/CSS/JavaScript) hosted on a server and accessible via the internet using a web browser. It typically serves to display static or semi-static/dynamic content.
Key Features:
Same for All Users: No personalized views (no login-specific data).
Accessible Anywhere: Works on any device with a browser and internet.
Hosting: Stored on servers (e.g., AWS, GoDaddy, Bluehost).
Types of Content:
Static Websites: A website that delivers the same pre-built content to every user. The HTML files are fixed and don’t change unless manually updated by a developer.
Use Cases for Static Websites:
Portfolio Sites (e.g., for a designer/developer/photographer)
Personal Blogs (e.g., travel blog with posts and images).
Informational Sites: Non-profit or public education sites (e.g., NASA, WHO).
Small Business Sites: Display services, contact info, and business hours.
Landing Pages: Marketing one-pagers used in ad campaigns or product launches.
Advantages:
Low Development Cost: Can be created using platforms like Wix, Squarespace, or pure HTML/CSS.
Low Maintenance: Minimal updates required once deployed.
Quick to Deploy: Easily hosted and fast-loading.
Ideal for Basic Needs: Great for businesses or individuals needing an online presence without complexity.
Disadvantages:
Limited Interactivity and Personalization: Static websites lack advanced features or dynamic user engagement.
No Offline Access: Requires internet to view.
Unsuitable for Complex or Frequently Updated Needs: Not ideal for businesses that require frequent updates, real-time data, or complex functionalities.
Semi-Dynamic Website: A website where content changes occasionally, but not based on user input - it’s updated by an admin or on a schedule.
Example: News site updated daily..
We make a blog with WordPress.
Visitors only read what we wrote.
Content updates only when we post something new.
This is semi-dynamic, not dynamic.
The user doesn’t interact. The content doesn't respond to them.
Dynamic Websites: A dynamic website is content-driven because its main purpose is to show information that can change depending on what the user does.
Content= Text, images, videos, or any other data on a webpage.
The content on the page changes instantly based on user actions or input, like typing, clicking buttons, or logging in.
Primary Goal: A dynamic website mainly delivers content that changes based on conditions, like user data or database info.
Example: Amazon Product Page
Before: We open Amazon's website and search for "laptop."
What happens: The products displayed (like images, prices, and descriptions) change dynamically based on your search.
It's Content-Driven because::
The content (products) changes depending on your search query.
We’re interacting with the content by searching, filtering, or clicking, but you're not performing complex tasks like editing or creating new data.
Dynamic means:
We search - Results change.
We log in - We see your own profile.
We click a filter - The list updates.
It's called "dynamic" because the page updates or customizes content while you're browsing.
Web Applications
A web application is a software application stored on remote servers, delivered via the internet, and accessed through a browser. Unlike static websites, web applications are highly interactive where users don’t just read or watch — they do things , like create, edit, upload, chat, or collaborate.
Primary Goal: A web app is more about functionality, it's designed for users to interact and perform tasks.
Focus: It’s action-driven, meaning we can use it to do things like filling out forms, sending
Key Features:
User-Specific Views (changes based on login).
Dynamic & Interactive: Updates in real time based on user input or backend logic.
Cross-Platform: Works on any device with a browser.
Backend Integration (uses Node.js, Python, Java, PHP).
User Accounts: Offers personalized views, dashboards, and saved preferences.
Examples:
E-Commerce: Amazon, Flipkart – shopping carts, orders, user accounts.
Social Media: Facebook, Twitter – posts, messages, likes.
SaaS Tools: Google Docs, Trello – real-time editing, collaboration.
EdTech: Coursera, Khan Academy – courses, quizzes, progress tracking.
Advantages Over Static Websites:
Enhanced User Experience: Real-time updates and interactivity provide a more engaging and dynamic experience for users.
Business-Centric Features: Supports advanced functionalities such as secure transactions, user accounts, and role-based access controls.
Scalability for Advanced Needs: Easily scalable to include features like dashboards, APIs, and other complex functionalities to meet evolving business requirements.
Cross-platform: Works on any browser, across devices.
Disadvantages:
More Complex Development: Requires full stack development (frontend + backend).
Higher Hosting Requirements: Needs database and application server.
Ongoing Maintenance & Security: Frequent updates, performance monitoring, and vulnerability patching.
Overlapping Characteristics: Some platforms can be both a website and a web application. For example:
Amazon: Its homepage may look like a website, but once we log in, you’re interacting with a full-fledged web application.
YouTube:
As a Website: Users can browse and watch videos, read video descriptions, and explore the site.
It's mostly content consumption (viewing), with no complex user actions required.
As a Web Application: When we log in, we can upload videos, comment on videos, manage playlists, like/dislike, and subscribe to channels.
These interactions require server-side processing and real-time updates, making YouTube a web application in these cases.
Types of Mobile Applications
Native Apps
Native apps are specifically designed and developed for a particular mobile platform (Android or iOS) using platform-specific languages and tools. Examples:
Android: Developed using Java or Kotlin with Android Studio.
iOS: Developed using Swift or Objective-C with Xcode.
Key Features:
Platform Optimization: Offers optimal performance and speed as they are compiled directly into machine code for the specific platform.
Access to Hardware and APIs: Full access to device features like GPS, camera, microphone, sensors, and more.
App Store Distribution: Installed via platform-specific app stores (Google Play, Apple App Store).
Offline Functionality: Can work without an internet connection, offering uninterrupted usage.
Disadvantages:
Higher Cost and Development Time: Developing separate apps for iOS and Android requires more resources, time, and expertise.
Lengthy App Store Approval Process:Getting apps approved by platforms like Google Play or the Apple App Store can take time.
Cross platform apps
Cross-platform apps allow us to write the code once and run it on multiple platforms (iOS and Android). Frameworks like React Native and Flutter are commonly used.
React Native uses JavaScript to write code that is rendered using native UI components. Key Features of React Native:
Native UI Components: React Native doesn’t use WebView to render the app, which means it doesn’t rely on a browser engine (like hybrid apps do). Instead, it uses native components for rendering the UI.
For example: A <Text> component in React Native on Android is rendered as a TextView.On iOS, it’s rendered as a UILabel.
JavaScript Bridge: React Native uses a JavaScript Bridge to communicate between the JavaScript code and the native components.
For example: When we interact with a button in the app (e.g., using onPress), React Native sends that interaction to the native platform (Android or iOS) via the bridge to trigger the corresponding native functionality (e.g., handle the button click).
Access to Native APIs: React Native provides direct access to native APIs via built-in modules and third-party libraries. This enables React Native apps to use native device features like the camera, GPS, and accelerometer.
No WebView by Default: React Native does not rely on WebView (which would essentially display a webpage inside the app). This is what separates React Native from hybrid apps, which often use WebView to display web content.
Exception: If we need to display a web page inside your app (like showing a website), React Native can use WebView, but that’s an optional feature.
Flutter uses Dart language and its own custom rendering engine to build cross-platform apps. Key Features of Flutter:
Faster Performance: Since Flutter avoids platform-specific UI components and uses its own rendering engine, it can deliver better performance, often faster than React Native.
Custom Rendering Engine: Flutter uses the Skia rendering engine to render UI elements directly to the screen. It doesn't rely on native platform components (e.g., Android’s TextView or iOS’s UILabel). This means Flutter draws everything (buttons, text, etc.) from scratch, providing more control over the design.
No JavaScript Bridge: Unlike React Native, Flutter doesn’t use a bridge to communicate between the app code and the native platform. This direct communication between Dart code and native components reduces latency and improves speed.
Hybrid Apps
Hybrid apps combine features of both native apps and web apps. They are essentially web apps wrapped in a native container, using tools like Apache Cordova or Ionic.
Key Features:
Web Technologies: Built using standard web technologies like HTML, CSS, and JavaScript, then wrapped in a native shell (WebView) to give the appearance and behavior of a native app.
App Store Deployment: Deployed through app stores (Google Play, Apple App Store) just like native apps.
Access to Native Features: Can access some native device features (e.g., camera, GPS) using plugins.
Lower Performance: Performance tends to be lower than native or cross-platform apps because the entire app runs inside a WebView, which is essentially a browser embedded within a native app.
Progressive Web Applications (PWAs)
PWAs are modern web apps that behave like native apps directly in the browser, using service workers, web app manifests, and responsive design.
Key Features:
App-Like Behavior: Can be installed on the home screen like native apps.
Offline Support, Push Notifications, & Background Sync: Leverage service workers to offer offline functionality, push notifications, and background data syncing.
Installable from Browser: Can be installed directly from the browser without needing app store deployment.
Installation is supported by the Web App Manifest and browser compatibility.
Access to Limited Native APIs: Can access certain native APIs like geolocation, camera, and file storage (with some limitations).
Cross-Platform: Designed using responsive design principles, making it accessible across devices.
Key Components
Service Worker: A background JavaScript file that intercepts network requests and manages caching, offline support, and background tasks.
Offline Flow: Checks cache, serves cached data or a fallback page.
Online Flow: Fetches from the network and updates the cache.
Web App Manifest: Provides metadata about the app, including the name, icons, theme color, and installation behavior.
Added via a manifest.json file.
HTTPS: PWAs must be served over HTTPS to ensure secure communication.
Cloud-Native & Cloud-Enabled Applications
Cloud-Enabled Applications: "Lift-and-Shift"
Applications originally built for on-premises environments and later adapted to run in the cloud, without being fully optimized for cloud-native features like microservices, serverless computing, or containerization.
Characteristics:
Originally On-Premises: Designed for traditional data centers.
Migrated, Not Modernized: Deployed to the cloud using Infrastructure as a Service (IaaS), but without re-architecting for the cloud.
Uses Virtual Machines (VMs): Runs on AWS EC2, Azure VMs, or Google Compute Engine.
Limited Scalability: Scaling often requires manual intervention or custom scripts; lacks auto-scaling mechanisms.
Monolithic or Partially Modular: May have tightly coupled components.
Cloud as Infrastructure Provider: Uses cloud only for hosting, not cloud-native benefits like serverless or containers.
Slow Release Cycles: Often follow traditional deployment practices (manual testing, longer release cycles).
Example: A legacy CRM system that was originally run on a company’s private data center but is moved to AWS EC2 and uses AWS RDS for the database, without adopting cloud-native features.
Limitation: While it runs in the cloud, it doesn't leverage cloud-native advantages like auto-scaling, fault tolerance, CI/CD pipelines, microservices, serverless, or containerization.
Cloud-Native Applications: – "Built for the Cloud"
These applications are designed and built from scratch to run exclusively in cloud environments, using cloud-first principles.
Key Features:
Built for Cloud: Designed for public, private, or hybrid cloud platforms from the ground up.
Microservices Architecture: The application is decomposed into independent, loosely coupled services.
Containerized Deployment: Uses Docker, Kubernetes, or similar for packaging and orchestration.
Serverless Capabilities: Leverages AWS Lambda, Azure Functions, etc., to minimize infrastructure concerns.
Auto-Scalable: Dynamically scales services based on real-time traffic and usage (horizontal scaling).
Platform-Agnostic: Can be deployed across cloud providers with minimal effort.
Resilient & Fault-Tolerant: Designed to be self-healing, distributed, and highly available.
CI/CD Integration: Follows DevOps practices with automated pipelines for fast and reliable releases.
API-Driven Communication: Uses RESTful APIs, GraphQL, or gRPC for interaction between services.
Examples:
Netflix: Uses microservices, Kubernetes, and serverless to scale globally, ensuring high availability during traffic spikes..
Serverless Architecture
A serverless architecture allows developers to focus solely on writing and deploying business logic, while the cloud provider handles server provisioning, scaling, infrastructure management, and maintenance.
Key Features:
Event-Driven Execution: Functions are triggered by specific events such as: HTTP requests, File uploads (e.g., to S3), Database changes, Scheduled tasks (cron jobs)
Pay-Per-Use Billing Model: Costs are based on the actual usage of resources, ensuring cost efficiency by charging only for the compute time consumed.
Automatic Scaling: Serverless platforms automatically scale up or down based on the number of incoming events or requests. No manual configuration needed.
No Server Management: Developers do not need to provision, patch, or scale servers, VMs, or containers.
Stateless & Short-Lived Execution: Serverless functions run independently and are typically stateless (but state can be stored in databases or object storage).
Faster Time to Market: Simplified deployments and focus on business logic result in rapid development and iteration.
Serverless Computing Models:
Function as a Service (FaaS): FaaS is a serverless computing model where developers write and deploy individual functions that execute in response to events. It eliminates the need for managing servers, infrastructure, or runtime environments.
Examples: AWS Lambda, Azure Functions, Google Cloud Functions
Backend as a Service (BaaS): BaaS offers pre-built backend features like authentication, databases, and storage that can be integrated directly into front-end apps.
Firebase Functions - Serverless functions for mobile & web apps.
AWS AppSync - Serverless GraphQL API for real-time data synchronization.
Working Flow of Serverless (Example Use Case): Processing an image upload from a user.
User uploads an image to Amazon S3.
S3 triggers a Lambda function via an event notification.
Lambda resizes or compresses the image.
The processed image is saved to a new S3 bucket or DynamoDB.
A notification (via SNS or Firebase) informs the user.
Core AWS Serverless Services:
AWS Lambda – Executes code in response to triggers.
AWS Fargate – Fargate brings the serverless model to containers. Instead of managing EC2 instances or Kubernetes clusters,We define the task, CPU, memory, container image, and Fargate handles the underlying infrastructure to run them.
Amazon API Gateway – Fully managed service to create, publish, maintain, monitor, and secure APIs that route requests to Lambda or other backend services.
Amazon DynamoDB – Serverless NoSQL database with low-latency performance.
Amazon Cognito – This service simplifies user identity and access management for your web and mobile applications. It handles:
User authentication and access control service supporting sign-up, sign-in, and access management, Integration with social identity providers
AWS App Runner – A fully managed service to deploy web apps and APIs from code repositories or container registries (like GitHub or ECR) without needing ECS, task definitions, or VPC config.
AWS Amplify Console – A CI/CD and hosting service for full-stack web and mobile apps.
Automatically build, test, and deploy your app (frontend + backend) whenever we push changes to GitHub, GitLab, or Bitbucket.
Amazon SNS & SQS: Pub/Sub messaging & queueing for async tasks.
SNS (Simple Notification Service): Pub/Sub messaging. Send a message to multiple subscribers at once.
Push-based → sends notifications (email, SMS, Lambda, HTTP)
SQS (Simple Queue Service): Message queue. Stores messages until a consumer (like Lambda or EC2) retrieves them.
One message → one consumer
Pull-based → consumer polls the queue
Ensures reliable delivery even if services are temporarily down
Amazon EventBridge: Event bus for decoupled microservices.
Advanced event bus for routing events between AWS services, SaaS apps, and custom applications.
Routes events based on rules and filters
Integrates with hundreds of AWS services
Useful for complex event-driven architectures
Preferred over SNS/SQS for fine-grained event handling
Example: When a file is uploaded to S3:
If the file type is .csv, trigger Lambda-A
If the file type is .jpg, trigger Lambda-B
Step Functions: This is a serverless orchestration service that lets us coordinate multiple AWS services into serverless workflows. We define your workflows as state machines, and Step Functions manages the execution, retries, and error handling.
S3: File storage with event triggers for other serverless services (like Lambda) (e.g., image resize).
AWS Serverless Web Application Architecture: A typical AWS serverless web application looks like this:
Frontend – Static content hosted on Amazon S3 and served via Amazon CloudFront.
API Layer – Amazon API Gateway routes client requests to AWS Lambda.
Business Logic – Implemented in AWS Lambda functions.
Database – Amazon DynamoDB (NoSQL) or Amazon Aurora Serverless (SQL).
Authentication – Amazon Cognito handles login, registration, token management, access control.
Event Processing – Uses Amazon EventBridge, SNS, and SQS for communication.
Monitoring & Debugging
AWS CloudWatch: A monitoring and logging service for AWS resources and custom applications.
Collects logs, metrics, events, and alarms
Helps we visualize app performance, identify issues, and trigger alerts
AWS X-Ray: for tracing and debugging.
Trace how a single user request flows through multiple services (e.g., API Gateway -> Lambda -> DynamoDB)
Limitations to Be Aware Of
Cold starts: Initial delay when a function runs after being idle
Execution limits: Short-lived processes (e.g., AWS Lambda max is 15 minutes)
Statelessness: Requires external storage for maintaining state
Complex debugging and monitoring in distributed setups
Vendor lock-in risks depending on cloud-specific services
Tools and Technologies
Frontend Development:
ReactJS, Angular, Vue.js: Popular frameworks for building dynamic, interactive UIs and single-page applications, enabling fast rendering and a seamless user experience.
Bootstrap, Tailwind CSS: Widely used CSS frameworks for creating responsive and mobile-friendly designs, ensuring consistency across various devices and screen sizes.
Bootstrap: Pre-built responsive components (buttons, grids).
Saves time with ready-made designs.
Tailwind CSS:
Utility-first CSS framework: Instead of writing custom CSS rules for every component, we apply predefined utility classes directly in your HTML.
No Predefined Components – Build custom designs with utility classes.
Backend Development:
Node.js, Express, Django, Spring Boot: Frameworks designed to create robust and scalable backend systems, supporting server-side logic, API development, and database integration.
Databases:
Relational Databases: MySQL and PostgreSQL are commonly used for structured data storage, supporting ACID compliance and complex queries.
NoSQL Databases: MongoDB and Cassandra are ideal for unstructured or semi-structured data, providing flexibility and scalability for large datasets.
Testing Tools:
Postman: A widely used platform for developing, testing, and documenting RESTful APIs with an intuitive interface and automation capabilities..
Selenium and Cypress: Automated testing tools for ensuring frontend functionality and end-to-end workflows operate correctly across browsers and devices.
Web Server and Application Server
Web Server: A web server is software or hardware that processes and delivers static content (HTML, CSS, JavaScript, images) to clients (browsers, mobile apps) over HTTP/HTTPS.
Functions of a Web Server
Serves static content like HTML, CSS, images, JavaScript.
Handles HTTP requests and responses.
Supports SSL/TLS encryption for secure browsing.
Can forward dynamic requests to an application server.
Popular Web Servers
Nginx: For Python (Django), Java (Tomcat), and Node.js, Nginx acts as a reverse proxy.
Example: Nginx forward requests to a Node.js application running on port 3000.
Apache HTTP Server: Apache has a built-in module called mod_php, which allows it to directly process PHP code inside the web server itself.
For languages like Python (Django), Java (Tomcat), and Node.js, Apache does not process the code directly. Instead, it uses the mod_proxy module to forward requests.
Microsoft IIS
LiteSpeed
Example: Nginx Serving Static Content:
server {listen 80;server_name example.com;root /var/www/html;location / {index index.html;}
}Nginx listens on port 80. Static files from /var/www/html (e.g., index.html) are served directly.
Application Server: Processes dynamic content by running backend code and interacting with databases.
Functions of an Application Server
Runs server-side programming languages (Java, PHP, Python, Node.js).
Processes business logic (authentication, database interactions, transactions).
Handles session management and API requests.
Often works with a web server to handle frontend requests.
Popular Application Servers
Node.js
Apache Tomcat (Java)
Django server (Python)
PHP-FPM (for PHP): Nginx cannot process PHP on its own, so it relies on PHP-FPM (FastCGI Process Manager).
Web Servers and Application Servers Together :
Client Request: User requests a web page.
Web Server Processes Request: If it's a static file, the web server delivers it directly.
Forwarding to Application Server: If it's dynamic, the web server forwards the request to the application server.
Application Server Handles Logic: Retrieves data, processes authentication, interacts with the database.
Response Sent Back to Client: Web server delivers the response generated by the application server.
A reverse proxy is a server that sits in front of backend servers and forwards client requests to them. Reverse Proxy is useful for:
Load Balancing: Distributes traffic across multiple servers.
Security: Hides backend servers from direct exposure to the internet.
Performance: Caches static files and reduces server load.
SSL Termination: Handles HTTPS encryption and decryption
Scale Cube
The Scale Cube is a scalability model that helps developers understand how to scale applications efficiently. The Scale Cube consists of three dimensions of scalability:
X-Axis Scaling (Horizontal Cloning): Cloning multiple instances of the application and placing them behind a load balancer.
Each instance runs the same code and handles the same types of requests.
Common in stateless applications and microservices.
Y-Axis Scaling: Service Partitioning / Functional Decomposition / Microservices
Break monolith application into smaller, independent services(microservices architecture). Each service has its own logic, database, and API.
Each service handles a specific functionality (e.g., authentication, payments, order processing).
Helps in team independence (different teams can develop, deploy, and scale independently).
Example: An e-commerce site splits into Product Service, Order Service, Payment Service, each running separately.
Z-Axis Scaling (Data Partitioning / Sharding): Splitting databases/data storage across multiple nodes (sharding) based on attributes like user ID, region, etc.
Each partition (shard) handles only a subset of data (e.g., based on customer ID, region, etc.).
Common in high-traffic applications that need massive storage.
Layered Architecture
A layered architecture divides software into different layers to separate concerns and improve modifiability, portability, and reusability.
Layers communicate only with adjacent layers, creating a strict unidirectional flow of data and control.
Types:
Two-Layer Architecture (Client-Server): A basic architecture model, typically found in traditional applications.
The client contains the user interface and application logic.
Handles database operations and backend logic.
Example:
A desktop application using JDBC/ODBC for database communication.
A calculator app with a small embedded database.
Three-Tier(Layer) Architecture: Common in web applications.
Client Tier / Presentation Layer (UI) – Handles user interactions (e.g., React, Angular).
Business Logic Layer / Server Tier (Application Layer) – Processes requests and applies business rules (e.g., Java, .NET, Node.js).
Data Tier / Data Layer (Database) – Stores and retrieves data (e.g., MySQL, MongoDB).
Business Logic Placement:
In the Presentation Layer(Bad):
Duplication: Logic repeated across Web, Mobile, APIs.
Poor Maintainability: Update needed in many places.
Security Risks: Exposes sensitive logic to the client.
In the Domain/Business Layer(Good):
Encapsulation – Keeps core business rules separate and reusable.
Scalability – Reused across multiple UI platforms (Web/Mobile/API).
Maintainability – Easier to update logic without affecting the UI.
Security – Protects sensitive business rules from direct UI exposure.
Example: If a list of products needs to highlight those with a 10% increase in sales:
Method 1 (Bad): Logic in the UI layer to compare sales and set color.
Method 2 (Good): A method in the business logic layer determines the condition and the UI just reflects the change.
The Domain Layer is a crucial component of software architecture, particularly in Domain-Driven Design (DDD). It contains the business logic and rules that define how data is processed in an application.
The Domain Layer represents the core business logic of an application. It is responsible for defining:
Business rules (e.g., “A customer can’t place an order without an address”).
Entities and Aggregates (e.g., User, Order, Product).
Services that handle business-related operations.
N-Tier(Layer) Web Architecture
An N-tier architecture extends three-tier architecture by adding more layers.
Benefits:
Better security – Each layer can enforce security policies.
Performance optimization – Load balancing across multiple servers.
Scalability – More tiers can be added as needed.
Common Layers in N-Tier Architecture:
Client Tier: User interface (HTML, CSS, JS)
Application/Service Tier: Handles business logic (e.g., Application Server)
Data Tier: Stores data (e.g., SQL or NoSQL database)
Additional Tiers (Optional):
API Gateway Layer
Authentication Layer
Caching Layer
Logging/Monitoring Layer
Integration Layer (for third-party services)
Security Layer
Evolution of Distributed Systems
RPC (Remote Procedure Call): RPC is a protocol that allows one program to call a function on a remote machine as if it were a local function call.
Client sends a request with function name and parameters.
Server executes the function and sends back the result.
The client receives the result and continues execution.
Used in early client-server models.
Pros: Simple to implement, Natural syntax - looks like a local function call.
Cons:
Tightly coupled: Client and server must agree on method names, parameters, and structure.
Often platform/language-dependent.
Error handling is primitive (no REST-like status codes).
gRPC (modern implementation by Google) is used in microservices today.
RMI (Remote Method Invocation) – Java-specific version of RPC that allows objects to invoke methods on remote Java objects.
Pros:
Java-native and object-oriented.
Seamless integration with Java applications.
Cons:
Works only with Java.
Tightly coupled – changes in remote objects affect clients.
Performance overhead due to serialization/deserialization.
SOAP
SOAP (Simple Object Access Protocol): SOAP is a platform-agnostic protocol for exchanging structured information using XML between web services over HTTP, SMTP, or other protocols.
Components:
SP (Service Provider) → The server that exposes a SOAP web service (e.g., a Bank API providing getAccountBalance).
SR (Service Registry) → A directory (UDDI) where web services are registered and discovered. Clients query it to find services.
SC (Service Consumer) → The client (e.g., a mobile banking app) that finds the WSDL in UDDI and sends a SOAP request to SP.
Working Flow:
Service Provider (SP) publishes a WSDL (Web Services Description Language) file to the Service Registry (SR).
Service Consumer (SC) queries the UDDI registry to find the required service.
SC retrieves the WSDL.
SC sends a SOAP request to the SP.
SP processes it and returns a SOAP response (structured XML).
Pros:
Platform and language-independent.
Strong security features (e.g., WS-Security).
Supports transactions and reliability (e.g., ACID).
Standardized and mature.
Cons:
Heavyweight: Verbose XML makes communication slow.
Complex: Requires WSDL, UDDI, and strict contracts.
Slower than lightweight alternatives like REST.
Monolithic vs. Microservices Architecture
Monolithic Architecture: A monolithic application is developed as a single, tightly-coupled unit where all components—UI, business logic, and data access—are packaged and deployed together.
Example: A Java web application deployed as a WAR file on a Tomcat server.
Pros:
Simple to develop initially.
Easier local testing and debugging.
Straightforward deployment (one package, one deployment).
Challenges:
Scalability Issues – We must scale the entire application, even if only one part needs more resources.
Deployment Bottlenecks – A minor change (e.g., fixing a typo) requires redeploying the entire app.
Hard to Maintain – As the app grows, it's difficult for teams to work independently.
Tight Coupling – All components are interdependent.
Microservices Architecture: In Microservices architecture, an application is split into independent services, each handling a specific business function, and communicating through APIs (often REST/gRPC).
Each service is deployed independently and often has its own database (polyglot persistence).
Advantages of Microservices:
Independent Scalability – Only scale services that need more resources.
Faster Releases – Smaller teams own and deploy individual services.
Fault Isolation – A bug in one service (e.g., email) won’t crash the whole system.
Technology Flexibility – Teams can use different tech stacks for different services.
Challenges of Microservices:
DevOps Overhead – Requires CI/CD, container orchestration (e.g., Docker, Kubernetes).
Distributed System Complexity – Difficulties in service discovery, communication, load balancing.
Data Consistency – Managing ACID transactions across services is hard (eventual consistency often preferred).
Monitoring and Debugging – Requires sophisticated observability tools.
Service-Oriented Architecture (SOA)
A modular design where services communicate via an ESB (Enterprise Service Bus).
ESB Role: Acts as a middleware for message routing, transformation, and orchestration.
Message Routing – Directing service requests to the appropriate provider.
Data Transformation – Converting message formats (e.g., JSON to XML).
Protocol Mediation – Supporting communication between services using different protocols (e.g., HTTP).
Orchestration – Coordinating multiple services to fulfill complex workflows.
Decouples services for better maintainability.
Key Principle - Single Responsibility Principle (SRP): Gather components that change for the same reason.Separate those that change for different reasons.
Each service should encapsulate a single business capability.
Example: Keep Authentication, Order Processing, and Billing as separate services because they evolve for different business reasons.
SOA Example – E-commerce System: Enterprise Service Bus (ESB) handles communication between multiple web services.
Service 1: Handles user authentication.
Service 2: Manages order processing.
Service 3: Provides billing.
Pros:
Reusable services across applications.
Supports heterogeneous platforms (e.g., Java and .NET services communicating).
Enterprise-ready, ideal for large organizations with complex workflows.
Cons:
ESB is a Single Point of Failure – If it goes down, the whole communication flow breaks.
High Complexity – Managing service contracts, XML schemas, and WSDLs adds overhead.
Less flexibility – Compared to microservices, services often share databases, reducing autonomy.
API (Application Programming Interface)
An API is a software interface that enables two or more applications to communicate with each other.
It acts as a messenger that delivers client requests to a server and then returns the server’s response back to the client.
Types of APIs (Based on Access Scope):
Public APIs (Open APIs): Openly available to external developers and users.
Example: Twitter API, OpenWeatherMap, Google Maps API.
Use Case: Third-party app integration.
Private APIs: Used internally within an organization for integration.
Partner APIs: Shared with specific partners under agreements.
API Paradigms:
Request-Response APIs: These follow a client-server model where the client sends a request, and the server returns a response.
REST(Representational State Transfer):
Based on HTTP methods: GET, POST, PUT, DELETE.
Resources are accessed via URLs.
Stateless communication and cacheable responses.
RPC (Remote Procedure Call):
Directly invokes functions on the server, passing parameters.
Simpler than REST, often used in internal systems.
Variants:
gRPC (modern high-performance RPC by Google)
JSON-RPC, XML-RPC
GraphQL: Developed by Facebook.
Client specifies exactly what data is needed.
Reduces over-fetching and under-fetching of data.
Single endpoint replaces multiple REST calls.
Event-Driven APIs (Asynchronous Communication): These are real-time and reactive, enabling the server to push data to clients.
WebHooks: Lightweight HTTP callbacks.
Server notifies the client when an event occurs.
Example: GitHub sends a webhook when someone pushes code.
WebSockets: Opens a persistent, bi-directional connection between client and server.Ideal for real-time apps: chat, games, live stock updates.
Software Architectural Patterns
Architectural patterns define how components in software interact and are organized. The goal is to improve separation of concerns, testability, and maintainability.
Model-View-Controller (MVC): Separates application logic into:
Model: Handles data logic.
View: Manages the UI.
Controller: Handles user input.
Workflow:
User interacts with the View.
Controller handles the input, modifies the Model.
Model updates, and View reflects the changes.
Model-Template-View (MTV): MTV is Django’s implementation of MVC with renamed components:
View(MVC) —> Template
Controller(MVC) —> View
Model-View-Presenter (MVP): Designed to improve testability and separation of UI and logic, especially in desktop and mobile apps.
Model: Business logic + data (same as MVC).
View: The UI, completely passive – no business logic.
Presenter: Handles user actions, interacts with the Model, and updates the View.
Working Steps:
The user interacts with the View (e.g., clicks a button, types in a field).
The View doesn't know what to do with this input, so it passes the event to the Presenter.
Presenter communicates with the Model.
Presenter updates the View with results.
Key Differences from MVC
View is passive in MVP and fully controlled by the Presenter.
In MVC, View may directly read from the Model.
Binding:
One-way or two-way binding can be used.
Commonly involves event listeners and subscribers.
MVP is used in:
Legacy Android apps (Java/Kotlin).
Desktop apps
Older web: jQuery
MVVM (Model-View-ViewModel): Evolved to support reactive UI development using data binding.
MVVM (Model-View-ViewModel) is a software architectural pattern used in frontend development to separate UI logic from business logic.
The View never directly communicates with the Model. Instead, it relies on the ViewModel.
Components of MVVM
Model: Represents the data and business logic (e.g., database, API, local storage).
View: The UI (User Interface) that displays data and captures user interactions.
ViewModel: Exposes data from Model to View using observable properties or bindings.
Working Steps
User interacts with the View. (e.g., clicks a button).
ViewModel captures interaction, updates the Model.
Model updates data (e.g., fetch from server).
ViewModel reflects changes back to View (auto-updated via bindings).
Last updated