part 1 of this blog post series introduced the db-view approach and discussed its trade-offs. part 2 showed a TodoMVC example app that uses the db-view approach. This part explains how to do side effects in a db-view application.
Side effects are a necessary evil within most applications. The todo app discussed in part 2 would be pretty useless without side effects, like marking a todo as done or creating a new one. Functional programming tries to push these side effects to the "edges of the system", meaning it tries to maximize the percentage of side-effect-free (pure) functions. Datomic takes this to a whole nother level by applying this principle to create a database system that only needs one stateful place.
In part 1 I've talked about the db-view approach that has different trade-offs in comparison to a REST API. In essence you decide to develop your backend API endpoint with a single frontend app in mind. Thereby your API endpoint and frontend tends to stay simple.
This part is about the example app that I've developed for this blog post series. It implements the well-known TodoMVC example, an app to manage todo items. In comparison to many other TodoMVC implementations out there, it implements the frontend and the backend. It is a core principle of the db-view approach that you design your API exclusively for one frontend app, instead of providing a more generic API. The latter one introduces various complexities which needs to be solved, despite the fact that they are not strictly required for your app.
In my previous blog post series Approaching The Web After Tomorrow I've talked about how I tried to implement the idea that Nikita described in his blog post called The Web After Tomorrow.
In part 1 of Approaching The Web After Tomorrow I talked about how we used DataScript, Datomic and Clojure(Script) to build a real-time app for our SaaS product Storrito.com and what performance challenge the first implementation yielded. Part 2 was about some ideas I had to solve this performance challenge. Finally Part 3 was about what difficulties you can avoid by creating your API for exclusively one frontend app and that big organizations tends to separate developers into frontend and backend developer teams.
This blog post series is about my attempt to implement The Web After Tomorrow that Nikita described in his blog post back in 2015.
In part 1 I talked about how we used DataScript, Datomic and Clojure(Script) to build a real-time app for our SaaS product Storrito.com and what performance challenge the first implementation yielded. Part 2 was about some ideas I had to solve this performance challenge.
This blog post series is about my attempt to implement The Web After Tomorrow that Nikita described in his blog post back in 2015.
This part is about some ideas I had to solve the performance challenge that was described in part 1.
