Re: deployment.
+1 for https://nanobox.io (deploying to Digital Ocean)
We are using for it staging & production deployment, works AMAZINGLY well. (Large Elixir/Phoenix/Elm app/site). Highly recommend.
And yes, switch to Elixir/Phoenix (and Elm!). You’ll be super-psyched.
I also came to Elixir from Node.js and I shared the same issues that you mentioned with Node.
Fragile deps, manual wiring all the different libs.
In Node.js its really easy to get started, but is harder to maintain the system in the long run.
There’s is a learning curve, but once you it “clicks” you will never want to go back 
If you’re just getting started, I suggest you make your Elixir app stateless (just like in Node.js), don’t use ETS or try to hot-code reload, keep all your state in external DB (Postgres, redis) it will make your life easier when trying to deploy your app.
Once you feel comfortable, you can try the cool features of Elixir 
TLDR: My biggest regret was not switching to elixir sooner. I suggest following the udemy course by Stephen Grider. It’s a bit old, but it should give you enough to decide whether you want to make the leap or not.
I also came from node (nextjs + redux + mongodb + heroku) for many of the same reasons.
My current project is Elixir + phoenix + react + redux + postgres (for users) + arangodb (for graph data) + graphql inside arangodb. I don’t bother with absinthe, just send a POST request with a string.
For my own project I wanted something really performant, and the js crowd seems to think that js is performant because it’s async. But dealing with async was a huge pain my rear. Especially when you start using things like mongoose, where it uses it’s own promise library, but parts of it you can do with async/await (promises), but there’s the occasional undocumented thing in mongoose that ONLY works with old school callbacks… That lead to a great deal of frustration.
Elixir is more performant. WAY more. And its async system (processes) is WAY easier to reason about. Processes are also truly asyncronous, while the js event loop is technically just a highly optimized, yet synchronous system.
Then you have immutability. I remember the time I spent days trying to figure out why my array was changing by itself. Oh, you used an Array.prototype method on a different array? Too bad!
That is not an issue in elixir.
Or how about setting things up. Expressjs is awesome because it’s so lightweight and lets you roll your own stack… but eventually I found that to be its greatest weakness. There’s several different ways to do anything in node. When you look for help, you often have to explain your whole setup, and pray that someone had the same setup with the same problem.
Elixir comes with testing. I find it better than jest, jasmine, or mocha.
Elixir has a rails-like framework (phoenix). Built in CSRF validation and sessions, ORM, and an intuitive organization of code. Of course if you really want to roll your own, that’s still easy enough.
Hi, I switched from Node to Elixir. I am generally happy with the switch, but it really just depends on what your needs and expectations are. I personally really like the coherence of the community and the batteries-included approach of Phoenix. The community has basically taken the opinionated stance of Rails, but fixed most of the shortcomings.
Anyway, I’m sorry people are not answering your questions seriously. We all have to start somewhere and it’s very frustrating when people trivialize these challenges. I went through some of these struggles myself. Let me tell you my setup, and I hope it helps you out.
I am essentially doing the following for my Phoenix application:
My Dockerfile looks something like this:
FROM elixir:1.7.1-alpine
ARG APP_NAME=my_app
ARG PHOENIX_SUBDIR=.
ENV MIX_ENV=prod REPLACE_OS_VARS=true TERM=xterm
WORKDIR /opt/app
RUN apk update \
&& apk --no-cache --update add nodejs nodejs-npm make g++ python git imagemagick \
&& mix local.rebar --force \
&& mix local.hex --force
COPY . .
RUN mix do deps.get, deps.compile, compile
RUN cd ${PHOENIX_SUBDIR}/assets \
&& npm install \
&& ./node_modules/brunch/bin/brunch build -p \
&& cd .. \
&& mix phx.digest
RUN mix release --env=prod --verbose \
&& mv _build/prod/rel/${APP_NAME} /opt/release
FROM alpine:latest
RUN apk update && apk --no-cache --update add bash openssl-dev imagemagick
ENV PORT=8080 MIX_ENV=prod REPLACE_OS_VARS=true
WORKDIR /opt/app
EXPOSE ${PORT}
COPY --from=0 /opt/release .
CMD ["/opt/app/bin/my_app", "migrate_seed_and_start"]
My bitbucket pipeline config looks something like this
image: elixir:1.7.1-alpine
pipelines:
default:
- step:
name: Test
script:
- apk update
- apk --no-cache --update add coreutils nodejs nodejs-npm make g++ python git imagemagick bash curl tar
- MIX_ENV=test mix local.rebar --force
- MIX_ENV=test mix local.hex --force
- MIX_ENV=test mix deps.get
- MIX_ENV=test mix deps.compile
- MIX_ENV=test mix ecto.create
- MIX_ENV=test mix ecto.migrate
- mix test
services:
- database
- step:
name: Build and Deploy
trigger: manual
script:
- apk update
- apk --no-cache --update add coreutils nodejs nodejs-npm make g++ python git imagemagick bash curl tar
# Installing gcloud
- curl -o $HOME/google-cloud-sdk.tar.gz https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-207.0.0-linux-x86_64.tar.gz
- tar -xvf $HOME/google-cloud-sdk.tar.gz -C $HOME/
- $HOME/google-cloud-sdk/install.sh
- source $HOME/google-cloud-sdk/path.bash.inc
- export PATH="$HOME/google-cloud-sdk/bin:$PATH"
- gcloud -v -q
# Installing kubectl
- gcloud components install kubectl -q
# Authentication
- echo $GCLOUD_API_KEYFILE | base64 --decode --ignore-garbage > ./gcloud-api-key.json
- gcloud auth activate-service-account --key-file gcloud-api-key.json
- gcloud config set project my_app
- gcloud container clusters get-credentials my_app --zone=europe-west1-d
- kubectl version
# Deploy
- source $BITBUCKET_CLONE_DIR/build.sh $BITBUCKET_BUILD_NUMBER
- source $BITBUCKET_CLONE_DIR/deploy.sh $BITBUCKET_BUILD_NUMBER
services:
- docker
definitions:
services:
database:
image: postgres:9.6
environment:
POSTGRES_PASSWORD: secret
docker:
memory: 2048
Also, you will notice a build.sh and deploy.sh file referenced here. These are small simple scripts I made. They look like this:
Build.sh
VERSION="$1";
if [ -z "$VERSION" ]
then
echo "Must specify a version to tag the docker container";
exit;
fi
docker build --no-cache -t "eu.gcr.io/my_app/my_app:$VERSION" . && \
gcloud docker -- push "eu.gcr.io/my_app/my_app:$VERSION"
Deploy.sh
#!/bin/bash
VERSION="$1";
if [ -z "$VERSION" ]
then
echo "Must specify a version to tag the docker container";
exit;
fi
kubectl set image deployment/my_app my_app=eu.gcr.io/my_app/my_app:$VERSION
Haha. I had to make the switch for my day job as the tech stack does not include Elixir :'(.
The things you take for granted in Elixir are serious concerns in the Node world. The obvious example being hogging the event loop. Also, while not limited to Node, immutability is something I greatly miss especially in a team environment. You never really know if an object will change out from under you if you pass it around to other functions. If I had to choose between “developer diligence” and “baked in”, I would chose baked in.