apidays Paris 2022 - Of graphQL, DX friction, and surgical monolithectomy, Francois Lascelles, Broadcom Software

apidays Paris 2022 - APIs the next 10 years: Software, Society, Sovereignty, Sustainability
December 14, 15 & 16, 2022

Of graphQL, DX friction, and surgical monolithectomy
Francois Lascelles, CTO at Broadcom Software
------

Check out our conferences at https://www.apidays.global/

Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8

Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io

Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/

Deep dive into the API industry with our reports:
https://www.apidays.global/industry-reports/

Subscribe to our global newsletter:
https://apidays.typeform.com/to/i1MPEW

Transcript

1. Francois Lascelles Distinguished Engineer, Broadcom Software DX friction, and surgical monolithectomy. Of GraphQL,
2. 2023 SERIES OF EVENT New York May 16&17 Australia October 11&12 Singapore April 12&13 Helsinki & North June 5&6 Paris SEPTEMBER London November 15&16 June 28-30 SILICON VALLEY March 14&15 Dubai & Middle East February 22&23
3. • Top asked-for ‘modern’ protocol • GraphQL being chosen in new APIs – Especially for internal (“private”) APIs – “…we are standardizing on graphQL…” • This affects your API infrastructure Re-cap from yesterday
4. • GraphQL and authentication, authorization • API infrastructure loss of context – And how to restore it • Best Graph Practices – Should you turn off introspection in prod? • Impact on rate limiting – Why per-request counting is broken? • Query cost analysis and vulnerability mitigation – Basic – Cost modeling – Cost learning • OWASP API-Sec top-10 from GraphQL perspective Impact on API infrastructure Why patterns established for REST APIs aren’t always adapted for graphQL
5. • Beyond processing our customer’s graphQL APIs – How we chose graphQL for a critical API of our own – Lessons learned for others considering graphQL Our own graphQL journey Lessons learned
6. Configuration management • Customers create over time sophisticated, but complex gateway configurations – Thousands of policies and other entities that relate to each other – Services, policies, connectors, data sources, secrets, certificates, counters, … • Config needs nurturing – Analyze, duplicate, update, environmental mapping, … • Existing API to pull/apply config – REST/XML – Hard to use, limiting our ability to deliver next-gen config management capabilities
7. Introducing Graphman • New GraphQL-based API – Wired into the core of Layer7 gateway – Complement + replaces existing tooling – Simplified representation of configuration entities – Fast – Checksums – Dependencies Lessons learned 1. DX complexity introduced by graphQL and how we are dealing with it 2. Early evidence of benefits on innovation provided by graphQL
8. DX Friction • Front-end devs love graphQL – For their own reasons • But just to accomplish a task – E.g.: copy my config to another gateway – Learning graphQL can’t be a pre-req • For average config man user, graphQL feels unnecessarily complex GraphQL is not the right abstraction layer for most users
9. Example 1 Get all the config graphQL REST query everything { policyFragments { name checksum folderPath policy { xml } guid } webApiServices { name checksum resolutionPath folderPath policy { xml }…(actual query 199 lines long and counting) HTTP GET /everything
10. Example 2 • word Output format and chaining queries and mutations
11. Managing DX • Introspection+completion goes a long way • Postman collections – Samples per queries, mutations – Per-request documentation – JS in pre-request and test to switch between input/output format differences • CLI wrappers – README.md, [Curl wrappers].sh, [json transfo].js, pre-baked samples, • Client-side already use tooling rather than the API directly – SDK, Code snippet, .proto, code generation It’s the tooling It was supposed to be easier! Use the tooling
12. Let the power user innovate • The graphQL layer targets the power user • Reap benefits of added flexibility provided by graphQL – Power users create new queries and mutations that work together to address specific repeatable tasks – Output of power user at graphQL layer is the new query integrated in tooling layer • The tooling layer targets the actual user (ops, next layer up ci/cd, etc) – Using the pre-canned requests that are out of box – ones created by power users in their orgs, custom things created specific to their pipeline Keeping the tooling layer open
13. Evidence of power-user innovation Power user introduces new capability Made possible thanks to graphQL layer Tooling layer GraphQL client layer GraphQL server impl new new Regular user leverages it
14. Example 1 • New capability requirement: reverse-dependency analysis • Pre-existing API capability – Forward-dependencies bundled with the policies that use them • Custom query – Get just the right amount of data – Easy to traverse and reverse • Tooling update – New query – Traverse, create reverse-dep report Reverse-dependency analysis
15. Example 1 Demo
16. Example 2 • Entities relate to each other via numerous mechanisms – Entity type – Policy dependency – Folder organization – Belonging to different layers of configuration (framework vs services) each having distinct lifecycles • Bundling per task – Package a service update – Package framework update – Duplicate – Monolithectomy • Target bundle -> corresponding graphql query Bundling
17. • Monolithectomies are complex procedures – Each puzzle is unique – Encounter new species in the wild – Cannot provide samples for any possible way to organize config • GraphQL client-side innovation to the rescue – Expert tailoring, reusable for multiple procedures on same monolith Example 2 (continued) Decode, detangle and decompose your monolith
18. • If it’s about data -> graphQL • Task-oriented API? -> maybe graphQL • Complexity is false concern when alternative has target developer still using abstraction layer – sdk, collection, snippet, proto, above API • Added sophistication allows for more client-side innovation – Especially when paired with open tooling • Increased ability to innovate at client-side should also translate to more stable APIs • API infrastructure needs graphQL context to adapt to these new APIs Last slide The chosen one
19. Thank you
20. Extra Reverse-traversing dependencies
21. Adding GraphQL context to existing API Gateways • Load GraphQL schema at design time – Behind the scene design time introspection facilitates metadata loading • Validate queries/mutations against schema at runtime – Incorporate in policy decision tree • Reduce/tweak schema at edge – Graphql façade/subset Leveraging the power of GraphQL schemas
22. Adding GraphQL context to existing API Gateways • Select an embedded property in an inline input • Parse its value, make available to policy context – Branch on its value – Validate additional conditions Parsing granular inline input property