Automating API Orchestration - Vyne + Taxi

The one where Marty explores the Why's and How's of automating orchestration between microservices with Vyne & Taxi.

Transcript

1. Automating API Orchestration with Taxi & Vyne
2. Marty Founder - Vyne CTO - HiP Principal - Lab49
3. spring swagger ★ 3,100 All credit to @dilipkrish & @adrianbk since 2012 @martypitt
4. A tale two of services
5. Two services One has data, another wants it
6. Two services One does stuff, another wants stuff done
7. “We should connect” totally
8. Write code Micro services Nano services Serverless services More Code More Code services More More Code More Code
9. The Art of Integration - 2018. #FML
10. Automating Orchestration
11. orchestrate (v.) connecting multiple services to get stuff done
12. The number of services is growing exponentially
13. The number of integration points is growing exponentially
14. The number of failure points is growing exponentially
15. Microservices go smaller ship faster moar innovate #WeHaveAnInnovationLab
16. Microservices are an enabler
17. 2 Areas: Describe Connect
18. Describe
19. Stage 1 Kinda Shit • Not machine readable • Word / Google Docs, Excel, Email • Not part of codebase / version control Stage 3 Typed Protobuf GraphQL Thrift • Object types • Protocol agnostic • Strict Type System Stage 4 Semantic Taxi JSON-LD RDF / OWL / Sparql • Microtypes • Composable • Extensible Rise of the Machines • Machine readable • Generators (to/from) • Source controlled WSDLs Swagger / RAML Stage 2 The Schema Maturity Slide
20. Publish schemas Write adaptors Adaptors become brittle We need a standard! things don’t match New releases grrrrrr
21. Standards suck.
22. Standards Dilute Nullable extraInfo name2
23. Standards suffocate innovation
24. Autonomy is oxygen to innovation
25. Don’t agree the big stuff.
26. Agree a vocabulary to describe the big stuff
27. date of birth vs birthdate markup vs margin
28. Microtypes
29. BirthDate = LocalDate Margin = BigDecimal
31. taxi (n.) schema language
32. taxi (n.) schema language aim of being Readable
33. taxi (n.) schema language aim of being Expressive
34. taxi (n.) schema language aim of being Extensible
35. Readable
36. Taxi Swagger
37. Goal: Be readable, to encourage writing
38. Goal: Be readable, to encourage conversation
39. Goal: Be readable, to encourage people to stop using fucking Excel (as a schema tool. Please buy my Excel plugin)
40. Expressive
41. type Customer { id : CustomerId as String name : CustomerName email : CustomerEmailAddress? as String } type alias CustomerName as String
42. type Customer { id : CustomerId as String name : CustomerName email : CustomerEmailAddress? as String } type alias CustomerName as String Type aliases (Microtypes)
43. type Customer { id : CustomerId as String name : CustomerName email : CustomerEmailAddress? as String } type alias CustomerName as String Longer syntax, same effect Type aliases (Microtypes)
44. type Customer { id : CustomerId as String name : CustomerName email : CustomerEmailAddress? } Nullable types (non-null is default)
45. type Customer inherits Person { id : CustomerId name : CustomerName email : CustomerEmailAddress? } type Person { … } Inheritance (Composable)
46. operation find( CustomerEmailAddress ) : Customer
47. operation find( CustomerEmailAddress ) : Customer Optional parameter names (encourages Microtypes)
48. operation find( CustomerEmailAddress ) : Customer Protocol agnostic
49. operation find( CustomerEmailAddress ) : Customer Protocol agnostic @HttpGet(url=”customers/{CustomerEmailAddress}”)
50. operation find( CustomerEmailAddress ) : Customer Protocol agnostic @HttpPost(url=”customers/{CustomerEmailAddress}”)
51. operation find( CustomerEmailAddress ) : Customer Protocol agnostic @AmqpRpc(topic=”customers.{CustomerEmailAddress}”)
52. Goal: Allow services to describe what they do
53. type Money { value : Amount as Decimal currency : Currency // Enum, defined elsewhere } type alias OrderValue as Money operation checkAvailableCredit( CustomerId, OrderValue ) : CreditStatus
54. “The credit service only supports USD”
55. type Money { value : Amount as Decimal currency : Currency // Enum, defined elsewhere } type alias OrderValue as Money operation checkAvailableCredit( CustomerId, OrderValue( currency = ‘USD’ ) ) : CreditStatus
56. type Money { value : Amount as Decimal currency : Currency // Enum, defined elsewhere } type alias OrderValue as Money operation checkAvailableCredit( CustomerId, OrderValue( currency = ‘USD’ ) ) : CreditStatus Constraint on input
57. type Money { value : Amount as Decimal currency : Currency // Enum, defined elsewhere } operation convertCurrency( source : Money, targetCcy : Currency ) : Money
58. type Money { value : Amount as Decimal currency : Currency // Enum, defined elsewhere } operation convertCurrency( source : Money, targetCcy : Currency ) : Money( from source, currency = targetCcy ) Response contract
59. type Money { value : Amount as Decimal currency : Currency // Enum, defined elsewhere } operation convertCurrency( source : Money, targetCcy : Currency ) : Money( from source, currency = targetCcy ) Returns this type
60. type Money { value : Amount as Decimal currency : Currency // Enum, defined elsewhere } operation convertCurrency( source : Money, targetCcy : Currency ) : Money( from source, currency = targetCcy ) Based on this
61. type Money { value : Amount as Decimal currency : Currency // Enum, defined elsewhere } operation convertCurrency( source : Money, targetCcy : Currency ) : Money( from source, currency = targetCcy ) But this bit Changed to that
62. operation checkAvailableCredit( CustomerId, OrderValue( currency = ‘USD’ ) ) : CreditStatus operation convertCurrency( source : Money, targetCcy : Currency ) : Money( from source, currency = targetCcy ) Problem Solution
63. Extensible
64. Integration is a two party system
65. Publisher Consumer
66. Publisher Consumer Schemas ignore their needs
67. Consumers gotta consume
68. type Customer { id : String name : CustomerName email : CustomerEmailAddress } Consumers gotta persist type Customer {
69. id : String name : CustomerName email : CustomerEmailAddress } Consumers gotta persist type Customer { @Entity @Id
70. id : String name : CustomerName as LegacySalutation email : CustomerEmailAddress } Consumers gotta map type Customer { @Entity @Id
71. email : CustomerEmailAddress } Consumers gotta validate type Customer { id : String name : CustomerName as LegacySalutation @ValidEmailAddress @Entity @Id
72. email : CustomerEmailAddress } Consumer context is hard type Customer { id : String name : CustomerName as LegacySalutation @ValidEmailAddress @Entity @Id
73. Consumer context is hard but consumers are the reason schemas exist
74. Type extensions
75. Type extensions type Customer { id : String name : CustomerName } @Entity type extension Customer { @Id id name as LegacyMarketingName }
76. Type extensions type Customer { id : String name : CustomerName } @Entity type extension Customer { @Id id name as LegacyMarketingName }
77. Type extensions type Customer { id : String name : CustomerName } @Entity type extension Customer { @Id id name as LegacyMarketingName } Add annotations
78. Type extensions type Customer { id : String name : CustomerName } @Entity type extension Customer { @Id id name as LegacyMarketingName } Add type aliases
79. Type extensions type Customer { id : String name : CustomerName } @Entity type extension Customer { @Id id name as LegacyMarketingName } Cannot change type Can add aliases provided base type is the same
80. Type extensions type Customer { id : String name : CustomerName } @Entity type extension Customer { @Id id name as LegacyMarketingName } +
81. Type extensions @Entity type Customer { @Id id : String name : CustomerName as LegacyMarketingName }
82. Type extensions + Taxi Taxi
83. Type extensions + Swagger Taxi December ‘18
84. Type extensions + RAML, WSDL, Protobuf, etc Taxi Q1 2019
85. consumers
86. Tooling
87. Generators Don’t write it Export it
88. Generators java→taxi kotlin→taxi swagger→taxi Python C# Go PHP Typescript
89. Generators taxi→kotlin taxi→java taxi→typescript
90. taxi-cli command line compiler & generator
91. taxi-cli $ sdk install taxi $ curl https://get.taxilang.org | python
92. taxi-cli Validate & Generate Plugin ecosystem Simple project format
93. Taxi Readable, Expressive, Extensible Schemas
94. https://docs.taxilang.org https://gitlab.com/taxi-lang
95. 2 Areas: Describe (taxi) Connect
96. Connect
97. Vyne
98. Automated API Orchestration
99. given(this) discover(that)
100. given(EmailAddress) discover(Customer)
101. given(EmailAddress) discover( AccountBalance)
102. Vyne connects services
103. No plumbing
104. Vyne adapts as API’s change
105. Demo Time
106. Discover In which Vyne integrates multiple services, fetching requested data
108. Resolve In which Vyne calls services to resolve constraint violations
109. Gather In which Vyne calls services based on their polymorphic result type
110. Holy Sheet In which we use Vyne from within Google Sheets, and you reach for your credit cards
111. FAQ
112. How fast?* 5-30ms varies by complexity *No focus on performance yet
113. <5ms Goal
114. Potential to outperform handwritten code through caching & parallelisation
115. Community Edition + Commercial Edition(s) All of this demo (ex. Excel) Auth, High Avail., Streaming...
116. GraphQL?
117. GraphQL Vyne
118. GraphQL Vyne automates resolvers Q1 2019
119. How mature? Beta Early adopters
120. How mature? marty@vyne.co
121. // TODO
122. Streaming
123. Instant GraphQL
124. Authentication & Data Policies
125. CI / CD Tooling Does this break?
126. Roadmap at https://vyne.co
127. Automated, Dynamic Orchestration Vyne Awesome dev tooling Dead simple API Awesome biz tooling - Excel / Sheets
128. Q&A
129. https://vyne.co marty@vyne.co