By Author:
Dr. Shailesh Kumar Shivakumar, Solution Architect, Mindtree
Performance principles provide a best practices-based approach to design optimal performance. In this whitepaper we discuss the main performance-related principles and the primary bottleneck scenarios and patterns. We also discuss performance validation methods.
Performance related architecture principles
Here are the key performance-related optimization principles:
Single Responsibility Principle (SRP)
The SRP principle states that modules should do one thing. By applying the SRP to components and services, it is easier to maintain, modularize, test, and extend the code. Here are some best practices of SRP:
- Each service should handle a single concern. Services should be encapsulated by the context.
- A component should only handle the logic related to the view. All other logic should be handled by the services.
- Develop reusable services so that components are simple and reusable.
- Develop smaller, modular, and reusable functions.
- Presentation logic should be separated from business logic.
- Follow DRY (Don’t Repeat Yourself) approach. The DRY approach ensures reusability, maintainability, testability, and reduces complexity.
Responsive design
Ideally, we should leverage responsive design to cater to multiple devices and browsers. The responsive design utilizes HTML 5, CSS 3 and media queries to render the web page optimally across various browsers and devices.
Single code base
Develop the web platform using a tool that uses a single code base for web and for various mobile devices. Isomorphic applications use a single code base for client and server side. For instance, we can use IONIC4 based Hybrid cross-platform development using Angular7 with a single source code for both iOS & Android mobile apps.
Optimal maintenance cost and shorter time to market
A single code base improves maintainability and results in effective cost reduction for implementation, support, and maintenance. The single code base also accelerates time to market.
Separation of concerns
Create different modules and components to handle data, UI rendering logic, business logic and communication logic. This pattern improves code testability, reusability, and extensibility.
Testability
The modules and components should follow the single responsibility principle (SRP) that separates concerns. This makes the code easily testable.
Extensibility
The models and components should be reusable and extensible following the open-closed principle.
Maintainability
In case of new UI requirements in the future, the UI components should be reused so that we don’t need to rewrite the entire UI.
Modern web platforms use an API-driven and contract-based approach for integration. They use modular, lightweight, and granular microservices for integrations. The services are decomposed based on the business capabilities required for the web platform. In this section we define the main design principles for the integration modules within modern web platforms.
Stateless integration
The server APIs should be stateless with well-defined contracts and should use the security tokens for security scenarios. Stateless APIs are lightweight in nature and can be used with various channels (such as web platforms, mobile apps, and others).
High performance
The server APIs should respond within the defined performance SLA. To render the entire page within a two-second response timeframe, each of the underlying APIs should respond within 0.5 seconds. Additionally, the performance of the server APIs should not degrade under a normal load.
Scalability
Normally a single web page needs data from multiple server APIs and the web page or the screen invokes the APIs asynchronously. In order to support multiple invocations, we need to test the scalability and performance of the server APIs at normal load and peak load. The APIs should also be scalable to dynamic requirements.
Fault tolerance
The server APIs should gracefully handle error and exception scenarios. For instance, if the APIs cannot get the source data, they could fallback to cached data or send a friendly error message. In case of transaction failure, the server API or the orchestration layer must ensure data integrity and consistency through rollback mechanisms.
End-to-end security
The server APIs should be secured to ensure data sensitivity, resource authorization and API security. The security governance process should enforce the security checks before invoking the APIs. The API itself should validate the invoker’s permission and provide the data accordingly. All sensitive data should be encrypted.
Lightweight design
The server APIs for modern web platforms should use a lightweight data exchange format such as JSON. APIs should serve the response based on the request channel; for instance, the API should provide minimal data to the mobile app request as compared to a web request.
Testable
The APIs should specify well-defined contracts and we should be able to test the APIs to validate the request and response contract. We should be able to conduct various tests (such as regression testing, automated testing, etc.) on the APIs with proper tools.
Plug and play architecture
The server APIs must be flexible enough to support various clients (such as browsers, mobile apps, tablets, wearables, watches, kiosks, etc.); various deployment models (such as on-premise, cloud or serverless architecture); various protocols (such as HTTP, HTTPS, REST, SMTP, etc.); and be platform agnostic (across cloud, database, UI framework etc.).
Extensibility
The APIs should be decomposed based on business functionality. API-driven design should enable incremental addition of business capabilities.
Service governance
Normally the integration middleware systems provide the service governance. They handle the concerns such as:
- Parsing incoming requests or inject headers in response. For example, we could use body-parser middleware for parsing the HTTP request.
- Authenticating requests before processing. For example, we could use passport to handle various authentication strategies (such as OAuth, Email, AD, third party authentication etc.). Middleware such as helmet can secure the APIs through headers.
- Logging request and response.
- Handling CORS (Cross Origin Resource Sharing).
- Proxying requests through middleware such as http-proxy.
- Error-handling by gracefully handling application errors, connection errors and data errors.
- Compress the HTTP response. For example, compression middleware can be used for HTTP response compression.
- Cache the required and static data.
- Perform any required data transformation.
The API façade pattern can be used at middleware to orchestrate the system-specific calls and abstract the details from the caller.
Asynchronous API invocations
- Most modern web platforms invoke the server APIs asynchronously. Such asynchronous calls prevent blocks in request processing and we can execute the tasks in parallel.
Download Whitepaper to read more
