Some libraries are available in erlang and can be called directly in elixir code. However if none are available you’ll need to roll your own. I find this to be incredibly fun!
Most APIs have an http endpoint so you would end up using an elixir lib like Poison to make theses requests and ideally make an open source package.
Is there a specific one your looking for?
Oh, I didn’t know that erlang libraries could be used in Elixir (didn’t receive the book yet 
)
And no, I’m not looking for a specific one, just looking at how easy it is to go from JS to Elixir in terms of libraries and packages.
You won’t need a lot of libraries as most of the time Phoenix will serve you as an api/websocket server. All stuff for this (db / orm / validation / json / etc) is already installed for you and is easy to work with.
From the client-side, you will have webpack, all npm packages you want, react + redux will do all the stuf.
This combo will be much more powerful than Meteor, but will require a bit of setup.
Earlier in the thread @ryanswapp linked to https://hex.pm/ which is the package repo for Elixir/Erlang.
It’s pretty deep. Did random searches for a number of things such as Oath, PDF generator or Stripe integration. It had everything I could think to look for.
@SkinnyGeek1010, @ryanswapp Hi, guys. I’m attempting to change stack to Phoenix + React.js. I’m curious how you guys do server-side rendering with Phoenix. Can you guys please suggest me the way to do that ?
@SkinnyGeek1010, @ryanswapp And, also I’m curious of few things.
Please help me, I need your advice before changing stack to Phoenix.
There are at least 3 examples of feeding React.js from Phoenix websockets earlier in the thread.
There are examples of both Postgres and RethinkDB pub/sub feeding Phoenix earlier in the thread.
Scroll up.
You’ll need to start at the top of the thread for more details but the Phoenix way of doing real-time is (currently) is very basic. You either need to (a) rely on a client to push you the new info and then Phoenix broadcasts a ‘change’ out… or (b) you use something like RethinkDB to subscribe to a changefeed and when the changefeed emits a new change, broadcast that to new clients or (c) you can setup manually poll & diff on channel and broadcast when the dataset changes, you broadcast the new change once (this is only efficient when many users consume the same realtime data).
I’m using RethinkDB in my app (migrating my frankenstein Meteor app running Rethink and custom auth).
Mongo is the most complete document database integration and Postgres is the most complete SQL integration for using Ecto, which is the ORM/Model layer that Phoenix includes by default (not required though).
I prefer Rethink’s forward thinking for realtime apps and I am going to try and use that for as many new projects adn possible. There is a nice driver for it and the author has recently released an Ecto “shim” adapter that lets you use the repository pattern and most importantly… model and changeset (equivalent to simple-schema). The purpose with the adapter is to let you use the awesome ReQL syntax to query (instead of the ORMy Ecto.Query), and still give you the schema ability.
If this podcast doesn’t sell you on Rethink than you’d prob. be better with Postgres:
@shcherbin @SkinnyGeek1010 @jacobin @skini26 and for all those interested:
I just wrote up a little post on Getting Started with RethinkDB and the Phoenix Framework http://bit.ly/1PTw18M
probably everybody has seen this but thought it might help someone.
I have a question about this topic as I am just starting to learn Meteor.
What makes Meteor so bad that you need an alternative? I’m just interested as I have heard some benefits of Phoenix however I am just wondering what actually makes you want to change to another framework?
Thanks
I think there are a number of reasons that one would look for an alternative to Meteor (these are in no specific order):
You’ve been working with Meteor for awhile and you’d like to learn something new. (I personally fall into this bucket because part of what I love about programming is that there are so many new things to learn. If I’m not learning something new I don’t feel excited about what I’m doing.)
Meteor development moves very slowly. I think a big reason for this is that MDG is a company, and not only that, they are a venture-backed company. They need to make money. Working solely on an open source project (Although Meteor doesn’t really feel like an open source project) doesn’t make they kind of money that VC’s are looking for. So, MDG has, understandably, focused their attention on money-making activities at the expense of the platform (I obviously don’t have an agenda of what everyone at MDG does all day, but the pace of development compared to the number of resources that MDG has certainly indicates that they are focusing on other things besides the framework).
Meteor has been very slow to adopt excellent technologies from the JS community. There is talk of switching Meteor’s build system over to something like Webpack, but I’ll be surprised if that happens any time soon. Meteor development is PAINFULLY slow. My app reload times are atrocious (30+ seconds) when larger projects than mine that use Webpack reload almost instantaneously (not to mention they have hot-code reloading so there is actually no reload at all).
There is instability in Meteor land. Just read through the forum for a bit and you’ll notice that people are always asking questions like, “Which Router should I use?” Should this even be a question in a full stack opinionated framework like Meteor? Furthermore, MDG just announced that they are switching their view layer to React with a Blaze like abstraction on top. This means that if you write an app in Blaze now, you most likely will need to rewrite it as soon as the new view layer comes out.
Testing is hard. It’s very difficult to test a Meteor app. In addition, good learning materials are far and few between. There are some great community driven packages, notably the cucumber package, but I think it says a lot that the Velocity team dropped support for the testing framework because MDG wasn’t helping them with it.
Other frameworks do what Meteor is trying to do better. Phoenix is one of them. Phoenix allows you to build stupid simple real time apps that are exponentially more performant than a Meteor app. In addition, you can use whatever database you’d like without much hassle! This is not true of Meteor. Phoenix allows you to drop whatever build tool you want into it with literally a couple lines of code. The Phoenix team is also much better at communication. You can go over to the Elixir slack channel and Jose Valim (creator of Elixir) or Chris McCord (creator of Phoenix) or any other core team member will totally respond to you and answer any questions you have. The Phoenix team accepts pull requests and moves quickly on new features. They are very much forward thinking and aren’t tied down because they have to make money.
I could keep going on and on but I have to go so I’ll leave it at that. Now, don’t get me wrong, I really like Meteor. I think it’s been a great framework for quickly building apps. However, I think there are much better options (in terms of features, performance, and extensibility) that are significantly more future proof than Meteor.
Looks like they’re re-inventing the wheel (they even used those words) and not using webpack for es6 modules:
Why invent Meteor.install instead of borrowing the bundle formats of Browserify or Webpack? The goal of those tools is to make server-side Node code runnable on the client. Either tool would probably work well for Meteor…
Unless the new module system will speed up their current build time i don’t see how this is even worth it? I haven’t got an answer if this will be the case but I expect it to be as slow.
Pheonix is cool but compared to Meteor’s features it’s rather primitive.
Percolate Studios, before joining Meteor, did a fantastic React demo that feature SSR for the first page load then the rest of the site loaded as a SPA. I believe this is that work
[editted out see below]
The amount of work put in to get a time
saving rapidly deployed prototype written simply in an isomorphic style is unmatched anywhere. The performance argument is separate. I just want to see a thing up and running at a low cost and fast. Once money is being made and the traffic is there, sure, Phenonix or something like that could makes sense for the backend.
EDIT: wrong link! This is the link
Hands down Meteor is the fastest prototyping tool out there. Phoenix is not a prototyping platform at the least. I think you’re 100% spot on.
I just want to see a thing up and running at a low cost and fast.
Again, I think Meteor hits the nail on the head here. What’s not ideal is that once it’s built you usually have a maintenance issue (technically debt).
Eventually if you’re hitting the edges of Meteor than Phoenix is way faster to develop in than Meteor. I’m just tired of monkeypatching core, sidestepping, or dancing around to get things to meet the project requirements.
For instance in complex apps you can’t use autopublish. You mostly can’t use the normal publish, and usually you have to drop down the the low-level publish API and coerce it send down data you want. With a more simple design you just broadcast(conn, [{foo:1}, {foo:2}]) and you’re done.
As your app gets more advanced I feel Meteor sucks away the productivity you had when first starting out. And starting out only lasts a few weeks.
IMO, they had to do it to keep packages truly isomorphic, aware of Meteor environment (like isClient, isServer), and as easy as meteor add pkg-name, without requiring the developer to know how to use Webpack or other bundler properly.
Supporting modules was more important thand build speed, for now…
I felt they are struggling with easy of use and backward compatibility. Good for legacy and newcomers… But bad for who knows how good it can get looking outside this Atmosphere and have willing to persuade more adventurous paths.
Knowing the repercussion that deprecating Blaze brought, i would do the same in their place, requiring to learn a new bundler would fire another crowd fury.
But they could provide a better advanced path… Anyone using Meteor for 6 months will start to see untied knots.
I will keep using Meteor using many shortcuts for the deficiencies… with the hope that after they take care of the legacy it will get better.
Does Phoenix have something like Mergebox, to send only the bits one client needs?
Hmm, yea I never really thought about the packages and how that would work. Technically they still work as is and MDG could use a hybrid of their current build system and webpack (like we do today) but make things hidden so that it’s transparent.
Knowing the repercussion that deprecating Blaze brought, i would do the same in their place, requiring to learn a new bundler would fire another crowd fury.
So if Meteor did it right, they wound’t have to learn anything new except how to include an ES6 module. Advanced users could add in a config file in the root that would override/augment more config options, etc…
I do think eventually the NPM path is the right way but killing atmosphere packages would lead to an outcry as you said.
The view layer is just a serverside layer like rails and on the client there’s a library that gives you a way to connect and handle broadcast events and that’s it. Redux is typically used as a mergebox/minimongo replacement and it works on any view layer (react/angular/blaze/etc…). It’s also simple but now that I understand it I very much prefer it over minimongo.
I shared the wrong link earlier, this one
BTW, I see what you mean. It would great if Meteor scaled better. It’s not a one for all platform. For what it is, for me, it’s really great.
Also, I’m a bit perplexed by compile times during development. Some people claim Webpack is much fast while others say Meteor 1.2 is really fast. For me Meteor 1.2 is slow to recompile changes and it can be frustrating under a crunch/focused session of debugging, I’m curious if some could share their fast compiling Meteor source on GitHub along with what OS they’re on. I’m on OS X, high spec MacBook Pro.
Investing in Phoenix would be spreading myself thin until I have a clear need for it. Sticking with Meteor means paying good developers to join the project would probably be easier and that itself could offset the higher hosting costs paid over a more performant setup.
As for taking a look at it, it’s does make sense to know what problems it is best suited for. Thanks for sharing your experience with it.
I wouldn’t describe Phoenix’s features as primitive. If you spent a bit of time trying to understand the Erlang VM, OTP, and how they help you build distributed systems you would probably reconsider your statement. Phoenix offers vastly more power to a developer than Meteor ever will.
With regard to your statement about having less features I don’t know that I agree. Does Meteor have amazing built in routing, testing, microservice support (this comes back to the distributed nature of Erlang), multi database support, etc…? Absolutely not. Sure, you can make a silly web app into a mobile app with the cordova integration, but if you try to make anything useful you won’t get too far. If you are going to build a serious mobile app it’s much better to use native technologies so cordova integration isn’t much of a win.
The isomorphic argument gets tossed around a lot and I’ve started to question whether isomorphic is a good way to build an app. After working with Phoenix on the backend and React on the frontend I’ve come to appreciate keeping a clean separation of concerns. In addition, Elixir is a beautiful language and extremely fun to work with. Much more so than JavaScript (although I do like JavaScript).
With regard to speed, I definitely think Meteor is faster if you are starting completely from scratch. However, if you have a good template (boilerplate) for something like a React + Phoenix app you can hit the ground running at the same speed as starting a Meteor app.
I completely agree with this statement. In addition, I think you will very quickly hit the edges of Meteor if you’re trying to build something more than a simple tutorial app. I’ve got a fairly good sized Meteor app that I maintain for the startup I work for and we’ve started to run into some issues that, frankly, if we were to have built the app with Phoenix, we wouldn’t have run into. Some of these issues include a huge initial payload size, ridiculous development reload times, expensive server costs, and poor testing coverage.
You are not alone my friend! Meteor 1.2 reload times are atrocious! Sometimes I find myself sitting there for 30 seconds waiting for the app to reload. I also am on a high spec MacBook Pro. Webpack is pretty much instantaneous. The hot reload feature is amazing!
I’d definitely agree that JavaScript developers are more abundant and that hiring them would be easier than hiring an Elixir dev. That said, I was able to pick up Elixir pretty quick. I also now that there are a number of dev shops that have moved to Phoenix and their teams have also been able to pick up Elixir quickly. It really is a joy to work with. Why not give it a shot just for the fun of it? 