On Monday, October 24, 2016 at 9:15:14 PM UTC+1, Peter Damoc wrote: > > I cannot provide sample code because I don't have a clear idea how the API > could look. > > Think about the role that a ORM is playing. What I want to understand is > what would a functional equivalent would look like in Elm. > > What would sit above graphQL or REST or some other lower level tech? > > Another way to look at this would be to take the Json.Decode/Encode as > example and imagine that one has the equivalent of a Decoder only that it > would be some kind of a descriptor used by some lower level library that > does the queries based on that descriptor data. > Maybe this descriptor uses something like Datalog. > > Another way to think about this is to try to imagine what would it take to > reduce the cognitive overload of a beginner that does not really care that > much about how the data is retrieved/saved remotely but cares to have the > functionality present. >
I think the model that has the lowest 'cognitive overload' for a beginner is to simply work with the request/response model of HTTP, and to request data when needed, and POST data when you want to update something. Its a pretty obvious abstraction and fits nicely with Elms event handling. Again, it comes down to Parnas principles of modular design. An API provides a minimal interface to the server code that sits behind it. To make use of that servers functionality, you only need to comprehend the API and what it does - the details are irrelevant. The API provides an abstraction that simplifies away the details. I would say that persistence is not really the concern of the UI. It is nice to experiment with clever technologies that let the UI code build whatever query it needs, or update whatever data it needs but you have to remember that most of the time your UI is not runnning in a trusted environment - in the case of Elm/javascript its running in someones browsers. Therefore it is almost a necessity that you create an API and think carefully about what data can be seen through it, and what data updated by whom. That said, Overmind has provided some clear details of how access rights to data are protected when using graphql. Not sure if PostgREST provides any assistance with access rights? Coming back to the 'cognitive overload'... I have found that simply setting up and working with the HTTP requests in Elm is a lot of work - you need encoders, decoders, functions to help build the requests, functions to help decode the responses and deal with errors, msgs to pass to update functions to update your model based on responses and so on. There is a lot of boilerplate in simply working with an API, although this has nothing to do with databases and persistence as such. I have used code generation techniques to handle all this boilerplate for me, which makes for a much more pleasant experience. So when it comes to working with an API, I am satisfied that it can be done much more simply than it first appears. Another simple model for persistence that should work with Elm is to simply serialize the application state and store it. So long as you don't have any functions in your model, it should be possible to write an encoder/decoder for the entire model. Why not just freeze dry your entire application state to some key/value store (on every update), then you have a simple way to rehydrate the whole application after a period of inactivity? If you want to get fancy, just as Elms virtual DOM is only updated as required, some technique to only save the deltas to the model, but be able to faithfully restore it in its entirety might be feasible? Perhaps draw inspiration for this from the 'event sourcing' pattern. Is this more the sort of thing that you are looking for? -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
