That’s indeed exactly what I was thinking. But again, I haven’t used phoenix, so I might make some wrong assumptions about it.
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.
5 Likes
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 )
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
1 Like
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.
1 Like
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.
1 Like
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).
In either framework it wouldn’t be so cut and dry. You could also have the user subscribe to data with no arguments and they could get realtime data (but in this example we need the passenger coords).
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).
Pretty much. Someone has to calculate the changes. If you need easy realtime Meteor is the best fit. Nothing at scale is going to be easy 
Rethink seems to be the most optimized for this on a very low level though. Every mutation is made in a way for realtime updates where as the oplog is a bolted on solution.
2 Likes
Then RethinkDB will solve almost all the problems that people have with Meteor scaling haha 
And also, apart from having a better programming paradigm, structure, good practices, tests, performance and fault-tolerance, what will be the advantage of Phoenix over Meteor if the load will be on the DB and not on the web server ?
(Btw, I’ll receive ''Programming Elixir" next Monday !)
1 Like
Not a lot as far as publications go. One thing is that you’d have the option to use pub/sub for realtime without a changefeed. Outside of publications you’d have more control over everything (like webpack vs Meteor bundler).
How about to create a repository where we can try to simulate the Meteor behaviour?
2 Likes
What behaviour do you want to simulate ?
Combo of Webpack, React, Redux, Channels - pub/sub (add items/update/remove), User Authentication, SQL database as a start.
3 Likes
So you want to create a boilerplate project where all those components and base functionalities are already pre installed/configured ? That’s a good idea !
We can use the already available repo from the Phoenix React tutorial and build upon it ?
1 Like
Yes, some kind of a boilerplate, we can use to quickly start a new project or just try (or benchmark), how it works. I like this tutorial, but I miss User Auth and Router part, which are must have for me.
3 Likes
Thank you for the research. I know what I’m doing this weekend! 
You could always fork that project yes, but I’m of the opinion it’s best to see what @ryanswapp comes up with first. After all, his React/Meteor tutorial was excellent. I’m sure his version will have basic auth and routing in some fashion.
Redis is hand tuned to the point it would easily win an obfuscated c contest. RethinkDB I’ve read is a tad slower than Mongo.
Also, Redis is getting geo queries in 3.2.
Don’t thank me. Blame @SkinnyGeek1010 for turning me on to Phoenix. 30 years of OO down the drain!
Hah why is poor Charlotte sitting in the back? Her website gets a lot of hits… no comment!
3 Likes
Meteor could really improve the documentation like they have done with Phoenix. It was quite easy and felt a less steep learning curve compared I had with Meteor. Of course, the full documentation is really good these days - however I spend a lot of time finding things that were deprecated or simply non-existing. Important differences in Meteor vs other solutions were merely mentioned. Hopefully, that will change.
1 Like
Did you see my meteor-elixir project towards the top? It has a Reactive setup that would be similar to using a webpack outside of the Phoenix app (only it’s Blaze in this case).
I also have a boilerplate with webpack/redux/redux-router for the frontend and the server just needs a command run:
mix phoenix.new foo --database mongodb
cd foo
mix deps.get
And then the generator builds the server boilerplate for you. If you have your models ready then you can scaffold out a model, controller, routes, and tests (this is great for learning too):
mix phoenix.gen.json posts post title:string desc:string
However, it’s not pre wired up to the Phoenix’s channels (though you could mash together the two repos and use the HTML if you want). Also if someone is looking for an app to replicate my facebook wall clone it’s up on my Github 
[quote="miningsam, post:113, topic:13519"] Meteor could really improve the documentation like they have done with Phoenix. It was quite easy and felt a less steep learning curve compared I had with Meteor. [/quote]
I agree, I was going to refer Sashko to those guides as a reference as he’s working on new guides now.
2 Likes
you’ve made some great points regarding computing resources needed for SSR and SSR may not be necessary for most apps.
However, for consumer and/or content heavy sites, SSR is critical for SEO and, indirectly, traffic generation.
Wonder if there is a feasible option to React SSR w/ Phoenix. If not, pre-render may be the next best option.
1 Like