Phoenix as a Meteor alternative

[jacobin]

Spacedojo Show | What are Phoenix & Elixir and why should I care? | Episode 18

Latest meteor club podcast is an interview with Chris McCord on Elixir and Phoenix.

[Babak]

I gave Phoenix a try. I like it. I’m intrigued, especially by functional programming. Anyway, I tried both the projects share on GitHub by @ryanswapp and @SkinnyGeek1010 (thanks guys!)

What I kept thinking is why not just write a DDP server to talk to the Meteor client. This way one can simply start with Meteor then if performance is an issue, swap out the server without changing anything on the client.

Then I found this:

meteorhacks/goddp

A DDP server (not client) written in GO.

@arunoda Are you guys using this? Could this address Meteor performance woes? What are the performance metrics like? Kind of crazy idea is to use this along with @martijnwalraven’s Meteor iOS

martijnwalraven/meteor-ios

Edit:

Though not possible with a Go DDP server, for my own references I’ll collect other interesting projects to replace mongo as well.

https://github.com/metstrike/meteor-oracle introduced by @metstrike

@numtel’s (and contributors like @vlasky) packages for MySQL or Postgres.

numtel/meteor-mysql

numtel/meteor-pg

It is possible to have a “Meteor” or DDP stack without Meteor. Just goes to show just how flexible one can be with Meteor.

[ryanswapp]

I’m intrigued, especially by functional programming.

I feel the same way. It seems so clean to me!

What I kept thinking is why not just write a DDP server to talk to the Meteor client.

Did you by chance listen to the most recent Meteor Club podcast? If not, here’s a link https://simplecast.fm/s/2f11905f21 Josh, Ben, and Sam talked to Chris McCord about Phoenix and he had a lot of interesting things to say. One of which is similar to the DDP server idea. He basically said that Phoenix channels have been designed as low level infrastructure for people to build on top of and they talked about a potential DDP layer on top of that. Interesting stuff.

Awhile back some Meteor folks tried to hook Meteor up to Elixir https://teamgaslight.com/blog/the-philae-experiment-landing-an-elixir-app-on-meteor It’s a pretty interesting post. They also made a DDP client package https://github.com/cincinnati-elixir/philae.

I personally have been trying to figure out how Meteor would fit in with Elixir and have struggled to come up with viable options. The thing that Meteor is great at is abstraction. It’s abstracted away a lot of tedious things like syncing data between the client and server, authentication, etc… With Phoenix, I’m not sure you really need all the Meteor abstractions. If you can use tools like RethinkDB’s changefeeds in conjunction Phoenix channels and a state manager like Redux on the frontend then I’m not sure where Meteor fits into the picture.

The other thing I wonder about is whether an Oplog tailing/Long Polling type system is really the best way to go. I really like the idea of using Phoenix as a message broker to notify all clients when things change so you don’t need to be constantly polling the database. I’ve experimented with broadcasting events from the controller when something successfully changed and it’s seemed to work pretty well. It’s almost kind of a lazy DDP… haha

Anyways, I’m glad you like Phoenix! Even if it’s not something that we use everyday I think the functional world can teach us a lot about how to build better programs. My code has definitely gotten a lot cleaner since I started working with Elixir

[Babak]

I feel the same way. It seems so clean to me!

I feel it depends on the application for me. SQL is functional. Data is transformed as it moves from one function into another. Data is the focus. Procedural languages have their advantage too. There isn’t a landslide winner either way. That said, yes, Elixir is refreshing.

Did you by chance listen to the most recent Meteor Club podcast? If not, here’s a link https://simplecast.fm/s/2f11905f21 Josh, Ben, and Sam talked to Chris McCord about Phoenix and he had a lot of interesting things to say. One of which is similar to the DDP server idea. He basically said that Phoenix channels have been designed as low level infrastructure for people to build on top of and they talked about a potential DDP layer on top of that. Interesting stuff.

I have, interesting talk for sure!

Awhile back some Meteor folks tried to hook Meteor up to Elixir https://teamgaslight.com/blog/the-philae-experiment-landing-an-elixir-app-on-meteor It’s a pretty interesting post. They also made a DDP client package https://github.com/cincinnati-elixir/philae.

Right, but the aforementioned DDP projects is a Go DDP server not a client. It means it speaks DDP to DDP clients. Be this a Meteor client w/ React or Meteor iOS.

I personally have been trying to figure out how Meteor would fit in with Elixir and have struggled to come up with viable options. The thing that Meteor is great at is abstraction. It’s abstracted away a lot of tedious things like syncing data between the client and server, authentication, etc… With Phoenix, I’m not sure you really need all the Meteor abstractions. If you can use tools like RethinkDB’s changefeeds in conjunction Phoenix channels and a state manager like Redux on the frontend then I’m not sure where Meteor fits into the picture.

There are some changes coming to RethinkDB that will give it full Meteor compatibility https://github.com/rethinkdb/rethinkdb/issues/4629

There are nuances that typical “real time” apps often overlooked.

With a DDP Server (not client!) written in Elixir or Golang, it seems to me much of the performance problems for high-traffic application can be resolved. This further supports the idea that Meteor is indeed a very good choice in the beginning given that the problematic parts can be swapped out when needed.

To rehash: At the heart of Meteor is the DDP protocol. There are many clients that rely on a Node server; yet it is quite possible to have a server written on something else. Perhaps Golang?

[ryanswapp]

I’ve been playing around with RethinkDB in Phoenix and just wrote up a post on actually using it inside a Phoenix app. I plan to follow this post up with one describing how to use changefeeds with channels to make real time applications. Let me know what you think! http://ryanswapp.com/2016/01/02/getting-started-with-rethinkdb-and-the-phoenix-framework-building-an-app/

[ryanswapp]

By this “In a follow up post we will use RethinkDB Changefeeds and Phoenix Channels to make our app realtime” I was just trying to let everyone know that I’d be doing a third post on using changefeeds with channels to make the simple app we built real time. The app built in that post isn’t realtime (yet - the third post I’m planning will make it that way). Sorry if that wasn’t clear!!

[jacobin]

I finally got around to making a React/Phoenix starter template today! It's got a whole bunch of goodies: React React Router & Redux Router Redux Webpack CSS Modules, CSSNext, PostCSS Phoenix API JWT API Authentication Redux/Channels Example I still need to do some work on the README to explain how things work and I'm planning on doing a video to explain how it works and some of the design/architectural decisions behind it. One thing that I've noticed about React + Phoenix is that it req…

@ryanswapp do you still plan on recording a video series on your phoenix/react/redux template? I know, law school right?

[kaiyes]

@jacobin

video series on your phoenix/react/redux template

eagerly waiting for the video series.

[ryanswapp]

@jacobin

I know, law school right?

@jacobin @kaiyes I am still planning on the video series!! It’s been a bit delayed because I’ve been experimenting with different approaches to building apps with Phoenix. I’d like to nail down a solid implementation before I make a video series on it.

Now, that’s not to say that the template I made is a bad implementation. I just want to get a little more comfortable with the technology so I have some value to offer. I’ve got a bunch of free time tomorrow. I might look at pumping out some material. We shall see

[jacobin]

Now, that’s not to say that the template I made is a bad implementation. I just want to get a little more comfortable with the technology so I have some value to offer. I’ve got a bunch of free time tomorrow. I might look at pumping out some material. We shall see

Elixir Fountain

I have been working my way through these podcasts while we wait. There’s 18 of them, akin to the meteor podcast series.

[benjamin79]

Sorry, it should have been clear. I should learn to read better

[rolf]

Awesome, as soon as I have some minutes, I will read it

Here is some other probably unrelated stuff, but it’s Phoenix with React so it will fit the picture somehow; http://blog.overstuffedgorilla.com/render-react-with-phoenix/

[ryanswapp]

@jacobin @kaiyes Just an update. I spent a bunch of time working on a new React Starter Template (Purely client side - no backend). https://github.com/ryanswapp/react-starter-template This template is ready to go for production.

I’ve decided to start a tutorial site that I’m currently building so you can plan on that popping up in the next couple of weeks. It’ll focus on Meteor, React, and Phoenix development. Some of the videos I’m planning will discuss my new boilerplate and how its setup. In addition, I’ll show how to build the template for production and deploy it to S3 or Github pages as a static site that talks to a Phoenix API hosted on Heroku.

[jacobin]

@jacobin @kaiyes Just an update. I spent a bunch of time working on a new React Starter Template (Purely client side - no backend). https://github.com/ryanswapp/react-starter-template This template is ready to go for production.

Phoenix Framework (elixirphoenix)

I know you use webpack but thought I would mention that Phoenix 1.1.2 was released two days ago, which includes the new Brunch with npm support.

[ryanswapp]

Ya I saw that! Had to upgrade to Node 5.4 to create a new app (which is good). Do you know if Brunch creates client bundles for you? Or is it like Grunt/Gulp where you have to run your code through Browserify?

I’m really comfortable with Webpack now and it is amazing so I don’t think I’ll be switching any time soon. I also don’t think Brunch supports hot code reloading?

That said, if I build an app without a React frontend I’ll most likely just use Brunch

[riaan53]

Have a look here on how to use react with the new version of brunch in phoenix: https://medium.com/@diamondgfx/phoenix-v1-1-2-and-react-js-3dbd195a880a#.sbaj68qi4

[ryanswapp]

Ya it looks pretty straightforward. The only problem is that the vast majority of the react ecosystem uses webpack so all the tools are designed around webpack. I used to not be a big fan of webpack but now I love it! Tough learning curve for sure, but it’s a great build tool.

[jacobin]

Trello clone with Phoenix and React (pt.1)

@ryanswapp There is a new phoenix react example that’s been brewing the past couple weeks. It’s a Trello clone. The blog is up to 4 parts now. Hopefully it has some ideas for you to use.

Elixir.
Phoenix
Ecto
PostgreSQL

Webpack
Sass
React
React router
Redux
ES6/ES7 JavaScript

[ryanswapp]

That’s pretty cool. I hadn’t seen that. Thanks for sharing!

[cgarciae88]

What a nice discussion! I followed Meteor when it was still < 1.0. This was when I was first leaning web development and It was the first web framework I liked, before I tried Django but the experience repelled me.

I ended not using Meteor because one of my basic needs was to serve JSON and this is/was difficult (maybe the situation has changed since). I finally when with Dart because I liked the idea of sharing code between client and server (I don’t think like this anymore). Ended up ditching Dart in favor of Elixir after investigating about scalability for a month (contendors where Go, Scala, C#).

Phoenix is a really nice framework that takes a lot of the good things that Ruby brought to the scene. Here are some remarks about Meteor vs Elixir/Phoenix.

Meteor

Pros

1. Dead simple realtime with database pub/sub to live updates. This problem is hard to tackle and you have to create a lot of infrastructure to do it elsewhere.
2. Easy to get started. Client and server on the same project.
3. Lots of libraries.

Cons

1. Diverges a lot from standard web dev, e.g. creating a REST API is not easy.
2. Too much magic. This magic gets you started easily but can bite you later.
3. If scalability becomes a problem you might have reached a dead end. Meteor is too opinionated.

Elixir/Poenix

Pros

1. Scales
2. Phoenix is an excellent framework for general web development.
3. FP is an excellent paradigm.
4. No JavaScript! Well, at least not on the server. People here favor using Elm on the frontend a lot, so even better.
5. Fault tolerance and all the OTP goodies.

Cons

1. If you want all the magic Meteor does with its pub/sub and automatic update system you are going to miss it.
2. Starting isn’t as easy. Meteor is excellent for total newbies to web dev to get something up and running.