Closed Dylanb-dev closed 2 years ago
lamdera evergreen
my understanding of "evergreen" refers to the "msg migration" feature that allows deploying of new versions of the app and have the safety that a stale SPA instance on client browsers would still be able to auto upgrade itself and thus not lose a msg between client/server communications
elm-webapp does not come with "msg migration" feature. however as of 3.0.0, the generated MsgFromServer
comes with ClientServerVersionMismatch
which is leveraged to know that the client/server is out of sync and present a "Please reload this browser page" message to the end user
persisting data
elm-webapp does not persist the "model" of the server (aka serverState
), unlike Lamdera.
While you can still code to update the model of Server note that the values are only held in memory and is lost when the Server process exits. Doing so is still worthwhile during development though, enabling quick iteration of the app without messing with db & schema
For reference, in my own production apps, serverState
is only ever used to hold immutable server config. For persisting data, my Server code
Thanks for the write up.
The elm-webapp solution for the frontend is great and I wish more frameworks adopted it by default.
I was curious how much of lamdera was borrowed by elm-webapp and agree persistence solutions are outside the scope of the project. Thanks for the examples on what is the correct way to get persistence in elm-webapp.
Hey, @choonkeat .
What do you think about putting this informations about ServerState
in the README?
About it not being persisted and some alternatives to do it, like you said about making HTTP requests to DynamoDB or to Hasura.
Good idea @Massolari ! I've written it down in README 🙇
Or something like it for persisting data?