Components in Production

These are our slides from IN/Clojure 2019 where we shared our journey of using the Component framework in Production and solved the issues faced with multiple dependencies and problems faced when there is no clear boundary.

Transcript

1. Components in Production Rubal Jabbal and Pavitra Shetty Engineers @ Helpshift rubal@helpshift.com pavitra@helpshift.com
2. • Existing projects and their problems • Using components in new projects • Journey in Retrospect ** From this point onward, opinions flow freely Agenda
3. - Existing projects and their problems (first Agenda)
4. Project V1
5. Project V2
6. Project Vn
7. Older projects : Global vars for services
8. Older projects : Global vars for services
9. Older projects : Dependency among services
10. Older projects : Dependency among services
11. Older projects : Dependency Order
12. Older projects : Handlers using the dependencies
13. Older projects : Shutdown services
14. What is not-so-good about it? Summarizing: • Use of Global Vars • Implicit information • Structure and Order of services • Weak State Management of dependent services
15. - Using Components in new projects (nth Agenda)
16. A component - `Lifecycle` protocol
17. A component - Lifecycle for MongoDB
18. A component - Lifecycle for MongoDB
19. The big picture : setup the system
20. The big picture : setup the complete system
21. The big picture : system map
22. The big picture : setup the complete system
23. The big picture : the complete system map
24. The big picture : dependency graph
25. The big picture : start the system
26. The big picture : stop the system
27. The big picture : main function
28. The big picture : main function
29. Dependency graph for an existing project
30. The big picture : handlers in older project
31. The big picture : handlers using components
32. Writing Tests
33. QA - Integration testing in older projects
34. QA - Integration testing in older projects
35. QA - Integration testing in older projects
36. QA - Integration testing using components
37. QA - Integration testing using components
38. QA - Integration testing using components
39. System Health Check
40. System Health Check
41. `Status` protocol
42. Status protocol - MongoDB
43. A complete component
44. The big picture : System health check
45. The big picture : System status check
46. The big picture : System status check
47. Looks great, but...
48. Looks great, but... • Large number of components as function arguments
49. Looks great, but... • Large number of components as function arguments ◦ Single Responsibility Functions!
50. Looks great, but... • Large number of components as function arguments • What qualifies as a “Component”?
51. Looks great, but... • Large number of components as function arguments • What qualifies as a “Component”? • Migrating large or active projects
52. Looks great, but... • Large number of components as function arguments • What qualifies as a “Component”? • Migrating large or active projects ◦ `Whole app buy in`
53. Looks great, but... • Large number of components as function arguments • What qualifies as a “Component”? • Migrating large or active projects • Boilerplate code.
54. Looks great, but... • Large number of components as function arguments • What qualifies as a “Component”? • Migrating large or active projects • Boilerplate code • Code navigation?
55. - Journey in Retrospect (last Agenda)
56. What we learnt? • Suitable for migrating small projects or starting from scratch.
57. What we learnt? • Suitable for migrating small projects or starting from scratch. • Larger projects need better understanding of what could be defined as a “component”.
58. What we learnt? • Suitable for migrating small projects or starting from scratch. • Larger projects need better understanding of what could be defined as a “component”. • PRO - Using components made us think of a project as a whole, and hence bring about some structure from start.
59. What we learnt? • Suitable for migrating small projects or starting from scratch. • Larger projects need better understanding of what could be defined as a “component”. • PRO - Using components made us think of a project as a whole, and hence bring about some structure from start. • CON - Clojure does not force such architectural rules, so the transition seems challenging.
60. What we learnt? • Suitable for migrating small projects or starting from scratch. • Larger projects need better understanding of what could be defined as a “component”. • PRO - Using components made us think of a project as a whole, and hence bring about some structure from start. • CON - Clojure does not force such architectural rules, so the transition seems challenging. • Hacking -> Use Global Vars; Engineering -> Use Components!
61. What we learnt? • Suitable for migrating small projects or starting from scratch. • Larger projects need better understanding of what could be defined as a “component”. • PRO - Using components made us think of a project as a whole, and hence bring about some structure from start. • CON - Clojure does not force such architectural rules, so the transition seems challenging. • Hacking -> Use Global Vars; Engineering -> Use Components! • Other alternatives? Mount, Integrant?
62. What we learnt? • Suitable for migrating small projects or starting from scratch. • Larger projects need better understanding of what could be defined as a “component”. • PRO - Using components made us think of a project as a whole, and hence bring about some structure from start. • CON - Clojure does not force such architectural rules, so the transition seems challenging. • Hacking -> Use Global Vars; Engineering -> Use Components! • Other alternatives? Mount, Integrant? • Finally, YMMV!
63. Best* Practices *Recommended 1. Implementation of Lifecycle methods should always return the Component. 2. The component record should be indicative of all the required dependencies in fields. 3. Start & Stop methods should be idempotent. 4. Have Constructors; they should create the record, not do state creation. 5. Cyclic dependencies is not allowed (by design). Plan for it.
64. 2. Component record indicative of dependencies
65. We are hiring! https://jobs.lever.co/helpshift Suggestions? Questions? More projects on: https://github.com/helpshift