Well hey, the Absinthe Elixir library has you covered there!

If you use any of the immutable functional libraries in javascript then you’ve got the ideas of Elixir already down, if not then that will mean learning a bit new of a paradigm.

Elixir is worth learning due to the entire BEAM VM it runs on though, but honestly if your current system runs well and can be maintained without much issue I’d keep it. But if you want to learn a new way, or if you want to be able to scale well, or if you just likely want to shorten your code and improve maintainability then Elixir would be great to use. Just be aware of what you are doing, though porting an existing working project from something else to Elixir is definitely a good way to learn things.

Yep, Absinthe works with the Apollo client code just fine too!

Never heard of zeit’s, but deploying my elixir server’s is just running a single shell script then bouncing the server via systemd (which I could easily automate too, but haven’t yet because eh… easy enough).

Elixir is exceptionally well documented and has a fantastic community for sure!

But yeah, if your current thing works and you see it doing fine as it is in the future then I’d say just keep at it, only port it over if you want to learn. However if you see pain with it in the future then it may be worth porting to Elixir sooner.

I think many people here will say, yes

If you can spare the cash, I would recommend you get Elixir for Programmers (PragDave) though not to learn Elixir, but to get an insight into why working with Elixir and Phoenix is one of the most exciting ways to develop modern software …Elixir makes so many of the current best practices in development incredibly easy, making it a very natural fit it will make the hairs on the back of your neck stand up

The one caveat to this is GraphQL subscriptions. The solution that the Absinthe community provides for subscriptions relies on Phoenix Channels as the transport mechanism between a Phoenix server and the client. That means that the GraphQL client must work with the Phoenix Channels transport mechanism and an out-of-the-box Apollo client will use the websocket protocol of the Apollo Server by default.

The Apollo JavaScript client is flexible though, and the Absinthe community has used that flexibility to create a JavaScript Apollo client that handles subscriptions through Phoenix channels (see GitHub - absinthe-graphql/absinthe-socket: Core JavaScript support for Absinthe WS-based operations · GitHub). If you require subscriptions, and want to use the Apollo clients for other platforms (most notably the iOS and Android Apollo clients) they may require additional modification to tie into the transport that Absinthe Phoenix provides by default.

I came to Elixir a little more than a year ago from JavaScript and I still share your thoughts here. I spent 30 hours one weekend trying to just research deploying an Elixir/Phoenix application. I’ve asked once on Slack for tips and wasn’t really helped other than a few things like “just do [thing JS devs never deal with]” and it was hard to grok since JS is just so easy to deploy pretty much anywhere. I’ve read a lot of posts here and in every conference talk whenever they mention JS they always make it a joke so I think a lot of Elixir devs just look down on JS in general and haven’t had the pleasure of deploying it

Ideally I would have liked to keep asking more questions, but I feel like I waste everyone’s time when I ask how to figure out this deployment stuff. I ended setting up an ECS instance for an EC2 cluster, then added an RDS Postgres instance, set up all the security groups and stuff, and put it all behind an Elastic Load Balancer which came with all of its configuration. If anything breaks I’m screwed because I have no idea how it works or how I got it to work in the first place lol.

Anyways, I really hope you find the answer to the deployment story. I’m still looking.

Hmm I wonder how this factors in with cross platform frameworks - e.g. can I still use it for react native or vue-nativescript?

I’m afraid I do not have enough experience with either environment to say. I won’t let that stop me from speculating though. Based on what I do know, the data transport mechanism is generally a very small part of the overall system. Once the data has been squeezed from the server to the client through whatever pipe is used (Apollo’s socket protocol, Phoenix’s channel protocol… whatever) then feeding that data into the top of the React (or presumably Vue) data flow should be fairly straightforward.

I thought there was an apollo addon library that adds that though?

/me mostly uses graphql on the back-end for as much sense as that makes…

Ah yep that’s it! ^.^

It’s always seemed easy for me? Just release, bind it to systemd, and let it go. Building a new release is just release, copy into the systemd accessed location, and tell systemd to restart it. It’s the same as any other unix style server?

/me is thinking they should make a blog post about systemd deployments sometime…

I feel the same about deployments. Even though I’ve done it successfully, I don’t think it was that simple. You might want to look into https://nanobox.io/ – they offer a great and simple solution for deploying your apps.

Alternatively have a look at https://gigalixir.com/ or search our deployment tag.

@OvermindDL1 Please write that post

I think it would be worth mentioning what exactly are you building? Node stuff is “easy” as long as you don’t have to deal with having to offload work to other node processes to keep event loop from blocking. The deployment story is easier for Node but deployment is a kind of thing you setup hopefully once vs development that you have to do every day. As you mentioned Elixir ecosystem is much less fragmented and it is very easy to get going vs Node. The most refreshing thing to me is the ability to write sync code and block in Elixir so it’s much easier to reason about what is going on vs JS/TS. Async/await might look nice but you still better understand what is really happening behind that syntactic sugar. Also on large node projects arch. tends to get vary hairy I am working on large enterprise node app if it was done with Elixir it would literally be 1/4 the size and much easier to understand.

Regarding deployments, Gigalixir and Heroku are great if you don’t care about the underlying platform. You just push your code and they take care of the rest. (This is pretty much what Zeit Now is, so it is just as easy to deploy Elixir to a hosted service)

In my opinion, doing it yourself is far more satisfying, and allows you to take advantage of the full set of Elixir/Erlang features that come into play once your code is running, like hot code reloading for zero downtime upgrades.

For me the best way to deploy Elixir would be to setup a Digital Ocean droplet, install Elixir, PostgreSQL, and anything else you might need. Then setup edeliver to push your code to the server and run it.

You could also just use Docker to build an image of your project, and Docker Compose to orchestrate the services needed and where to deploy, or build a release manually and use scp to copy it over to the server (provided your local machine and the target machine share the same environment).

It all might sound complicated, but a lot of the steps mentioned above would also have to be performed for Node as well, if you are not deploying to a ready-made PaaS.