Hello folks.
I released a new library/package called elm-express:
https://package.elm-lang.org/packages/eberfreitas/elm-express/latest/
It is an attempt of creating something that allows me to write backend apps with Elm. I wrote a little bit about why I did it here:
Would love to hear your thoughts about it if there are any. Thanks!
Very excited to give this a try 
Time to dust off the old notes. Thanks for your efforts on this. Looks great.
Very cool! Are there examples for how to do things like read data from a file, database, or some other form of persistence? For example fetching a user’s profile. Thanks!
Not directly, but on the example app you have two examples for using ports and tasks:
You could use the task to make API requests to fetch user data, or ports/subscriptions if your Node.js app has database access.
Edit:
I would favor Tasks as they are easier to use with the library. I’m almost sure we can use something like taskport to hack for a “better” ffi. Just didn’t want to include that into the framework.
Tried it out now. This is a really cool package.
I tested creating a simple in memory CRUD API.
(Lamdera-style: Persist state via port and load state via flags on startup)
I defined something like this: type alias Model = { projects: Dict String Project } and gave this as ctx to the Application.
( I renamed the “Connection-Model” from the example to “Endpoint” to avoid nameClash )
If someone POST to the “/projects” endpoint I would like to add a new project in that shared model and return the new id in the response. (Using the elm model as a databse, no task or port needed)
But there seems to be no way to update the shared model (ctx) ?
Is there any way to have any application state in elm? Or does it have to be on the JS side?
Thank you so much for trying it out @Atlewee . Really appreciate it 
That is right. Currently the ctx is read only. I wasn’t sure which way to go there and I thought it would be best to remove restrictions in the future than adding one.
My thinking there was that ctx should be used for global read-only immutable things, like env vars and stuff. Also, I wanted to keep the return data from incoming and update pretty simple, but maybe ctx can be a part of Conn.
Another thing is that I’m not sure if allowing for the change of some global cross requests state might create problems with data being overwritten with older versions or race conditions.
I can definitly see why we would want a global shared state among requests… Need to think a little bit harder about it. What are your thoughts?
Nice work! The API looks really good. I’ll have to give it a try soon.
Tks @nateabele
I would love to get some feedback
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.