Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save matthewstokeley/80b6420fbaacca5d4b7cfa3712d9eb2d to your computer and use it in GitHub Desktop.
Save matthewstokeley/80b6420fbaacca5d4b7cfa3712d9eb2d to your computer and use it in GitHub Desktop.
Stateful strategies in HTTP applications
Http applications
- Mobile
- Js apps
- Server-side
- Hybrid
- API’s
Persistence
Sessions
Stateless transfer
Local storage
Redux
Finite state machines
Reactive programming
Contamination
Event Patterns
Shared State Concurrency
Stateful computation
Mutable/immutable state
Side-effects: mutations to memory references outside the named scope - for instance, an accessor set method is not a side effect when the class property mutates, but if that property mutated in an unrelated iteration method, the mutation of that reference would be considered a side effect.
Referential transparency / polymorphism
What does building stateful applications with Rails, Redux, Reactive Programming, and REST tell us about stateful systems? A coherent strategy is important. Let’s take a look at four strategies implemented by the previously mentioned frameworks and paradigms.
*Modeling*
“The data model is the entirety of application state.” MVC’s and MVVM’s, reliant on OOP, apply this strategy at the component or unit level, where the model is the properties of the class encapsulated in an object - Libraries to add static type-checking to languages where that isn’t native exist. Data models can also be reactive. The design of reactive programming is essentially an FSM that triggers a polymorphic function on state change that accepts state as an argument, otherwise known as a reactive function. In an event-driven, immutable system, a new data model would be created reflecting state on every invocation. Otherwise, various designs for object mutation are available.
*Persistance*
The persistance layer refers to server-specific properties that bind objects between requests. It is similar to a cache layer in serving response data to a specific user across multiple requests - it isn’t a cache layer because the binding mechanism is specific to handling multiple http requests for **specific data**, instead of LRU or other patterns for serving the **most recent request**. Persistance also shares design concerns with cache implementations, including error handling strategies for user authentication and dropped connections. Sessions is a core feature PHP, in Rails the persistance layer is a part of the ORM, simplifying integration with in-memory key stores as well as caching services.
*Messaging*
One strategy for handling state in client and server-side applications is to utilize an event-driven system that acts like a global pub-sub broker cascading state change to subscribed components or units. This can invoke re-rendering. If the application is also events-based, methods can be subscribed from highly decoupled unit-level components or controllers, otherwise the framework can conventionally obfuscate event listening by invoking lifecycle methods. Messaging is especially powerful and frameworks like Redux assure best practices and a common language between implementations.
*Avoidance*
State at the system and component level introduces system complexity. Functional programming and serverless architectures eschew state and side effects altogether in favor of polymorphic referential transparency that depends more on input and control flow and less on memory references, preserving Liskov’s principle. Stateless representation is very similar to HTTP responses and requests, where state is avoided but abstraction of implementation details is not precluded. These are sophisticated and elegant approaches.
*Glossary*
Http applications
- Mobile
- Js apps
- Server-side
- Hybrid
- API’s
Persistence
Sessions
Stateless transfer
Local storage
Redux
Finite state machines
Reactive programming
Contamination
Event Patterns
Shared State Concurrency
Stateful computation
Mutable/immutable state
Side-effects: mutations to memory references outside the named scope - for instance, an accessor set method is not a side effect when the class property mutates, but if that property mutated in an unrelated iteration method, the mutation of that reference would be considered a side effect.
Referential transparency / polymorphism
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment