This document discusses architectural considerations for complex mobile and web applications. It covers implementation strategies like the laser strategy of focusing on one platform and the cover-your-bases strategy of supporting multiple platforms. It also discusses design decisions around native vs hybrid apps and keeping client-side logic light by doing more processing on the server-side. The document provides best practices around API design including using consistent interfaces, aggregating responses, optimizing payloads and expanding and then contracting responses. It discusses organizational structures for managing APIs and client development including poly-skilled teams, dedicated API teams and using a mobile facade layer.

1. Architectural Considerations
For Complex Mobile And Web
Applications
Vivek Jain
Application Developer
Twitter: @vivekjain10
Feb 2015, Pune

2. •Implementation Strategy
•Keeping Client-side Light
2

3. Implementation
Strategy
3

4. Experience
4

5. Experience
4

6. Reach
5

7. Reach
5

8. Reach
5

9. Reach
5

10. Product or Channel
6

11. Product or Channel
6

12. Product or Channel
6

13. Product or Channel
6

14. Ultimate Goal
7
UserExperience
Line of deployment
Awesome apps

15. Ultimate Goal
7
UserExperience
Line of deployment
Awesome apps

16. The Laser Strategy
8
UserExperience
Line of deployment
Awesome apps

17. The Laser Strategy
8
UserExperience
Line of deployment
Awesome apps

18. The Laser Strategy
8
UserExperience
Line of deployment
Awesome apps

19. The Laser Strategy
8
UserExperience
Line of deployment
Awesome apps

20. The Cover-your-bases Strategy
9
UserExperience
Line of deployment
Awesome apps

21. The Cover-your-bases Strategy
9
UserExperience
Line of deployment
Awesome apps

22. The Cover-your-bases Strategy
10
UserExperience
Line of deployment
Awesome apps

23. 11
Native Vs Web

24. 11
Native Web
Native Vs Web

25. 11
Affordability
Native Web
Native Vs Web

26. 11
Affordability
User Experience
Native Web
Native Vs Web

27. 11
Affordability
User Experience
Native Web
PhoneGap
Xamarin
Calatrava
Hybrid
Titanium
Native Vs Web

28. Keeping
Client-side Light
12

29. 13
Client-side Logic

30. 13
"name": {
"first": "Amitabh",
"last": "Bachchan"
}
Client-side Logic

31. 13
"name": {
"first": "Amitabh",
"last": "Bachchan"
}
fullName = "#{name.first} #{name.last}"
Client-side Logic

32. 14
Change in Requirement

33. 14
"name": {
"first": "Amitabh",
"middle": "Harivansh",
"last": "Bachchan"
}
Change in Requirement

34. 14
"name": {
"first": "Amitabh",
"middle": "Harivansh",
"last": "Bachchan"
}
fullName = "#{name.first} #{name.middle} #{name.last}"
Change in Requirement

35. 15
Light Client

36. 15
"name": {
"first": "Amitabh",
"middle": "Harivansh",
"last": “Bachchan",
"full": “Amitabh Harivansh Bachchan"
}
Light Client

37. 15
"name": {
"first": "Amitabh",
"middle": "Harivansh",
"last": “Bachchan",
"full": “Amitabh Harivansh Bachchan"
}
fullName = name.full
Light Client

38. Benefits
16

39. Benefits
• Less duplication of code
16

40. Benefits
• Less duplication of code
• Easier to fix defects
16

41. Benefits
• Less duplication of code
• Easier to fix defects
• Some changes without app release
16

42. API Best Practices
17

43. Consistent Interface
18

44. Consistent Interface
• Consistent Format
18

45. Consistent Interface
• Consistent Format
• Back-end Systems/Database Agnostic
18

46. Consistent Interface
• Consistent Format
• Back-end Systems/Database Agnostic
• Standard Architecture (REST)
18

47. Aggregate
19
"id": 1234,
"type": "savings"
"id": 1234,
"balance": 100.23

48. Aggregate
19
"id": 1234,
"type": "savings"
"id": 1234,
"balance": 100.23
"id": 1234,
"type": "savings",
"balance": 100.23

49. Optimize
20
"id": 1234,
"type": "savings”,
“branch_id": 75,
“customer_id”: 20757

50. Optimize
20
"id": 1234,
"type": "savings”,
“branch_id": 75,
“customer_id”: 20757
"id": 1234,
"type": "savings”,
“customer_id”: 20757

51. Expand, then Contract
21

52. Expand, then Contract
21
"name": {
"first": "Amitabh",
"last": "Bachchan"
}

53. Expand, then Contract
21
"name": {
"first": "Amitabh",
"last": "Bachchan"
}
"name": {
"first": "Amitabh",
"last": "Bachchan",
"full": “Amitabh Bachchan"
}

54. Expand, then Contract
21
"name": {
"first": "Amitabh",
"last": "Bachchan"
}
"name": {
"first": "Amitabh",
"last": "Bachchan",
"full": “Amitabh Bachchan"
}
"name": {
"full": “Amitabh Bachchan"
}

55. Who owns APIs?
22

56. Poly-skilled teams
23

57. Poly-skilled teams
• Client + Server side skills
23

58. Poly-skilled teams
• Client + Server side skills
• Empowered to make changes in any layer
23

59. Poly-skilled teams
• Client + Server side skills
• Empowered to make changes in any layer
• Ideal for small organizations
23

60. Work with API team
24

61. Work with API team
• Request changes
24

62. Work with API team
• Request changes
• Communication channel with back-end teams
24

63. Work with API team
• Request changes
• Communication channel with back-end teams
• Ideal for mid-size organizations
24

64. Mobile Facade
25

65. Mobile Facade
• Middle-layer seen by apps
25

66. Mobile Facade
• Middle-layer seen by apps
• Minimal logic to support apps (avoid business
logic)
25

67. Mobile Facade
• Middle-layer seen by apps
• Minimal logic to support apps (avoid business
logic)
• Aggregate and Optimize Response
25

68. Mobile Facade
• Middle-layer seen by apps
• Minimal logic to support apps (avoid business
logic)
• Aggregate and Optimize Response
• Ideal for large organizations
25

69. References
• http://martinfowler.com/articles/mobileImplStrategy.html
• http://blog.vivekjain.in/
26

70. Thank You!
@vivekjain10
vivek.jain@thoughtworks.com
27