Any chance you got to do this? Very much interested in the possibilities of this “marriage”
Ya I did build a little app that used Rethink changefeeds with Phoenix channels! I never ended up writing a post mostly because I’ve been swamped with school and work (in addition to being a bit burnt out). In order for changefeeds and channels to be useful you’d need to write some type of abstraction layer that interprets the changefeed output as its not as straightforward as it seems. I know Peter Hamilton (the RethinkDB driver author) has done some work in this area so I’ll need to check out what he’s done and revisit my example app before I publish anything. Thanks for the reminder though! I need to play with that stuff a little more…
4 Likes
There was a related Erlang Factory talk recently.
1 Like
For those who only compare Meteor with phoenix , beware, there is another alternative.
2 Likes
@ramstein74 this is really interesting! I think the main draw for Erlang/Elixir for me is not using JavaScript, not having the micro package issue (1000 deps in a small project), and the error handling philosophy.
But that looks pretty neat for JavaScript though 
3 Likes
There is also a nice article, which shows, how to use react (+ redux, + router), phoenix and have react server-side rendering 
2 Likes
So why not use Firebase, Redux, and RiotJS. Small and relatively cheap. RiotJS makes it easy to cross compile whatever to JS (if it has a cross compiler of course).
Interest to see where you have got. Looking at using React+Redux+Phoenix
kind of interested in using RethinkDB, however, one thing occurs to me, for reactivity, it seems elixir is in a good position to do notifications in between your data layer and clients.
2 Likes
@keithnicholas I actually haven’t spent a ton of time on RethinkDB as of late. I’ve been doing a bit of elixir but mainly messing with OTP and trying to understand it more deeply. I think React/Redux + Phoenix (RRP) is awesome! Elm + Phoenix (EP) would be cool but I’m just not familiar enough with Elm to feel like I could be productive. Still too many unknowns. I’d say give RRP a shot!
You’re right that Phoenix is in a good position to efficiently communicate between the client and server! I love that about Phoenix. It also sounds like since this is the case you may be thinking of using another database? I’d say use whatever you want! You can make anything close to real time (although RethinkDB makes it a lot simpler).
Another thing to consider is how you’ll structure your app. There has been a lot of talk recently about having a main elixir app and then using phoenix as a separate application merely as an interface to the web. Here is a great talk about it https://www.youtube.com/watch?v=lDKCSheBc-8 I think this is probably how you should structure your app if you are building anything serious. I’m not sure how familiar you are with OTP so this may be more or less confusing. If you are less comfortable I’d recommend Elixir in Action. It’s an excellent book!
One more thing and I’ll shut up (this stuff just gets me excited). I’d highly recommend using GraphQL instead of REST. There is an excellent elixir graphql library called Absinthe http://absinthe-graphql.org/ There is a nice tutorial on their website to help you get started (you may already be all over this but figured I’d mention it). Also, here is an example app if you want to see what it looks like https://github.com/ryanswapp/react-redux-phoenix-graphql-example
Let me know if you have any questions. 
8 Likes
I’m going to be using this in the near future for a prod app. Currently i’m just long polling to get things going but it’s pretty nice to subscribe to a change feed and have Phoenix push down updates. On the client you just dispatch a single update action in the Phoenix channel callback and the whole UI updates 
2 Likes
Awesome new tutorial covering Phoenix, React & Redux by Sam Corcos: https://www.learnphoenix.io/
2 Likes
This framework is cool 
i already use it on production and its really really fast but i still use meteor on some of my projects that’s not need scalability