Anatomy of applications and services | System Design Tutorials | Part 7 | 2020

Part 7: Anatomy of applications and services | System Design Tutorials | Part 7 | 2020

Post about Applications and Services.

• What is an app / service?
• What do applications or services do?
• Why do we need them?
• Use case / examples
• Factors for designing apps
• Surprising sub-topic

Using the example of a building, the water, electricity, elevators, etc. are all application equivalents. In client-server architecture.... the client side code sends requests to the server side code expecting a response. 

Examples of client side applications are: DropBox, EverNote, Netflix, Browser, etc. For EverNote, the desktop/mobile/web app communicates to back-end server application. This in turn handles storing the notes, handling user profile, payments, authentication & authorisation, etc.  Multiple back-end applications can interact with each other to fulfil a client side request.

Technology Stack:

The back-end stack could include:

• Python
• Java
• Go
• PHP

Front-end stack could include:

• Java  / Kotlin
• Swift / Objective-C
• Web / JavaScript

In addition to the languages listed for back-end (and front-end) there are frameworks that support development. For example Spring Boot, Laravel, DJango. The frameworks speed up development time, reduce common coding bugs (as it's a single code-base), and have been thoroughly tested by multiple users.

Front-end and Back-end interactions via APIs are language agnostic.

Responsibilities:

Front-end application responsibilities include:

• Render UI elements
• Handle interactions
• Collect Data
• Communicate with Back-End APIs to fetch/store data
• Render static data/information

Back-end application responsibilities include:

• Expose API endpoint
• House business logic
• Handle data modelling / transformation
• Interact with data stores
• Interact with other services

Elements / Factors of Application Design / Development:

• Requirement
• Layers
• Technology Stack
• Code structure / Design patterns
• Data store interactions
• Performance / cost
• Deployment
• Monitoring
• Operational Excellence / Reliability

If, for example, this list was used for designing a parking lot app - it would have the following considerations:

• Requirement - e.g. number of parking slots, sizes, and floor. Finding car based on number plate, find next available slot, etc.
• Layers - this indicates if app will be desktop, mobile, server side CLI (command line interface)
• Technology Stack - for example a web app might have HTML/CSS, JavaScript, and React for front-end and Java with Spring Boot for back-end.
• Code structure / Design patterns - this contains the business logic, as well as logic for user handling and database storage & retrieval
• Data store interactions - often abstracted to be generic, whether data is read and written to disc or cache is determined by the use cases for the system.
• Performance / cost - especially for front-end applications the memory and CPU usage may slow down the application. On the server side, too much processing or storage can also have a cost impact if utilised in a pay per use cloud solution. 
• Deployment - whether hosted on cloud, on premises, etc is determined by the expected scaling needed to support the user base.
• Monitoring - is very important to reduce cost, investigate and fix crashes, as well as understand customer usage of the application.
• Operational Excellence / Reliability - application should be able to handle incorrect or unexpected inputs, it should fail gracefully when for example there is limited or no internet connectivity. 

Surprise topic:

If a single application handles creating/storing notes, payments, user profiles - this is referred to as a monolith. Usually small companies start with a monolithic architecture. 

As the user base scales and services need to be split off - this is called micro-service based architecture that interact with each other to satisfy user requests.