This is a Phoenix 1.3 port over of the Phoenix 1.2/Elm Address Book application, created by Ricardo García Vega over a series of posts over at his blog (original app codebase).
See the original
branch for the as-close-to-the-original-as-I-could-get-it
version of the codebase. Other branches will likely have personal tweaks to the
codebase in it.
git clone git@github.com:paulfioravanti/phoenix-and-elm.git
cd phoenix-and-elm
mix do deps.get, ecto.create, ecto.migrate, run priv/repo/seeds.exs
npm install --global elm
To install npm dependencies in package.json
:
cd assets
npm install
To install Elm dependencies in elm-package.json
:
cd elm
elm-package install
From the project root directory:
mix phx.server
Open http://localhost:4000 in a browser.
- The introduction of Contexts into Phoenix 1.3 required some re-structuring
of the application to get it working as expected. I made the decision to put
Contact
behind anAddressBook
context. - I used Create Elm App to generate the Elm app under the assets directory, so its structure is slightly different to what is in the original.
If you want to use Create Elm App to have it generate an Elm app in your
Phoenix 1.3 project's assets/
directory, you can follow these steps:
npm install create-elm-app --global
cd assets
create-elm-app elm
The rest
branch of this repository (which also the base branch) contains
code covering the first five sections of the tutorial. In other words, up to and
including Implementing Elm routing, so the communication between back
and front ends is done with REST requests via controllers.
The websockets
branch of this repository contains code covering all
sections of the tutorial. In other words, up to and including
Phoenix and Elm WebSockets support, so the communication between back and
front ends is done with Websockets requests via channels.
The graphql
branch of this repository used the REST version of the app as
a base, but added GraphQL. So the communication between back and front ends
is done with GraphQL requests via resolvers.
The rest-refactor
branch of this repository contains the same contents
as the rest
branch, but was refactored to reduce coupling between parent and
child modules based on information gleaned about the project using
elm-module-graph.
Code from the rest-refactor
branch is not currently deployed.
Heroku was originally used to deploy each branch to it's own app. The git remotes look like this:
$ git remote -v
heroku-graphql https://git.heroku.com/phoenix-and-elm-graphql.git (fetch)
heroku-graphql https://git.heroku.com/phoenix-and-elm-graphql.git (push)
heroku-rest https://git.heroku.com/phoenix-and-elm-rest.git (fetch)
heroku-rest https://git.heroku.com/phoenix-and-elm-rest.git (push)
heroku-websockets https://git.heroku.com/phoenix-and-elm-websockets.git (fetch)
heroku-websockets https://git.heroku.com/phoenix-and-elm-websockets.git (push)
origin git@github.com:paulfioravanti/phoenix-and-elm.git (fetch)
origin git@github.com:paulfioravanti/phoenix-and-elm.git (push)
So, deploying each version of the app out to Heroku meant deploying its branch out as the master branch:
git push heroku-rest rest:master
git push heroku-websockets websockets:master
git push heroku-graphql graphql:master
I wrote a couple of blog posts that use this application as an illustrative example:
- Migrating a Phoenix and Elm app from REST to GraphQL: This blog post
covers migrating the application API from using REST, to using GraphQL, and
shows the steps needed to get the application from the code base in the
rest
branch, to the codebase in thegraphql
branch. - Graph-driven Refactoring in Elm: This blog post covers decoupling parent
and child modules and refactoring Elm applications, and shows the steps needed
to get the application from the code base in the
rest
branch, to the codebase in therest-refactor
branch.