What I'm looking here is more like a strategy that takes into account the entire persistence layer from the perspective of an Elm Architecture app.
If one doesn't need to store data remotely, one could simply either use just some transient model OR, use something like localstorage to persist some small bits of data with an update on every relevant change to the model. But when one needs remote data, suddenly it comes the problem of how do you approach solving the fact that there is state on the server and state on your computer and there are performance considerations in retrieving the entirety of the state. I'm more interested in how one would solve this in a multilayer system where the actual remote persistence is abstracted from the app. The actual remote persistence might be implemented with REST, or it might be some kind of websockets thing. It might involve a SQL database, or maybe a NoSQL database. It might be something like Datomic. I'm interested in how would one implement this abstraction, this *separation of concerns*. On Mon, Oct 24, 2016 at 5:46 PM, 'Rupert Smith' via Elm Discuss < [email protected]> wrote: > On Wednesday, October 19, 2016 at 9:54:44 AM UTC+1, Peter Damoc wrote: >> >> What options are there? >> > > The option that probably has the most traction is Swagger (now the Open > API Initiative) : > > https://openapis.org/ > > In terms of what has been discussed here, graphql or PostgREST are more > sophisticated than Swagger, but Swagger may have relevance if its following > grows. That said, the news section in the open API initiaive is > dissapointingly empty beyond the initial announcement of the initiative: > > https://openapis.org/news > > I would find a json-schema -> Elm decoders/encoders/records converter > useful and the ability to generate the relevant Http boilerplate needed to > call endpoints defined in Swagger. It would be nice if you could pick up a > Swagger definition and create an Elm client module to work with that API > with next to no effort. > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
