The Continuum From Static to Dynamic
Dan Abramov in “Static as a Server”:
Static is a server that runs ahead of time.
“Static” and “dynamic” don’t have to be binaries that describe an entire application architecture. As Dan describes in his post, “static” or “dynamic” it’s all just computers doing stuff.
Computer A requests something (an HTML document, a PDF, some JSON, who knows) from computer B. That request happens via a URL and the response can be computed “ahead of time” or “at request time”. In this paradigm:
- “Static” is server responding ahead of time to an anticipated requests with identical responses.
- “Dynamic” is a server responding at request time to anticipated requests with varying responses.
But these definitions aren’t binaries, but rather represent two ends of a spectrum. Ultimately, however you define “static” or “dynamic”, what you’re dealing with is a response generated by a server — i.e. a computer — so the question is really a matter of when you want to respond and with what.
Answering the question of when previously had a really big impact on what kind of architecture you inherited. But I think we’re realizing we need more nimble architectures that can flex and grow in response to changing when a request/response cycle happens and what you respond with.
Perhaps a poor analogy, but imagine you’re preparing holiday cards for your friends and family:
- “Static” is the same card sent to everyone
- “Dynamic” is a hand-written card to each individual
But between these two are infinite possibilities, such as:
- A hand-written card that’s photocopied and sent to everyone
- A printed template with the same hand-written note to everyone
- A printed template with a different hand-written note for just some people
- etc.
Are those examples “static” or “dynamic”? [Cue endless debate].
The beauty is that in proving the space between binaries — between what “static” means and what “dynamic” means — I think we develop a firmer grasp of what we mean by those words as well as what we’re trying to accomplish with our code.
I love tools that help you think of the request/response cycle across your entire application as an endlessly-changing set of computations that happen either “ahead of time”, “just in time”, or somewhere in-between.