ALTERNATE UNIVERSE DEV

CodingBlocks

3factor app – Realtime GraphQL

We begin to twitch as we review the first factor of Hasura’s 3factor app, Realtime GraphQL, while Allen gets distrac … SQUIRREL!, Michael might own some bell bottoms, and Joe is stuck with cobalt.

If you’re reading these notes via your podcast app, you can find this episode’s full show notes and join in on the conversation at https://www.codingblocks.net/episode115.

Sponsors

  • Datadog.com/codingblocks – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.
  • O’Reilly Software Architecture Conference – Microservices, domain-driven design, and more. The O’Reilly Software Architecture Conference covers the skills and tools every software architect needs. Use the code BLOCKS during registration to get 20% off of most passes.
  • Educative.io – Level up your coding skills, quickly and efficiently. Visit educative.io/codingblocks to get 20% off any course.

Survey Says …

Anonymous Vote
Sign in with Wordpress
Would you be interested in doing a Coding Blocks Fantasy Football League?
  • How has this not been a thing for six years?! YES!!!
  • Sportsball ... puuuuuhhhhhhhleasssseeeee ... NO!!!
  • A fantasy game for soccer? Silly Americans ...
vote

News

  • To everyone that took a moment to leave us a review, thank you. We really appreciate it.
    • iTunes: Zj, Who farted? Not me., Markus Johansson, this jus10, siftycat, Runs-With-Scissors
    • Stitcher: wuddadid, unclescooter
  • Zach Ingbretsen gives us a Vim tutorial: RAW Vim Workshop/Tutorial (YouTube)

3factor app and the First Factor

3factor app

  • The 3factor app is a modern architecture for full stack applications, described by the folks at Hasura.
  • High feature velocity and scalability from the start:
    • Real time GraphQL
    • Reliable eventing
    • Async serverless
  • Kinda boils down to …
    • Have an API gateway (for them, GraphQL).
    • Store state in a (most likely distributed) store.
    • Have services interact with state via an event system.
  • Versus how did we used to do things using a REST API for each individual entity.
    • Let’s be honest though. We probably created a single very specialized REST API for a particular page all in the name of performance. But it was only used for that page.
  • Related technologies:
    • Web Sockets
    • Serverless
    • Lambda / Kappa – Types Streaming architectures
    • Event based architectures
    • Microservices

Factor 1 – Realtime GraphQL

Use Realtime GraphQL as the Data API Layer
  • Must be low-latency.
    • Less than 100 ms is ideal.
  • Must support subscriptions.
    • Allows the application to consume information from the GraphQL API in real-time.
Some Comparisons to Typical Backend API Calls
Traditional application 3factor application
Uses REST calls. Uses GraphQL API.
May require multiple calls to retrieve all data (customer, order, order details) – OR a complex purpose built call that will return all three in one call. Uses GraphQL query to return data needed in a single call defined by the caller.
Uses something like Swagger to generate API documentation. GraphQL will auto-generate entire schema and related documents.
For realtime you’ll set up WebSocket based APIs. Use GraphQL’s native subscriptions.
Continuously poll backend for updates. Use GraphQL’s event based subscriptions to receive updates.
Major Benefits of GraphQL
  • Massively accelerates front-end development speed because developers can get the data they want without any need to build additional APIs.
  • GraphQL APIs are strongly typed.
  • Don’t need to maintain additional documenting tools. Using a UI like GraphiQL, you can explore data by writing queries with an Intellisense like auto-complete experience.
  • Realtime built in natively.
  • Prevents over-fetching. Sorta. To the client, yes. Not necessarily so though on the server side.
A Little More About GraphQL
  • GraphQL is a Query Language for your API.
  • It isn’t tied to any particular database or storage engine.
  • It’s backed by your existing code and data.
  • Queries are all about asking for specific fields on objects.
  • The shape of your query will match the shape of the results.
  • Queries allow for traversing relationships, so you can get all the data you need in a single request.
    • Every field and nested object has its own set of arguments that can be passed.
      • Many types are supported, including enums.
  • Aliases
    • GraphQL has the ability to alias fields to return multiple results of the same type but with different return names (think of aliasing tables in a database query).
  • Fragments
    • Fragments allow you to save a set of query fields to retrieve, allowing you to later reuse those fragments in simpler queries. This allows you to create complex queries with a much smaller syntax.
    • There’s even the ability to use variables within the fragments for further queries requiring more flexibility.
  • Operations
    • Three types of operations are supported: query, mutation, and subscription.
    • Providing an operation name is not required, except for multi-operation documents, but is recommended to aid debugging and server side logging.
  • Variables
    • Queries are typically dynamic by way of variables.
    • Supported variable types are scalars, enums, and input object types.
      • Input object types must map to server defined objects.
    • Can be optional or required.
    • Default values are supported.
    • Using variables, you can shape the results of a query.
  • Mutations
    • Mutations allow for modifying data.
    • Nesting objects allows you to return data after the mutation occurs,
    • Mutations, unlike queries, run sequentially, meaning mutation1 will finish before mutation2 runs.
      • In contrast, queries run in parallel.
  • Meta fields
    • GraphQL also provides meta fields that you can use to inspect the schema that are part of the introspection system.
    • These meta fields are preceded by a double underscore, like __schema or __typename.
  • GraphQL schema language
    • Objects are the building blocks of a schema.
    • Fields are properties that are available on the object.
    • Field return types are defined as well – scalar, enum or objects.
      • Scalar types: Int, Float, String Boolean, ID (special use case), or User Defined – must specify serializer, deserializer and validator.
    • Fields can also be defined as non-nullable with an exclamation after the type like String!.
      • This can be done on array types as well after the square brackets to indicate that an array will always be returned, with zero or more elements, like [String]!.
    • Each field can have zero or more arguments and those arguments can have default values.
    • Lists are supported by using square brackets.
    • GraphQL’s type system supports interfaces.
    • Complex objects can also be passed as input types, however, they are defined as input rather than type.

Resources We Like

Tip of the Week

  • From Google’s Engineering Practices documentation: How to do a code review (GitHub.io).
    • This is part of the larger Google Engineering Practices Documentation (GitHub.io).
  • Use CTRL+SHIFT+V to access Visual Studio’s Clipboard Ring.
  • Take control of your tab usage in your browser with Workona.
  • Theme your Chrome DevTools!

Episode source