Skip to content

Instantly share code, notes, and snippets.

@tonymorris
Forked from benkolera/masterplan.md
Last active June 18, 2019 00:23
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 tonymorris/aa382886c793a570c4b31436292493d1 to your computer and use it in GitHub Desktop.
Save tonymorris/aa382886c793a570c4b31436292493d1 to your computer and use it in GitHub Desktop.

Our web applications are getting increasingly more complicated. They are becoming more distributed and increasingly powered by combinations of complex, constantly changing and large datasets. All while users are increasingly more connected and want the latest information instantly without any slow page loads or stale information.

To address this, developers have turned to layers of caching and single page applications so that there are layers of aggregated and preloaded state as close to the user as possible, to be immediately available when it is requested. This comes at a high cost: it is very difficult to invalidate or update those caches when the upstream information changes. This is especially problematic when the stale caches can accidentally cause real bugs rather than show stale data to users.

The big issue here is that we're not just caching expensive-to-compute static data. We are caching data that changes over time. There are a number of architectual patterns that can be applied, but to date, nothing has really commoditised them into a framework. Martin Fowler came up with Event Sourcing in 2005 [1], which indicates that this goal may not be possible with mainstream non-functional programming techniques (despite a number of successful specialised implementations of the Event sourcing idea: git being the most popular).

Functional Reactive Programming is a programmatic framework around time varying state that implements an airtight semantics over time varying state that is updated by a stream of events. Like pure functional programming, time varying values cannot be read outside the FRP part of the program, meaning that consumers of the data must be built in a way that accepts the time varying nature of the data and will have the new value flow to it as soon as the upstream data changes. Reflex is the FRP implementation with the most production use to date (June 2019).

Most of reflex's success and use has been in the browser frontend Single Page Application (SPA) space. This makes a lot of sense as browser UIs are event sourced by the very nature of javascript execution on a web page. Our frontend can now be built in such a way that time varying state can be safely abstracted over in our UIs, but our backend architecture has not caught up yet. Backends are still being written in request/response style which means that any attempts to try to notify clients as soon as data changes has been terribly ad-hoc.

I wish this world to change. If we have a full stack application framework that is FRP from top to bottom then we'll live in a world where there are no stale caching bugs and clients get updated as soon as data changes with the smallest possible incremental updates. At this point, I think that we have a solid foundation for the next decade of web apps that are increasingly more complex and aggregating increasingly needed to be powered by more frequently changing, large pools of distributed data.

Obsidian have done a lot of the pioneering work for this, but I want to do what I can to help out document, evangelise and support these efforts in any way that I can.

[1] https://martinfowler.com/eaaDev/EventSourcing.html


Paraphrased to the version with many shortcuts that I just told Rizary:

I have been thinking for a while that it is too hard to convince people that reflex-dom on it's own is a good idea. It's awesome if you know FRP, but it's a lot of effort to grok FRP to get to something that for a small app doesn't give you that much compared to an Elm/Miso thing. I can empathise with the folk that go "that looks really hard and I don't see what it gets me". However, once you start adding this new stuff (kinda new: it's been done kinda in a manual way with Rhyolite for a bit) it starts getting super compelling when your FRP superpowers give you something way better than GraphQL almost for free just by the powers that haskell and FRP give you. Then you start having FRP's killer app and it sounds awesome. Every other implementation of Event Sourcing has been some ad-hoc specialised implementation but the magicians at Obsidian seem like they are on the cusp of automating and commoditising it. I think even if you have the nicest possible Elm and GraphQL backend, you are probably a long way from the superpowers of what I think these new reflex backends can take us. That's extraordinarily cool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment