This Monday I held a talk at my company Agical presenting a sketch of an interesting web application architecture. One could call me a Cognitect fan-boy, but I'm proud of it. Before getting to the technical stuff I discussed a bit on modelling things.
I've always think modelling things are super complicated to get right, especially with ie SQL or single tables like Excel. Probably I try to take to many things into account at the same time, but hey, the world is complicated, so why shouldn't I try to model it at least a bit more like how it really is?
The architechture, then.
Something along these lines:
React/Om talking with DataScript via core.async channels and to the server.
The server running Pedestal and Datomic (and whatever other data source necessary - Datomic would be the transaction engine).
It's a bit bold to claim that even database queries could be reused in the client, this is likely not the case, but the model could be similar in structure on both client and server.
The controller in the client and server would consist of a core.async pub/sub setup, although it feels a bit hard to make sure everything is setup right, it feels a bit like we are in multimethods all over again.
The start and stop of the application would be taken care of through Component.
And off we go!
Extremely useful resources
for preparing this talk was
CatChat (a DataScript example app)
David Nolen's blog posts of both core.async and Om
Om intermediate tutorial on Datomic integration
O'Reilly's Webinar about Pedestal with Ryan Neufeld (2 h YouTube video)
Things I stumbled upon was
Trying to visualize even a simple Pedestal router setup was quite error prone. The interceptors got wrong and all over the place.
Setting up ClojureScript to compile Om. It's mostly the Leiningen project.clj options that's hard to understand. Validation of options or warnings when unused options occur would be useful.
Programming core.async channels in the nRepl often locked up the repl in strange ways, from which I had to re-require the namespaces.
Getting my head around Om and it's quite messy formatting syntax, especially when it comes to catching events from various things. Shouldn't one put small functions inside the elements maps? Maybe listeners should be defined separately from the DOM-structure.
Maybe there's even room for an abstraction over the events, because now most of it is quite OO that one has to get take back tree-element by element.
There are many fascinating papers about CRDT and similar techniques, but still it's not clear on how to structure the events from the application and the event "schema" between client and server, especially with regards to CRDT at similar. An especially delicate thing close to my heart is the ability to show where other people are editing, so edits not collide to badly.
Pub/sub "reactions" I think could be replaced with transducers.