Phoenix as a Meteor alternative

[seba]

That’d be pretty cool!

[jacobin]

If one could use RethinkDB then a channel could subscribe to a changefeed and then the channel would broadcast changes to any clients subscribed (outdated example)

The video I linked in this post demonstrating that technique was from August. Not so outdated and but a few lines of code.

Postgres also has pub/sub, for which there are Phoenix channel adapters.

opendrops/phoenix-pubsub-postgres

[seba]

Yeah, but it’s the part ‘if something changes in the data layer’ that would still be lacking. E.g. to answer questions like: Show me the top 10 most liked posts, where user A should only see a set of fields that is different from the set of fields user B may see.
You’d almost need a channel per user. As SkinnyGeek1010 points out something like rethinkdb could be a gamechanger for this.

[ryanswapp]

You’d almost need a channel per user.

I believe you may be fundamentally misunderstanding how channels work in Phoenix. A channel is a private websocket connection between the server and a particular user. One user likely would be connected to multiple channels per React component (or whatever view layer you use). In addition, the Redux store holds state for only one particular user. As a result, “where user A should only see a set of fields that is different from the set of fields user B may see” is achieved by default.

[SkinnyGeek1010]

Also worth mentioning, all of the user’s channels are multiplexed on a single websocket for performance… though the developer doesn’t have to worry about that.

[skini26]

@ryanswapp I think what @seba means is how a client can subscribe to data that is specific to him (with custom arguments for example).

I can imagine that the user can subscribe to a channel and pass arguments, then this channel will subscribe to Rethink with a custom query using those arguments.

But then, the bottleneck will go to Rethink and not Phoenix, since Phoenix will just receive notifications and push them back to the user via the channel.
This can also be achieved with a publication in Meteor, the user subscribes, the publication subscribes to Rethink then we can use the low level publication API with ‘‘added’’, ‘‘changed’’, ‘‘removed’’. (I did the same thing with publications and pub-nub).

So in this particular use case, how Phoenix will be more scalable than the Meteor solution since the first bottleneck will be the DB receiving to much subscriptions and not the web framework that will just act as a simple broker.

[vonwao]

Phoenix alongside Meteor looks like a cool solution. This way you could use Phoenix/Elixir to gradually refactor a Meteor app where there are performance bottlenecks. Yes?

This conversation of Meteor vs Phoenix seems too passionate. Both of these frameworks have strong areas, Phoenix for communication-intensive apps, but I would likely use Meteor for a CMS or even CRM system.

[SkinnyGeek1010]

Phoenix alongside Meteor looks like a cool solution. This way you could use Phoenix/Elixir to gradually refactor a Meteor app where there are performance bottlenecks. Yes?

Yep, that’s my plan. At the very least it solves my immediate problems. I hope that MDG can get it to a point where you won’t need Phoenix for a high amount of subscriptions… perhaps Rethink will help them out with the livequery (though that has limits as well of course).

This conversation of Meteor vs Phoenix seems too passionate.

Haha, I think the Elixir community is very excited in general. Partially because it’s the new shiny and partially because the developer experience is exceptional compared to a lot of others.

but I would likely use Meteor for a CMS or even CRM system

Yea I think it would be really good at that!

[themeteorchef]

+1

Going through this now and came to share it. Making it really clear and honestly, seeing a lot of parallels with JS in respect to basic language behavior. The teaching in the videos is on point too. Well worth $9 for the whole set.

[korus90]

Honestly I would just stick to Meteor unless you know you’ll have lots of traffic.

Thing is, I don’t know what my traffic will be. Being an app, it could go either way really… I’d plan on steady growth as most would.

Tech. you could use it in a brand new app by using Meteor to authenticate and handle the user publication, then do all other realtime data through Phoenix, but then you lose the ability to use packages that use your collections (like TabularTables or something).

This is why I think shifting entirely to Phoenix may be the better solution?

Also I enjoy learning new programming things in my spare time so it’s not too much extra effort for me.

I’m also the same and am in no rush so Phoenix looks like a very attractive proposition for me! The only negative is not building with Cordova? (to my knowledge)

I’m still a bit unsure what route to take. I’m also having major issues running ecto.create even though everything else installed correctly…

[eddyborja]

So maybe there’s a thread on a Phoenix forum where people are considering Meteor as a Phoenix alternative.

[jrudio]

Semi off-topic, but is there a Go Meteor alternative?

[SkinnyGeek1010]

This is a great article on how functional programming makes Phoenix easier than Rails. It’s also very applicable to Meteor packages (& illustrates what i’m going for in my Meteor rest library… which I should get back to )

Phoenix is not Rails - DockYard

Excerpts:

Functional programming and the Plug contract makes testing your controllers in isolation, or integration testing your entire endpoint only a matter of passing a conn through the plug pipeline and asserting against the result. Additionally, controller actions in Phoenix are just functions, without implicit state. If we need to test the controller in isolation, we call the function!

test "sends 404 when user is not found" do
  conn = MyController.show(conn(), %{"id" => "not-found"})
  assert conn.status == 404
end

There’s no stumbling with setting up controller instances thanks to functional programming. And when we need to fully integration test through the endpoint, Phoenix just calls the pipeline of functions:

test "shows users" do
  conn = get conn(), "/users/123"
  assert %{id: "123"} = json_response(conn, :ok)
end

Phoenix views follow the same principle as controllers: they are all just functions, there is no implicit data sneaking in!

[jacobin]

Semi off-topic, but is there a Go Meteor alternative?

I’m not aware of any. Perhaps Gorilla combined with your choice of web framework will get you part of the way.

Last I checked out Go, it had some issues. GC was mark and sweep, but was not generational. How exactly do you tune that?

What really made me all giddy about Elixir/Erlang, was the fact that it has a per process auto-sizing heap! That is like omfg level awesome. Set the minimum heap size during dev and say goodbye to garbage collection.

I’ve read though you need to be careful with their Atom data type. It’s Erlang’s version of Java’s constant pool, but unlike Java aren’t collected. They are per module, where with Java it was a global pool.

I imagine there is also an ecosystem of development tools like Jstack to inspect the vm and it’s processes. I’ll probably be asking @SkinnyGeek1010 about it when I get to the point it’s needed.

[seba]

That’s indeed exactly what I was thinking. But again, I haven’t used phoenix, so I might make some wrong assumptions about it.

[jacobin]

http://10consulting.com/2015/11/18/phoenix-react-redux-example/

I’ve spent the past week looking at every Phoenix/React github project and tutorial under the sun. The above is the best I’ve found while we wait for the @ryanswapp masterclass tutorial. It uses Phoenix/Webpack/React/Redux.

The ubiquitous reactive to-do app, sans database integration. It uses instead a Phoenix agent for persistence in memory. I’ve also seen using a GenServer for state as a pattern, but agents are apparently more lightweight.

[SkinnyGeek1010]

@seba

That’s indeed exactly what I was thinking. But again, I haven’t used phoenix, so I might make some wrong assumptions about it.

Ah I see now. I think that anytime you have a one-liner to get the entire state of the DB it’s going to be expensive. I wouldn’t be surprised if someone like compose or AWS will offer an ‘elastic changefeed’ service too

Another option would be polling the database, diffing, then broadcasting.

However, depending on the scenario you really don’t need changefeeds to make this happen. If you take Slack for example, you could use Phoenix’s pub/sub to get realtime (like @jacobin 's redux example )

@jacobin

I imagine there is also an ecosystem of development tools like Jstack to inspect the vm and it’s processes. I’ll probably be asking @SkinnyGeek1010 about it when I get to the point it’s needed.

This looks a bit like the NASA control center but has lots of things to monitor:

docs:
http://www.erlang.org/doc/apps/observer/observer_ug.html

[skini26]

I also always wondered how realtime custom data are done elsewhere without polling and without changedfeeds.

For example, a realtime geolocation service like uber or flight radar, if I want to see only the cars that are 2km around me and that are 4x4, how would it be done ?
With Meteor I can subscribe to a geo query, with rethink also I think, but I don’t think those methods are performant. I wonder how Uber does that.

I know it doesn’t really have to do with Meteor or Phoenix, but it’s to understand how to do those things that are really easy with Meteor with another more classic socket solution like Phoenix channels.

[SkinnyGeek1010]

For example, a realtime geolocation service like uber or flight radar, if I want to see only the cars that are 2km around me and that are 4x4, how would it be done ?

I’m purely guessing here but if you wanted to do this with Mongo and Phoenix you would have the passenger send a get_rides message sending the passengers current coords. Phoenix would respond by making a single query and would then send down an array of ride coords that the UI could render.

In this case sub second ‘soft-realtime’ isn’t really necessary and every 15 or 30 seconds would be plenty of an update.

Unlike long polling with REST, this can be setup declaratively on the frontend so that you just subscribe and you get a constant feed of ride data.

[skini26]

So if I understand, this means that: All (soft) realtime data that are dependent on the user state or arguments (in this case, userId, location and type = 4x4) are preferably fetched by polling ? (even every 3 seconds if necessary).

Then it would be preferable to use the same logic for Meteor, avoiding publications of custom queries and use method polling instead. (This goes back to this discussion).

So the only way to have something as easy as Meteor publications with other backends is to use RethinkDB/Postgres changedfeeds (which puts the load on the DB instead of the web app).

Otherwise, just use websockets for generic data (something different than a changefeed on a specific query).

(For example, this forum platform is using polling to get all the notifications, and those notifications are really specific to our accounts).