Resilient Microservices in Vapor

How to build Microservice applications in a resilient and abstract fashion in the Swift Vapor framework.

Transcript

1. CALEB KLEVETER RESILIENT MICROSERVICES IN VAPOR
2. ABOUT ME
3. ABOUT ME ▸ Contract Software Developer for Skelpo Inc.
4. ABOUT ME ▸ Contract Software Developer for Skelpo Inc. ▸ github.com/skelpo ▸ github.com/SwiftCommerce
5. ABOUT ME ▸ Contract Software Developer for Skelpo Inc. ▸ github.com/skelpo ▸ github.com/SwiftCommerce ▸ Vapor Fanatic
6. ABOUT ME ▸ Contract Software Developer for Skelpo Inc. ▸ github.com/skelpo ▸ github.com/SwiftCommerce ▸ Vapor Fanatic ▸ Maintainer for Several Core Vapor Repositories
7. ABOUT ME ▸ @calebkleveter
8. ABOUT ME ▸ @calebkleveter ▸ @calebkleveter
9. ABOUT ME ▸ @calebkleveter ▸ @calebkleveter ▸ The first time I tried sushi I ate all the wasabi at once.
10. WHY MICROSERVICES?
11. WHY MICROSERVICES? MODULARITY & REUSABILITY
12. WHY MICROSERVICES: MODULARITY
13. WHY MICROSERVICES: MODULARITY ▸ Independently Deployable
14. WHY MICROSERVICES: MODULARITY ▸ Independently Deployable ▸ Replaceable
15. WHY MICROSERVICES: MODULARITY ▸ Independently Deployable ▸ Replaceable ▸ Containment of Failure !
16. WHY MICROSERVICES: MAINTENANCE
17. WHY MICROSERVICES: MAINTENANCE ▸ Isolation of Bugs
18. WHY MICROSERVICES: MAINTENANCE ▸ Isolation of Bugs ▸ Easier to Understand
19. WHY MICROSERVICES: MAINTENANCE ▸ Isolation of Bugs ▸ Easier to Understand ▸ Increased Ease of Evolution
20. SO WHAT ARE RESILIENT MICROSERVICES?
21. SO WHAT ARE RESILIENT MICROSERVICES? ▸ Services with code that is written to last (i.e. not made up of ‘quick fixes’).
22. SO WHAT ARE RESILIENT MICROSERVICES? ▸ Services with code that is written to last (i.e. not made up of ‘quick fixes’). ▸ Services with code that can easily be added too or removed from.
23. SO WHAT ARE RESILIENT MICROSERVICES? ▸ Services with code that is written to last (i.e. not made up of ‘quick fixes’). ▸ Services with code that can easily be added too or removed from. ▸ Services with APIs that age well and are predictable.
24. MICROSERVICES DONE RIGHT
25. MICROSERVICES DONE RIGHT SWIFTCOMMERCE ADDRESS USERS PRODUCTS ORDERS E-MAIL VALIDATION PAYMENT
26. Image by Guma89, License CC BY-SA 3.0 Nope
27. BUILDING ABSTRACT LIBRARIES
28. BUILDING ABSTRACT LIBRARIES Wait, aren’t we talking about microservices?
29. BUILDING ABSTRACT LIBRARIES ▸ Maintainable
30. BUILDING ABSTRACT LIBRARIES ▸ Maintainable ▸ Pluggable
31. BUILDING ABSTRACT LIBRARIES ▸ Maintainable ▸ Pluggable ▸ Testable
32. ABSTRACT LIBRARIES IN THE WILD
33. ABSTRACT LIBRARIES IN THE WILD skelpo/Storage by yours truly
34. ABSTRACT LIBRARIES IN THE WILD ‣Defines file I/O for any backend. skelpo/Storage by yours truly
35. ABSTRACT LIBRARIES IN THE WILD ‣Defines file I/O for any backend. ‣Comes with a default LocalStorage Implementation. skelpo/Storage by yours truly
36. ABSTRACT LIBRARIES IN THE WILD ‣Defines file I/O for any backend. ‣Comes with a default LocalStorage Implementation. ‣Separate implementations for Amazon S3 and Google Cloud Storage. skelpo/Storage by yours truly
37. ABSTRACT LIBRARIES IN THE WILD ‣Defines file I/O for any backend. ‣Comes with a default LocalStorage Implementation. ‣Separate implementations for Amazon S3 and Google Cloud Storage. ‣*Also has a File type for handling file data representation. skelpo/Storage by yours truly
38. Image by Guma89, License CC BY-SA 3.0
39. Image by Guma89, License CC BY-SA 3.0
40. RECAP: MICROSERVICES AT 50,000”
41. RECAP: MICROSERVICES AT 50,000” ▸ They can increase reliability and save user frustration.
42. RECAP: MICROSERVICES AT 50,000” ▸ They can increase reliability and save user frustration. ▸ They can provide a better development experience.
43. RECAP: MICROSERVICES AT 50,000” ▸ They can increase reliability and save user frustration. ▸ They can provide a better development experience. ▸ They are a good thing, but they need to be built correctly.
44. RESILIENT INTERFACES
45. USE A STANDARDIZED API FORMAT
46. USE A STANDARDIZED API FORMAT ▸ Pick the API architecture you are going to use and stick with it
47. USE A STANDARDIZED API FORMAT ▸ Pick the API architecture you are going to use and stick with it ▸ REST, GraphQL, SOAP, gRPC, etc.
48. USE A STANDARDIZED API FORMAT ▸ Pick the API architecture you are going to use and stick with it ▸ REST, GraphQL, SOAP, gRPC, etc.
49. USE A STANDARDIZED API FORMAT ▸ Pick the API architecture you are going to use and stick with it ▸ REST, GraphQL, SOAP, gRPC, etc. ▸ Makes your API predictable.
50. USE A STANDARDIZED API FORMAT ▸ Pick the API architecture you are going to use and stick with it ▸ REST, GraphQL, SOAP, gRPC, etc. ▸ Makes your API predictable. ▸ The client knows what a route should look like.
51. USE A STANDARDIZED API FORMAT ▸ Pick the API architecture you are going to use and stick with it ▸ REST, GraphQL, SOAP, gRPC, etc. ▸ Makes your API predictable. ▸ The client knows what a route should look like. ▸ You know how new routes should look.
52. USE A STANDARDIZED API FORMAT ▸ Easily abstract the implementation for different models.
53. USE A STANDARDIZED API FORMAT ▸ Easily abstract the implementation for different models. ▸ Resources: ▸ restapitutorial.com ▸ graphql.org ▸ grpc.io
54. FOLLOW SEMANTIC VERSIONING
55. FOLLOW SEMANTIC VERSIONING ▸ myapi.io/version/collection/…
56. FOLLOW SEMANTIC VERSIONING ▸ myapi.io/version/collection/… ▸ Adds another layer of predictability and safety.
57. FOLLOW SEMANTIC VERSIONING ▸ myapi.io/version/collection/… ▸ Adds another layer of predictability and safety. ▸ Resource: semver.org
58. KEEP A CHANGEGLOG
59. KEEP A CHANGEGLOG ▸ A single source for all changes between versions.
60. KEEP A CHANGEGLOG ▸ A single source for all changes between versions. ▸ What is the good of knowing something changed if you don’t know what ‘something’ is?
61. KEEP A CHANGEGLOG ▸ A single source for all changes between versions. ▸ What is the good of knowing something changed if you don’t know what ‘something’ is? ▸ Resource: keepachangelog.com
62. CREATE MATCHING DATA STRUCTURES ▸ Use matching data structures for matching data sets across your microservices.
63. CREATE MATCHING DATA STRUCTURES ▸ Use matching data structures for matching data sets across your microservices. ▸ A Tale of Two Data Structures: {}.currency == {}.currency_code
64. USE YOUR REQUEST HEADERS
65. USE YOUR REQUEST HEADERS ▸ Use request headers to get the client the data they want.
66. USE YOUR REQUEST HEADERS ▸ Use request headers to get the client the data they want. ▸ Headers that define the expected response include Accept, Accept-*, and If-*.
67. USE YOUR REQUEST HEADERS ▸ Use request headers to get the client the data they want. ▸ Headers that define the expected response include Accept, Accept-*, and If-*. ▸ Resource: developer.mozilla.org/docs/Web/HTTP/ Headers
68. RECAP: EXTERNAL RESILIENCE
69. RECAP: EXTERNAL RESILIENCE ▸ Use a standardized API format.
70. RECAP: EXTERNAL RESILIENCE ▸ Use a standardized API format. ▸ Follow SemVer.
71. RECAP: EXTERNAL RESILIENCE ▸ Use a standardized API format. ▸ Follow SemVer. ▸ Keep a changelog.
72. RECAP: EXTERNAL RESILIENCE ▸ Use a standardized API format. ▸ Follow SemVer. ▸ Keep a changelog. ▸ Use consistent data structures.
73. RECAP: EXTERNAL RESILIENCE ▸ Use a standardized API format. ▸ Follow SemVer. ▸ Keep a changelog. ▸ Use consistent data structures. ▸ Make use of the request headers.
74. INTERNAL ABSTRACTIONS
75. INTERNAL ABSTRACTION I WISH I HAD DONE THAT BEFORE. Everyone’s Future Self
76. INTERNAL ABSTRACTION Just read Clean Architecture By Robert C. Martin
77. INTERNAL ABSTRACTION MICROSERVICE MYSQL
78. INTERNAL ABSTRACTION MICROSERVICE MYSQL MICROSERVICE MONGODB
79. INTERNAL ABSTRACTION Use abstractions for interfacing with external data sources, such as:
80. INTERNAL ABSTRACTION ‣ Databases Use abstractions for interfacing with external data sources, such as:
81. INTERNAL ABSTRACTION ‣ Databases ‣ Web APIs Use abstractions for interfacing with external data sources, such as:
82. INTERNAL ABSTRACTION ‣ Databases ‣ Web APIs ‣ Files Use abstractions for interfacing with external data sources, such as:
83. INTERFACES docs.vapor.codes/3.0/extras/style-guide/#architecture (OR, THE REPOSITORY PATTERN)
84. INTERNAL ABSTRACTION MICROSERVICE MYSQL MICROSERVICE MONGODB
85. INTERNAL ABSTRACTION MICROSERVICE MYSQL MONGODB INTERFACE
86. All code highlighted with JohnSundell/Splash
88. VAPOR SPECIFICS
89. REGISTER SERVICE ABSTRACTIONS
90. REGISTER SERVICE ABSTRACTIONS
91. REGISTER SERVICE ABSTRACTIONS
92. REGISTER SERVICE ABSTRACTIONS
93. USE ROUTE COLLECTIONS
94. USE ROUTE COLLECTIONS ▸ Conform your controller types to RouteCollection.
95. USE ROUTE COLLECTIONS ▸ Conform your controller types to RouteCollection. ▸ Register the collection to your router.
96. USE ROUTE COLLECTIONS ▸ Conform your controller types to RouteCollection. ▸ Register the collection to your router. ▸ Registers your route handlers where they are defined.
97. USE ROUTE COLLECTIONS ▸ Conform your controller types to RouteCollection. ▸ Register the collection to your router. ▸ Registers your route handlers where they are defined. ▸ Reduces complexity in the routes function.
98. USE ROUTE COLLECTIONS
99. USE ROUTE COLLECTIONS
100. USE ROUTE COLLECTIONS
101. USE ROUTE COLLECTIONS
102. PUTTING THE APPLICATION INTO A PROVIDER
103. PUTTING THE APPLICATION INTO A PROVIDER ▸ Abstracts the application from the database.
104. PUTTING THE APPLICATION INTO A PROVIDER ▸ Abstracts the application from the database. ▸ Plug the app into any other app.
105. PUTTING THE APPLICATION INTO A PROVIDER ▸ Abstracts the application from the database. ▸ Plug the app into any other app. ▸ Custom boot sequences for different app instances.
106. PUTTING THE APPLICATION INTO A PROVIDER ▸ Abstracts the application from the database. ▸ Plug the app into any other app. ▸ Custom boot sequences for different app instances. ▸ Dependency injection for provider instances.
107. PUTTING THE APPLICATION INTO A PROVIDER ▸ Abstracts the application from the database. ▸ Plug the app into any other app. ▸ Custom boot sequences for different app instances. ▸ Dependency injection for provider instances. ▸ Default services (using services.extend).
110. RECAP: INTERNAL ABSTRACTIONS
111. RECAP: INTERNAL ABSTRACTIONS ▸ Use interfaces (the repository pattern).
112. RECAP: INTERNAL ABSTRACTIONS ▸ Use interfaces (the repository pattern). ▸ Register your Vapor services under their protocol type.
113. RECAP: INTERNAL ABSTRACTIONS ▸ Use interfaces (the repository pattern). ▸ Register your Vapor services under their protocol type. ▸ Use route collections to build your controllers.
114. RECAP: INTERNAL ABSTRACTIONS ▸ Use interfaces (the repository pattern). ▸ Register your Vapor services under their protocol type. ▸ Use route collections to build your controllers. ▸ Maybe try putting your app in a provider.
115. RECAP: INTERNAL ABSTRACTIONS ▸ Use interfaces (the repository pattern). ▸ Register your Vapor services under their protocol type. ▸ Use route collections to build your controllers. ▸ Maybe try putting your app in a provider. ▸ Check out the Vapor Style Guide. docs.vapor.codes/3.0/extras/style-guide
116. Q & A
117. RESOURCE LINKS ▸ github.com/skelpo ▸ github.com/SwiftCommerce ▸ github.com/skelpo/Storage ▸ restapitutorial.com ▸ graphql.org ▸ grpc.io
118. RESOURCE LINKS ▸ semver.org ▸ keepachangelog.com ▸ developer.mozilla.org/docs/Web/HTTP/Headers ▸ docs.vapor.codes/3.0/extras/style-guide ▸ github.com/JohnSundell/Splash
119. THANKS FOR LISTENING!