Upgrade to Pro — share decks privately, control downloads, hide ads and more …

What comes after REST?

What comes after REST?

An opinionated view of GraphQL and other emerging API approaches for more reliable and flexible systems integration.

Shahid N. Shah

October 12, 2018
Tweet

More Decks by Shahid N. Shah

Other Decks in Technology

Transcript

  1. What comes after REST?
    AN OPINIONATED VIEW OF GRAPHQL AND OTHER EMERGING API
    APPROACHES FOR MORE RELIABLE AND FLEXIBLE SYSTEMS INTEGRATION
    BY SHAHID N. SHAH

    View Slide

  2. Audience poll
    REST?
    Swagger /
    OpenAPI?
    SOAP? oData? ORDS?
    GraphQL? Falcor? gRPC? CORBA?
    Microservices? DLL Hell?
    Microservice
    Hell!

    View Slide

  3. REST has
    served its
    purpose for
    data access
    Application-centric approaches have
    mostly migrated to a more data-centric
    and integrated systems strategy.
    Re-engineering workflows from internal
    user targets to include users across
    multiple stakeholders, multiple
    institutions, and disparate systems using
    REST based APIs has been successful.
    As number of endpoints and integrated
    systems have increased, reliability and
    flexibility appear to be suffering.

    View Slide

  4. What’s wrong
    with REST for
    data queries?
    Transport, security, business logic, and data transfer are
    more coupled than appropriate.
    Most of the protocol is driven by convention rather than
    type-safe verifiable specifications.
    We’re so afraid of making changes that we create data layers
    upon data layers leading to microservices hell.

    View Slide

  5. We need something like SQL over a
    unified data space
    This sucks:
    GET /search/user/?name=Shahid
    GET /search/user/?name=Shahid|Yuvi
    GET /search/user/?name=Shahid|Yuvi&limit=10&offset=20
    POST – how do you consistently mutate data vs. execute business logic?
    PUT – how to you update a single field of a 2 megabyte blob?
    PATCH – really?

    View Slide

  6. What’s a consistent public API-focused
    way to manage complex data tasks?
    Select /
    Join
    Filter Order
    Aggregate Page Metadata
    Schema Version

    View Slide

  7. Major issues facing data API strategies
    Discovery Registry Documentation Type safety
    Coupling
    Chattiness
    over fetching
    under fetching -> N+1
    Idempotency Mutability
    Traceability Metrics Portability
    (of code & devs)
    Monetization

    View Slide

  8. What do I suggest for your architecture?
    GraphQL for
    Data
    gRPC for Logic
    DMN for
    Business Rules
    Distributed
    event-oriented
    programming
    OpenTracing &
    OpenCensus

    View Slide

  9. GraphQL is a query language for APIs
    GraphQL is a query language for APIs
    and a runtime for fulfilling those
    queries with your existing data.
    GraphQL provides a complete and
    understandable description of the data
    in your API, gives clients the power to
    ask for exactly what they need and
    nothing more, makes it easier to evolve
    APIs over time, and enables powerful
    developer tools.
    As data storage on servers via
    databases gets more complex (e.g.
    hierarchical) and data consumption via
    mobile apps, web pages, reporting
    tools, etc. needs growing flexibility,
    standard REST APIs endpoints begin to
    get unwieldy.
    A single GraphQL endpoint exposes a
    typed and validatable data schema to
    the client, and the client can request
    only what it needs (similar to SQL).
    Source: http://graphql.org/

    View Slide

  10. Demo time
    https://graphloc.com/
    https://apis.guru/graphql-voyager
    https://graphql-demo.azurewebsites.net/

    View Slide

  11. GraphQL myths and misconceptions
    Nothing to do with graphs or
    graph databases.
    Not a tool or graph database but
    a specification. GraphQL will do
    for arbitrary back ends what
    Structured Query Language (SQL)
    did for relational databases.
    Will not replace REST, but does
    simplify it and gives it more value
    for data-heavy use cases.
    Is language agnostic and can be
    used in legacy and green field
    projects.
    Is transport independent, neutral
    to message protocols, not
    opinionated, and data store
    agnostic.

    View Slide

  12. Why another query language?
    As data storage on servers via databases gets
    more complex (e.g. hierarchical) and data
    consumption via mobile apps, web pages,
    reporting tools, etc. needs growing flexibility,
    standard REST APIs endpoints begin to get
    unwieldy.
    A single GraphQL endpoint exposes a typed
    data schema to the client, and the client can
    request only what it needs (similar to SQL).
    GraphQL is to REST what SQL was to ISAM
    tables.
    https://graphql.org/learn

    View Slide

  13. Modern, less brittle data APIs
    Data structures defined and secured at
    server but shaped by client
    Data structures strongly typed, relational,
    and hierarchical
    Data structures are decoupled from applications
    and are extensible across versions
    Source: http://graphql.org/

    View Slide

  14. Source: Bela

    View Slide

  15. What makes GraphQL special?
    Data producers decide what data is
    possible at the server but consumer can
    shape the data they need at the client.
    Send a GraphQL query to your API and
    get exactly what you need, nothing
    more and nothing less. GraphQL
    queries always return predictable
    results. Apps using GraphQL are fast
    and stable because they control the
    data they get, not the server.
    GraphQL creates a uniform API across
    your entire application without being
    limited by a specific storage engine.
    Write GraphQL APIs that leverage your
    existing data and code with GraphQL
    engines available in many languages.
    You provide functions for each field in
    the type system, and GraphQL calls
    them with optimal concurrency.
    Source: http://graphql.org/

    View Slide

  16. https://www.prisma.io/docs/1.16/understand-prisma/introduction-to-graphql-server-development-aa02/

    View Slide

  17. View Slide

  18. https://labs.getninjas.com.br/sharing-data-in-a-microservices-architecture-using-graphql-97db59357602

    View Slide

  19. The GraphQL architecture and ecosystem
    are made up of the following
    components:
    1. Specifications, shared concepts and
    knowledge management supports.
    2. Authentication.
    3. Backend-as-a-service providers.
    4. Schema Design tools.
    5. Server-side libraries and tools.
    6. Client-side frameworks and tools.
    https://thenewstack.io/graphql-data-query-language-resource-guide/

    View Slide

  20. GraphQL vs. REST Smackdown
    Schema-first,
    not transport
    first
    Client decides
    data access,
    not server
    Strongly typed,
    custom user
    types
    JSON-native
    nesting
    Introspection
    and auto
    documentation
    Versioning not
    required
    Code
    generation
    friendly

    View Slide

  21. Some slick tools
    to get you going
    Swagger2GraphQL
    Postgraphile for auto-generating full HTTPS-accessible
    GraphQL for any PostgreSQL database
    rejoiner for combining multiple gRPC endpoints into
    GraphQL

    View Slide

  22. Next steps
    Kill data access
    microservices, in favor
    of GraphQL
    Implement smarter data
    access with GraphQL
    Subscriptions / Streams
    Kill business logic
    microservices in favor of
    mutable GraphQL
    Kill business logic
    microservices in favor of
    gRPC when GraphQL
    underperforms
    Implement observability
    using OpenCensus,
    OpenMetrics and
    OpenTracing

    View Slide