Pete Corey - Meteor in Front, Phoenix in Back

If you follow me on Twitter, it’s probably not surprise that I’ve been interested in Elixir and the Phoenix Framework for quite a while now. Coming from a Node.js and Meteor background, the promises of out-of-the-box reliability and scalability are incredibly attractive.

To get my feet wet, I decided to use Phoenix to build out a back-end for a simple Meteor example app.

Let’s put on our mad scientist hats and build a “Franken-stack”. We’ll be tearing the front-end out of an existing Meteor application, dropping it into a new Phoenix application, rewriting a Blaze template to use Phoenix Channels instead of DDP, and then writing a simple replacement back-end in Elixir.

Let’s get started!

Building Leaderboard

The Meteor example application we’ll be using is Leaderboard. It’s a very simple application that updates a single collection over DDP. The lack of moving parts makes it an ideal candidate for this kind of experimentation.

Let’s clone Leaderboard onto our machine and run it:


git clone https://github.com/meteor/leaderboard ~/leaderboard
cd ~/leaderboard
meteor

Fantastic! Meteor has built our Leaderboard application an moved the final build bundle into ~/leaderboard/.meteor/local/build. We’ll work more with that later.

Creating Phoenix Leaderboard

Now we need to create our new Phoenix project. Unsurprisingly, we’ll be calling this new app “Phoenix Leaderboard”. Let’s use Mix to create our application:


cd ~
mix phoenix.new phoenix_leaderboard
cd ~/phoenix_leaderboard
mix ecto.create

I’ll assume that you have a very basic understanding of a Phoenix project’s structure. If you don’t, check out the official guides for a quick introduction.

Now that we have our Phoenix project, we can start up our Phoenix server:


mix phoenix.server

Navigating to http://localhost:4000 should bring you to a “Welcome to Phoenix!” page.

Front-end Transplant

Now that we’ve laid our groundwork, we can move onto the more interesting bits of this experiment. Let’s get to work transplanting our Meteor front-end into our newly created Phoenix application.

Within our ~/leaderboard/.meteor/local/build/programs folder, our Meteor application’s font-end and back-end components are separated into the web.browser and server folders respectively.

Transplanting the front-end is really just a matter of copying over all of the required files within web.browser into our Phoenix application.

From web.browser, we’ll need the merged-stylesheets.css file, the entire app folder, and the entire packages folder. Let’s copy all of these into ~/phoenix_leaderboard/priv/static:


cp merged-stylesheets.css ~/phoenix_leaderboard/priv/static/
cp -r app ~/phoenix_leaderboard/priv/static/
cp -r packages ~/phoenix_leaderboard/priv/static/

Now we need to tell our Phoenix server that these files can be served as static assets. Let’s open up our lib/phoenix_leaderboard/endpoint.ex file and add them to our Plug.Static plug:


  plug Plug.Static,
    at: "/", from: :phoenix_leaderboard, gzip: false,
    only: ~w(app packages merged-stylesheets.css css js)

The last step of this transplant is to copy over the final HTML generated by our Meteor application. Head over to view-source:http://localhost:4000/ and copy the contents of this page into web/templates/layout/app.html.eex, replacing whatever’s already there.

That’s it!

After restarting our Phoenix server and navigating to http://localhost:4000/, we should see the (playerless) Leaderboard application!

Leveraging Brunch

Now that we’ve successfully transplanted out Meteor front-end into our Phoenix application, our next step is to wire it up to our server and start passing data.

To do this, we’re going to make some minor changes to the leaderboard Blaze template.

We’re going to be writing ES6 in this project, so we’ll want this transpiled into standard ES5-style Javascript. We can use Brunch, Phoenix’s default asset pipeline, to do this for us.

To leverage Brunch, I’m going to move the contents of priv/static/app/leaderboard.js into web/static/js/app.js, overwriting the current contents of app.js. Brunch watches web/static/js/* for changes and runs them through Babel, UglifyJS, etc… before moving it to priv/static/js/app.js.

Next, I’ll remove the self-executing function wrapper around the Blaze Template code, and import Phoenix’s socket module. Our new app.js should look something like this:


import socket from "./socket";

const Players = new Mongo.Collection("players");

Template.leaderboard.helpers({
  ...

Now we’ll change our app.html.eex file to pull in /js/app.js instead of /app/template.js:


<script src='<%= static_path(@conn, "/js/app.js") %>'></script>

Now that we’ve made these changes, we should still be able to load our new Leaderboard application without any problems.

Connecting to Channels

Now that we can freely change our leaderboard template, let’s remove our dependence on DDP and fetch player data from a Phoenix Channel instead.

Our plan of attack is to subscribe to a Channel when the leaderboard template is created and upsert any published players into our client-side Players Minimongo collection. By leveraging Minimongo, we won’t have to make any changes to our existing Meteor-style template functionality.

Let’s add an onCreated handler to our leaderboard Blaze template:


Template.leaderboard.onCreated(function() {
  this.channel = socket.channel("players");
  this.channel.join()
    .receive("ok", players => {
      players.map(player => Players.upsert(player.id, player));
    })
    .receive("error", e => console.log("Unable to join", e));
});

We’re opening a connection to a "players" Channel, and on successfully joining, we’re upserting all of the players we receive from the server into our local Players collection.

To make this work, we need to add a "players" Channel on our server.

By default, Phoenix creates a socket handler for us called PhoenixLeaderboard.UserSocket (web/channels/user_socket.ex). Here, we can define our "players" channel and assign it a controller module, PhoenixLeaderboard.PlayersChannel:


channel "players", PhoenixLeaderboard.PlayersChannel

Now let’s add a simple join handler to our new PhoenixLeaderboard.PlayersChannel (web/channels/players_channel.ex):


defmodule PhoenixLeaderboard.PlayersChannel do
  use Phoenix.Channel

  def join("players", _message, socket) do
    {:ok, [
      %{ id: 1, name: "Ada Lovelace", score: 5 },
      %{ id: 2, name: "Grace Hopper", score: 10 },
      %{ id: 3, name: "Marie Curie", score: 15 },
      %{ id: 4, name: "Carl Friedrich Gauss", score: 20 },
      %{ id: 5, name: "Nikola Tesla", score: 25 },
      %{ id: 6, name: "Claude Shannon", score: 30 }
    ], socket}
  end
end

Every time a client joins the "players" channel, we’ll send them a list of players in our reply.

If we go back to our application, we’ll see that all of our players are correctly pulled from the server and rendered in order of their score!

What’s Next and Final Thoughts

In good conscience, we should reiterate that this is just an experiment. We don’t recommend tearing a Meteor application in half and dropping its front-end into another application.

That being said, the fact that this is possible is really interesting!

It’s amazing that after dropping the Meteor front-end into our Phoenix application, we can still use all of the features of Blaze templates, Minimongo, and Session variables right out of the box!

In our next post, we’ll finish up our Franken-stack by wiring our Phoenix server up to a real database and using Channel events to implement the “Add Points” functionality.

Stay tuned!

Meteor in Front, Phoenix in Back - Part 1