3 ms·

I think all logic should be in the db, but I think we just don't have the right databases. In my ideal world, my database would know about all the queries I wa

I think all logic should be in the db, but I think we just don't have the right databases. In my ideal world, my database would know about all the queries I want to run, and it would choose query plans based on this knowledge to effectively cache things, and handle streaming changes to queries. You also want to be able to visualize the full data dependency graph of all your data, i.e. when this value changes, what else changes. We need to get rid of all these poor-fitting abstractions between the database (REST, GraphQL, etc.). Your client code should work with a model exactly the same as how its stored in the database. In fact, your entire database should be able to run client-side in the browser. This is what is holding us back. This would allow optimisitic updates, and easy local/offline apps. I think people usually avoid this because they like to chose a different language for their backend and the thought of getting this to run in a browser is frightening. Just think how much easier your life would be if you had direct database access in your browser from your client code, and you didn't have to worry about apis, orms, etc. and that it was secure, and synced automatically. And now think about your current application you work on, and the difficulty in achieving such a thing.

nschiefer 3y ago
(Disclaimer: I’m plugging my own work here ;-)) You might enjoy this project, which ties to do basically exactly what you described: stick everything in a database and let it drive the app: https://riffle.systems/essays/prelude/ https://riffle.systems/essays/prelude/ It’s still very much a research prototype but we should have some more writing out soon.
- PKop 3y ago
  Good essay. Particularly with web development, there is complexity around bridging the gap between server and client, and data crosses this chasm through serialization which exacerbates the problem and limits expressiveness of server languages, requiring massive duplication of code simply to serialize and duplicate on client what is present on server if one wants all the power of client interactivity and API's. This is a big value of recent server-centric frameworks like Phoenix LiveView that provide ability to have code and data co-located and not have to duplicate so much on client and server as with SPA's while attempting to maintain some base level of client interactivity. But seems always a tension between leveraging the full power of client and full power of server. You might find this article [0][1] informative. It disputes the idea that UI's are "pure functions of the data/model" in a compelling way, and points to this incorrect assumption as having introduced some complexity/pain in how frameworks like React work. [0] https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio... [1] https://news.ycombinator.com/item?id=31979347 https://news.ycombinator.com/item?id=31979347
  - vaughan 3y ago
    That article was a great read. > What is a (somewhat) pure mapping from the model is the data that is displayed in the UI, but not the entire UI. This line was interesting to think about. React added so much complexity and perf issues, and I really don’t know what was so bad about something like Backbone / Backbone.Marionette. I find that in React I want all component props and data to come from an external store via subscription, instead of being passed down some tree. My UI is stable.

nschiefer 3y ago

(Disclaimer: I’m plugging my own work here ;-)) You might enjoy this project, which ties to do basically exactly what you described: stick everything in a database and let it drive the app: https://riffle.systems/essays/prelude/ https://riffle.systems/essays/prelude/ It’s still very much a research prototype but we should have some more writing out soon.

PKop 3y ago
Good essay. Particularly with web development, there is complexity around bridging the gap between server and client, and data crosses this chasm through serialization which exacerbates the problem and limits expressiveness of server languages, requiring massive duplication of code simply to serialize and duplicate on client what is present on server if one wants all the power of client interactivity and API's. This is a big value of recent server-centric frameworks like Phoenix LiveView that provide ability to have code and data co-located and not have to duplicate so much on client and server as with SPA's while attempting to maintain some base level of client interactivity. But seems always a tension between leveraging the full power of client and full power of server. You might find this article [0][1] informative. It disputes the idea that UI's are "pure functions of the data/model" in a compelling way, and points to this incorrect assumption as having introduced some complexity/pain in how frameworks like React work. [0] https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio... [1] https://news.ycombinator.com/item?id=31979347 https://news.ycombinator.com/item?id=31979347
- vaughan 3y ago
  That article was a great read. > What is a (somewhat) pure mapping from the model is the data that is displayed in the UI, but not the entire UI. This line was interesting to think about. React added so much complexity and perf issues, and I really don’t know what was so bad about something like Backbone / Backbone.Marionette. I find that in React I want all component props and data to come from an external store via subscription, instead of being passed down some tree. My UI is stable.