apidays Paris 2024 - Develop in Parallel and Ship Earlier with OpenAPI and Mocking, Lee Turner, WireMock
Download as PPTX, PDF•0 likes•99 views
Lee Turner's presentation discusses the benefits of using OpenAPI and mocking in API-driven architectures to enable parallel development and quicker shipping of features. Mocking allows teams to receive early feedback on API design, avoids dependency issues, and facilitates faster iterations. The presentation emphasizes that while OpenAPI can generate mocks, its primary purpose is not mock generation, leading to simpler mocks.
apidays Paris 2024 - Develop in Parallel and Ship Earlier with OpenAPI and Mocking, Lee Turner, WireMock
- 1. | 1 Develop in parallel and ship earlier with OpenAPI and mocking 1 PRESENTED BY: Lee Turner Senior Software Engineer, WireMock @leeturner
- 2. | ● API-driven architectures - microservices, SOA, partner integrations ● New product features often require new features in several APIs ● Leads to dependency chains between teams 2 Serial vs. Parallel in API centric systems
- 5. | Service A Client B API Mock Service A API What is mocking?
- 6. |
- 7. | ● Mocks are quick to build - available almost immediately ● No need to wait for depended-on API features to be shipped ● Early feedback on API design = much cheaper to fix issues 7 Mocking enables parallel working
- 9. | Mocking with OpenAPI 9 ● Generate mocks from spec ● Generate spec elements from mocks - prototyping ● Validate traffic against spec - contract testing However… ● OpenAPI is not primarily intended for mock generation ● Generated mocks are simplistic
- 10. |
- 11. | 11 Want to see more? https://www.wiremock.io/demo PRESENTED BY: Lee Turner Senior Software Engineer, WireMock @leeturner
- 12. | 12 PRESENTED BY: Lee Turner Senior Software Engineer, WireMock @leeturner
Editor's Notes
- #1: Remember: Call out 4 vs. 2 sprints explicitly Explain diagram arrows Explain light/dark boxes During demo - call out parallel dev: no backend required Mention stateful mocking/see at booth
- #2: This can lead to a web of dependencies where producers of API have to build and ship something before consumers of that API can start to work with it. This means longer periods of time to ship features to market. So clearly we want to improve this because getting new product features in front of our customers is a good things in pretty much any system.
- #8: Worth having a capable mocking tool that makes these things simple.
- #9: It lacks the vocabulary required to describe the nuances of behaviour that you might want to simulate in a usable mock When you generate mock from an open api they tend to be quite simplistic - they tend to represent the happiest of happy paths in terms of how the mock might respond and the real nuances and variation to how the mock might respond are missing from the first iteration.
- #10: So, with that I am going to hopefully give a practical demonstration of what a development workflow supported by mocks can look like and to show the benefits of going past that first iteration of mock generation to model real behavior. We have based this demo on the Open API developed by the team at bump.sh. This is meant to be an exemplar of what good open api design should look like. It is complex enough to make a good demo but not too complex to be overwhelming