Meteor in Front, Phoenix in Back

Hey all,

I’ve been interested in Elixir and the Phoenix framework for a while now. I thought I’d put on my mad scientist hat and try to build out a replacement backend for an existing (simple) Meteor application using Phoenix.

I’m breaking the process into two articles. The first article goes through the process of splitting a Meteor application in half and dropping the front-end into a new Phoenix project. From there we replace the DDP pub/sub mechanics with a Phoenix Channel.

I found the whole process of splitting off the front-end of a Meteor app surprisingly easy. If you’re not using a production build, you can continue to use all of the niceties of Blaze, ReactiveVars, MiniMongo, etc…

I wouldn’t recommend doing this in a “real” project, but hopefully you find it as interesting as I did. Part 2 coming next week!

1 Like

Why use Phoenix as a backend, instead of Meteor?

Yes… Why @pcorey ? what is the real benefit ?

This was mostly just an exploratory project. Why climb the mountain? Because it’s there.

If you’re interested in the general pros and con of Phoenix as a web framework, check out the Phoenix megathread.

So far, I’ve enjoyed working with Elixir and Phoenix. In the future I’ll most likely write more about my experiences with it and more sane/realistic migration paths.

1 Like

Hey all,

Part two is up! This article goes through the process of replacing DDP with Phoenix Channels, and wiring the resulting data up to Minimongo on the client.

Piggybacking on Minimongo is pretty interesting. It means you could keep the majority of your Meteor app intact while syncing data from any other sources or serves. I might play around with using the Phoenix Channel npm library to do this in an existing Meteor application.

2 Likes