Building a full stack application with Elm

[David Dawkins]

Those of you building real world apps with Elm, what is your back-end solution?  (Eg, Apache + PHP, or Node+Mongo, etc)

Many thanks

[Matthew Griffith]

I'd imagine you can use whatever framework you'd like, just get data to the frontend using ajax.  I haven't built it yet, but I'm planning on a small real world elm app using http://www.spock.li/ which is a haskell web framework.  

So, I'd say, it depends on what you're building and what you already know.  For databases, I default to using postgres unless I have a good reason to use some other solution.  For web frameworks my go to would be Flask(python), or Spock(Haskell).  For large stuff I use Yesod(also haskell).  

However what you already know is a big factor in what you should pick.

[Evan Czaplicki]

I know NoRedInk's backend is in Ruby. They have some tooling to help everything fit into their build system. Not sure what fraction Richard has gotten a chance to open source at this point though.

I have personally used Haskell's Snap for both elm-lang.org and package.elm-lang.org, but I'm trying out node.js for a project now and things are going well. (It's crazy how much easier it is to use!!!!)

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Dawkins]

Thanks guys. I'm encouraged to see node mentioned. I would like to get the time to create a soup-to-nuts tutorial based on node+Mongo+Elm that creates a todo application in stages, just as the Meteor boys do. It will be a great teaching experience for me. I'm still a little lost to be honest.

[Max Goldstein]

If you were okay not sharing code between the frontend and the backend (something Node people will promote), you could probably pair Elm with any RESTful API, whether Rails, Node (express?), or Python Django. So it's probably a matter of what you're comfortable with.

As an aside, I've noticed a pretty big gap in the communities and my own attitude when confronting small refactoring jobs, across the three languages I use the most. That is, for improving code a few lines at a time:

JavaScript: Yeah, I can see how awful this is, but there's no good way to improve it without a global state or losing the variables from the closures of nested anonymous functions. Besides, it's fewer bytes this way.

Ruby: This is decent, but I can extract this to a private method, apply tell-don't-ask, and use a null object to eliminate this code smell. Now that we obey the single responsibility principle without violating the law of demeter, the code is DRYer and easier to test.

Elm: So yeah, define our action and state types, the initial model and step function, put it together with a foldp, and write a downstream render function that's mapped over the model in main. Every program you write will follow this basic architecture, and it's really easy to extract out helper functions and constants. Done.

[Evan Czaplicki]

David, that'd be sweet!

I'm actually exploring node.js because I'd like to get Elm running there at some point. I made a couple fixes recently that make it so Graphics.Element and elm-html don't cause a meltdown on node, but I'll be pushing this farther with tasks in the coming months :)

Point is, I'd say go for that if that's your preference anyway!

In terms of "what backend would be best for this community?" I'd say node.js is probably the best strategically. The goal of this strategic choice would be to help the most people accomplish their goals more quickly. (achieved my goal > any other detail)

--

[David Dawkins]

Evan,

In my understanding, node would "just" be a backend application, written in JS, serving the Elm application, and handling client ajax/rest commands, perhaps

reading and updaing a mongo db.

Ideally (?), we would implement the backend with Elm too; write Elm that can work with Mongo, serve the client files, etc. I can almost see how gulp would serve

us here (though I have no idea how Elm could talk to Mongo just yet, or implement client-server requests, etc).

But - at what point would node ever be executing Graphics.Element code? I feel I'm missing something fundamental here. 

I'm glad you like the idea though, I'm inspired; albeit a little under-qualified.

[Evan Czaplicki]

In my understanding, node would "just" be a backend application, written in JS, serving the Elm application, and handling client ajax/rest commands, perhaps reading and updaing a mongo db.

Yeah, that'd be a fine way to start out. I'd do that first. (I'm experimenting with this myself just to know what it's like.)

 

Ideally (?), we would implement the backend with Elm too; write Elm that can work with Mongo, serve the client files, etc. I can almost see how gulp would serve us here (though I have no idea how Elm could talk to Mongo just yet, or implement client-server requests, etc).

Longer term, I'd like to see this, but it's quite a ways off I think. I need to continue with improvements to tasks before this would feel really excellent I think.

But - at what point would node ever be executing Graphics.Element code? I feel I'm missing something fundamental here.

Oh, I was just referring to this and this. They used to come up if something you depend on referred to them, so not all code could run on node for kind of silly reasons. It's not super relevant, but general evidence that I'm starting to take steps towards node :)

[David Dawkins]

But - at what point would node ever be executing Graphics.Element code? I feel I'm missing something fundamental here.

Oh, I was just referring to this and this. They used to come up if something you depend on referred to them, so not all code could run on node for kind of silly reasons. It's not super relevant, but general evidence that I'm starting to take steps towards node :)

 

OK :-) You're thinking (coding) ahead to the point where we are running Elm in the back end.

 

[Adam Kowalski]

In my opinion some solutions such as firebase and parse are fantastic as they allow you to focus on content creation and essentially have a real time database at your disposal with no extra effort.  I'm not sure if there are any elm specific bindings, but both of those work great with just plain old http requests.  While I have not actually tried hooking this up maybe you could look into elm-http and get everything working together.

[David Dawkins]

Great ideas, but I don't even know how to make an elm app from scratch yet, other than typing stuff into the Elm online editor. I feel like I have seen only the barest fragment of what it takes to use Elm in an app. Compare this to Meteor (try it right now if you haven't already( where they show you everything, take you through the steps and then host the app. I want that experience for new Elm users (for me!!). That's what I'd like (us all) to be working towards.

[Corey Trampe]

I'd like to explore a Haste.app kind of solution, where a (conceptually) single program is compiled for both the client and the server.

I think it maps very well to event sourcing, immutable infrastructure, and continuous deployment.

--

[David Dawkins]

A small milestone for me - I've just created a "Hello World" app based on node, using elm-make and elm-html-and-js. My next steps are:

1. Use Gulp to automate the "elm-make then copy elm.js to public/js" part 

2. Apply styling, using Semantic UI

The workflow and platform I've created with node is nothing that elm-reactor can't do, but understanding how it fits together is big

deal for me. I will feel like I know how to substitute elm for whatever client framework is being used.

I plan to create a page detailing my steps, in case anyone else is interested.

[Mike Clark]

In terms of workflow automation, I've been using Grunt with Richard's excellent elm-grunt package:

  https://github.com/rtfeldman/grunt-elm

Here's how to get everything installed:

  npm install -g grunt-cli --save-dev

  npm install grunt --save-dev

  npm install grunt-contrib-watch --save-dev

  npm install grunt-contrib-clean --save-dev

  npm install grunt-elm --save-dev

And here's a simple Gruntfile.js you can use as a template:

  module.exports = function(grunt) {

    grunt.initConfig({

      elm: {

        compile: {

          files: {

            "your-file.js": ["YourFile.elm"]

          }

        }

      },

      watch: {

        elm: {

          files: ["YourFile.elm", "YourOtherFile.elm"],

          tasks: ["elm"]

        }

      },

      clean: ["elm-stuff/build-artifacts"]

    });

    grunt.loadNpmTasks('grunt-contrib-watch');

    grunt.loadNpmTasks('grunt-contrib-clean');

    grunt.loadNpmTasks('grunt-elm');

    grunt.registerTask('default', ['elm']);

  };

Then you can run "grunt watch" to automatically recompile when a file changes.

 

Anyway, perhaps that helps!

Mike

[David Dawkins]

Yes it does! Thank you. I've managed to get something working with gulp (it seems to be the NKotB), but it's rough at the moment. I'll check this out too.

[Mike Clark]

Cool - glad that's useful. Perhaps I should write it up on our blog. This solution has been working great for me, so I haven't bothered to try switching over to Gulp or whatever we're supposed to be using as of 5 minutes ago.  :-)