hypermedia lightning talk – or, in defense of centralization of some computation

View Github Repository Open presentation in a new window

mooreniemi

See all presentation from mooreniemi

hypermedia lightning talk – or, in defense of centralization of some computation

0 0

hyper_lightning_talk

the :link: is :zap:

On Github mooreniemi / hyper_lightning_talk

hypermedia lightning talk

or, in defense of centralization of some computation

(but not all of it)

by Alex Moore-Niemi / @feminstwerewolf

(a) Hypermedia (b) (c) (d) (e) GraphQL I think this is a very useful diagram to think about centralization. Where is the majority of the computation taking place? On the client, on the server? Equally across both? What sorts of computation? It's this diagram that makes me think, contrary to popular opinion, hypermedia makes the most sense not on the desktop but on mobile.
A distributed hypermedia architect has only three fundamental options: render the data where it is located and send a fixed-format image to the recipient; encapsulate the data with a rendering engine and send both to the recipient; or, send the raw data to the recipient along with metadata that describes the data type, so that the recipient can choose their own rendering engine.
"traditional client-server style" is Option 1, and means you only get what the server can render for you. GraphQL by itself fits in here, by putting a declarative interface on that rendering of data. Flash and Java applets are examples of Option 2. Obvious downsides: big over the wire, compatibility issues on the client. Basically extinct. RPC schemes that work by sharing header files (declarations) fit in Option 3, and so does Protobuf if you squint a little.
REST provides a hybrid of all three options by focusing on a shared understanding of data types with metadata, but limiting the scope of what is revealed to a standardized interface. REST describes a statically typed program with early binding: types are known "at compile time". This "engine" is the interpreter pattern. (The interpreter pattern is a free Monad.)

How do the server and client share understanding of data types?

Profiles, and registered media types.

Where do we get our standardized interface?

Our types, and our protocol.

But HTTP sux. :c

That's just one protocol. Don't let it box you in! (Also: no it doesn't.)

The model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations. The model application, in other words, renders the potential options to the ultimate input: the user.

How can we expose alternative state transitions in the current set of representations?

Hypermedia.

Hypermedia is defined by the presence of application control information embedded within, or as a layer above, the presentation of information. Distributed hypermedia allows the presentation and control information to be stored at remote locations. We're doing something fundamentally different here. We're saying expose data with context about how it can be used.

so when might I want hypermedia?

When you have relatively little control over your clients, ie., can't expect them to update (mobile).

When you need properties like dynamic dispatch (associating an implementation with an operation) and dynamic binding (associating a name with an operation) in your program.

what are the tradeoffs?

Hypermedia requires the client to work with a certain granularity of programmatically generatable interaction units.

This would make working with Storyboard driven development in iOS difficult and maybe impossible.

In Android, activities need to be declared in the manifest at compile time, but fragments could be generated during runtime.

Our new mental model: Graphs

  • The server has a canonical superset of all possible application states it recognizes how to move through as a graph (every state is a node, and has edges to other nodes).
  • The client can rearrange any useful subgraph of those states it wants and make it available to the final key ingredient: user input/intent.think of the server's graph as black, and the client's graph as red

Importantly, the client can request different sized "graphs" based on a set of tradeoffs like no network requests vs flexibility.

Want to minimize requests? Grab the biggest possible representation of application state with controls embedded of other potential application states, cache it, and move on.

Want to allow flexibility? Grab the smallest representation of application state with minimal controls linking (referencing, like reference types) to other potential application states.

stuff hypermedia does not solve*changing program data schema

stuff hypermedia does solve changing program topology

* if the client supports meta-programming or polymorphic representation of untyped data (like maps) hypermedia can solve this problem. yes, static langs can be meta-programmed. no, i have not lost my mind. 😅

the constraints a client needs to accept to solve the first problem involve some tradeoffs. i think ideally, truly responsive clients with a shared understanding of controls and data types could work this way. in the real world, my guess is that this would best serve as a way to decouple server and client release cycles, for example, you could release on the server a change that is handled programmatically by the client until the client has time to flesh out the actual functionality via its own release. think MVP. you might not want to expose the user to anything less than the best possible UI. that's something to keep in mind as a trade off.

some use cases of topology changing

  • introduction of a promotional element
  • changing terms and services or other notices
  • new selection criteria
  • retiring a workflow
  • adding a new workflow

All of these correspond to adding new nodes or edges to our graph. Done right the "hypermedia way" these can be done without the client needing to ever release a change.

this means:

  • clients can respond to API changes, not be broken by them
  • business logic is centralized, thus consistent
  • clients can focus on the user, not the server

😑 idgi...

Check out my extended presentation on hypermedia, discuss in #rest on freenode, or if all else fails, ask me. 😁

hypermedia lightning talk or, in defense of centralization of some computation (but not all of it) by Alex Moore-Niemi / @feminstwerewolf