Constructing a Consistent and Stable User Experience with REST and GraphQL APIs

Constructing a Consistent and Stable User Experience with REST and GraphQL APIs

APIs are a fantastic way to extend the functionality of a solution across the data center and public clouds. However, as a solution expands the features and available use cases, the complexity of an API surface area scales in parallel. In terms of cloud data management, it can be difficult to create a consistent and deterministic experience when dealing with a huge quantity of integration points (virtual machines, cloud native workloads, file servers, physical servers, hypervisors, etc). At the same time, the user experience is directly impacted by the quality of documentation and frequency of communication, which are often overlooked by project teams. In this session, you’ll hear about the construction of REST and GraphQL APIs that are used by infrastructure engineers and cloud architects around the globe for data management and the various challenges tackled to deliver an exceptional user experience.

80a34a84e6b006b603b1192a8af3b435?s=128

Chris Wahl

July 10, 2019
Tweet

Transcript

  1. 1.

    Constructing a Consistent and Stable User Experience with REST and

    GraphQL APIs Chris Wahl, Chief Technologist at Rubrik Twitter: @ChrisWahl GitHub: chriswahl
  2. 3.

    ▪ The Concept of Cloud Data Management ▪ Designing with

    REST and GraphQL ▪ Real-World Workflows and Automation
  3. 5.
  4. 6.
  5. 7.
  6. 8.
  7. 9.

    ▪ Originally “Converged Data Management” in Aug, 2015 – Coined

    to represent the distillation of hardware and software needs into a single platform. – https://www.rubrik.com/blog/tag/cdm- series/ ▪ Updated to “Cloud Data Management” in Aug, 2016
  8. 11.

    2015: The data center is now an API. David Vallente,

    co-founder and co-CEO SiliconANGLE Media
  9. 13.

    ▪ There are still many “food groups” in the data

    center that lack an API. ▪ Talent that can take advantage of an API / SDK is increasing. ▪ Enterprises are requiring products to have full API support in their buying cycle.
  10. 14.

    ▪ API as a premium – Our API is only

    available in the Super Deluxe Platinum Enterprise Premium edition ▪ API as a side project to address specific large customers – Customer X requires automation of feature Y, so add a shim ▪ API for a specific acquisition – The portfolio contains a few products that came with an API ▪ API as a bolt-on – The “YOLO” approach with a bolt-on proxy
  11. 15.
  12. 16.
  13. 17.

    Things you may hear from IT Ops: ▪ There’s no

    need to learn an API; they are for developers only. ▪ SDKs and Tools are abstraction layers; just focus on that. ▪ The product should do everything and never require API usage.
  14. 18.

    Things you may hear from Developers: ▪ The API is

    just for the product to consume; no one else uses them. ▪ GraphQL is self-documenting and strongly-typed, so no docs are needed. ▪ Let’s just make another endpoint for Resource X.
  15. 19.
  16. 22.

    ✓ Use predictable, resource, and action-oriented URLs. ✓ Use HTTP

    status codes for handling errors and responses. ✓ Allow sophisticated authentication mechanisms (such as API Keys). ✓ Support versioning. ✓ Aim to be understood by standard HTTP clients. ✓ Create a maintainable spec that supports all our use cases.
  17. 23.
  18. 24.

    Create a consistent and deterministic experience when dealing with a

    huge surface area of integration points: Hypervisors Cloud Native Services Legacy Services File Servers Virtual Appliances
  19. 25.

    Place major integration points (parents) at root level of the

    API. Add child items to each parent Leverage HTTP methods to simplify workflows. Ugly: POST to “/add_node” and “/remove_node/{id}” Pretty: POST to “/node” and DELETE to “/node/{id}” Use Boolean field naming conventions. Start with ‘has’, ‘is’ or ‘should’ to make it clear that it is a Boolean field Examples: ‘hasRootAccess’, ‘isAdmin’ and ‘shouldDoSomething’
  20. 26.

    Introduced a version into the path*. Establish a specific version

    control process and model. Use “/internal” to develop new endpoints, but make available to end-users. Use “/v1”, “/v2”, “/vn” to publish stable endpoints. *not applicable in GraphQL
  21. 27.

    The rules of versioning and deprecation. Future deprecation of endpoints

    / resources. New or updated endpoints / resources.
  22. 28.

    ▪ Started with REST since GraphQL was still private at

    Facebook (and very new). ▪ Adopted GraphQL for our Polaris SaaS product. – Much easier to iterate / develop against. – Dramatically less requests needed (often single query). – Strongly typed model for the win!
  23. 31.

    Data protection does not exist or is very painful. Data

    lifecycle includes data protection from cradle to grave. Ecosystem integrations / tools leverage data management. Automated pipelines are delivering services from protected data points in innovative ways. My data has become self aware. Skynet? 1 Happy 2 Data Evolution 3 Multi-Cloud Data Control Plane 4 Data Lifecycle Management 5 Data Protection at Scale
  24. 32.

    ▪ Lifecycle Management ▪ Data Migration to Multi-Cloud ▪ Ransomware

    / Malicious Actors ▪ Development Risk Mitigation ▪ Re-Platform Efforts
  25. 34.

    ▪ Change request / change approval – Atlassian Jira issue

    filed by engineer to make change to object(s) – REST call sent to CDM to inventory object(s) – REST call sent to CDM to generate on-demand snapshot of object(s) – Snapshot held using maintenance SLA (7-14 days retention with auto purge) – Optional approval in Jira once snapshot is stored / replicated ▪ Change executed – If successful, SLA will purge ephemeral snapshot data of object(s) – If failure, REST call sent to CDM to instant restore object(s) as desired ▪ Repeat as needed
  26. 35.

    Object Location A Policy-based Snapshots Workflow Object (Copy) Location B

    Integration API Request Conversion to Native Format Archive to Location B Sprint Duration
  27. 36.

    ▪ Protect object in Location A – Assign SLA to

    object(s) for policy-based snapshot generation – Archive data to Location B to move data close to compute – REST call sent to CDM to request conversion of object(s) at desired frequency ▪ Ephemeral conversion of object(s) in Location B – Ephemeral compute instance converts object(s) in place while respecting archive – REST call sent to CDM to request power on activity for object(s) ▪ Re-platform tasks – Object(s) in Location B access native services for integration – Begin re-platform tasks for object(s) using native services ▪ Repeat process daily, nightly, weekly, etc. based on sprint duration / needs