Architectural Considerations For Complex Mobile And Web Applications
Vivek Jain Application Developer Twitter: @vivekjain10
Feb 2015, Pune
• Implementation Strategy
• Keeping Client-side Light
2
Implementation Strategy
3
Experience
4
Experience
4
Reach
5
Reach
5
Reach
5
Reach
5
Product or Channel
6
Product or Channel
6
Product or Channel
6
Product or Channel
6
Ultimate Goal
7
Use
r Exp
erie
nce
Line of deployment
Awesome apps
Ultimate Goal
7
Use
r Exp
erie
nce
Line of deployment
Awesome apps
The Laser Strategy
8
Use
r Exp
erie
nce
Line of deployment
Awesome apps
The Laser Strategy
8
Use
r Exp
erie
nce
Line of deployment
Awesome apps
The Laser Strategy
8
Use
r Exp
erie
nce
Line of deployment
Awesome apps
The Laser Strategy
8
Use
r Exp
erie
nce
Line of deployment
Awesome apps
The Cover-your-bases Strategy
9
Use
r Exp
erie
nce
Line of deployment
Awesome apps
The Cover-your-bases Strategy
9
Use
r Exp
erie
nce
Line of deployment
Awesome apps
The Cover-your-bases Strategy
10
Use
r Exp
erie
nce
Line of deployment
Awesome apps
11
Native Vs Web
11
Native Web
Native Vs Web
11
Affordability
Native Web
Native Vs Web
11
Affordability
User Experience
Native Web
Native Vs Web
11
Affordability
User Experience
Native Web
PhoneGapXamarin
Calatrava
Hybrid
Titanium
Native Vs Web
Keeping Client-side Light
12
13
Client-side Logic
13
"name": { "first": "Amitabh", "last": "Bachchan"}
Client-side Logic
13
"name": { "first": "Amitabh", "last": "Bachchan"}
fullName = "#{name.first} #{name.last}"
Client-side Logic
14
Change in Requirement
14
"name": { "first": "Amitabh", "middle": "Harivansh", "last": "Bachchan"}
Change in Requirement
14
"name": { "first": "Amitabh", "middle": "Harivansh", "last": "Bachchan"}
fullName = "#{name.first} #{name.middle} #{name.last}"
Change in Requirement
15
Light Client
15
"name": { "first": "Amitabh", "middle": "Harivansh", "last": “Bachchan", "full": “Amitabh Harivansh Bachchan"}
Light Client
15
"name": { "first": "Amitabh", "middle": "Harivansh", "last": “Bachchan", "full": “Amitabh Harivansh Bachchan"}
fullName = name.full
Light Client
Benefits
16
Benefits
• Less duplication of code
16
Benefits
• Less duplication of code
• Easier to fix defects
16
Benefits
• Less duplication of code
• Easier to fix defects
• Some changes without app release
16
API Best Practices
17
Consistent Interface
18
Consistent Interface
• Consistent Format
18
Consistent Interface
• Consistent Format
• Back-end Systems/Database Agnostic
18
Consistent Interface
• Consistent Format
• Back-end Systems/Database Agnostic
• Standard Architecture (REST)
18
Aggregate
19
"id": 1234, "type": "savings"
"id": 1234, "balance": 100.23
Aggregate
19
"id": 1234, "type": "savings"
"id": 1234, "balance": 100.23
"id": 1234, "type": "savings", "balance": 100.23
Optimize
20
"id": 1234, "type": "savings”, “branch_id": 75, “customer_id”: 20757
Optimize
20
"id": 1234, "type": "savings”, “branch_id": 75, “customer_id”: 20757
"id": 1234, "type": "savings”, “customer_id”: 20757
Expand, then Contract
21
Expand, then Contract
21
"name": { "first": "Amitabh", "last": "Bachchan"}
Expand, then Contract
21
"name": { "first": "Amitabh", "last": "Bachchan"}
"name": { "first": "Amitabh", "last": "Bachchan", "full": “Amitabh Bachchan"}
Expand, then Contract
21
"name": { "first": "Amitabh", "last": "Bachchan"}
"name": { "first": "Amitabh", "last": "Bachchan", "full": “Amitabh Bachchan"}
"name": { "full": “Amitabh Bachchan"}
Who owns APIs?
22
Poly-skilled teams
23
Poly-skilled teams
• Client + Server side skills
23
Poly-skilled teams
• Client + Server side skills
• Empowered to make changes in any layer
23
Poly-skilled teams
• Client + Server side skills
• Empowered to make changes in any layer
• Ideal for small organizations
23
Work with API team
24
Work with API team
• Request changes
24
Work with API team
• Request changes
• Communication channel with back-end teams
24
Work with API team
• Request changes
• Communication channel with back-end teams
• Ideal for mid-size organizations
24
Mobile Facade
25
Mobile Facade
• Middle-layer seen by apps
25
Mobile Facade
• Middle-layer seen by apps
• Minimal logic to support apps (avoid business logic)
25
Mobile Facade
• Middle-layer seen by apps
• Minimal logic to support apps (avoid business logic)
• Aggregate and Optimize Response
25
Mobile Facade
• Middle-layer seen by apps
• Minimal logic to support apps (avoid business logic)
• Aggregate and Optimize Response
• Ideal for large organizations
25
References
• http://martinfowler.com/articles/mobileImplStrategy.html
• http://blog.vivekjain.in/
26