You’re not making yourself look too good.
3 Likes
Not at all, I stand by that. Maybe you should think about it a bit more?
Oh the irony. Perhaps had you followed your own advice you would not currently be in such a “precarious situation” ?
Back on topic: I’m halfway through Programming Elixir and love it!
1 Like
I’m not sure that’s a fair comment.
The way MDG informs the community of technical direction (or lack of it in the past) is a risk factor you can pick up reading the forums. The fact they made a community blog post on the directional change that sparked a brush fire of response is actually a good sign that they are aware. Hopefully they will listen to the people most vocal about the business stability of using Meteor as a tech choice being vital and put more effort into supporting this via a smooth transition process.
It’s also possible to tick all the evaluation boxes and still get burnt by a tech platform/company.
History of the web is littered with those kind of stories. And apps for that matter.
At some point you have to decide whether the benefits outweigh the risks for your current use case and start developing. That includes other factors like time, resources, skills etc as well.
I may be wrong but Phoenix seems to me to be at the same stage Meteor was in 2013, more or less, and has it’s own risk factors. It’s not immune and you would be making a mistake to think so.
Getting back to the point I was trying to make with ryan (in my typically direct Australian manner;-) this recent post nicely sums up the core issue to me, when trying to pitch a new tech:
"React has become very popular among developers and there are lots of resources that speak to its technical merits. However, migrating to (or choosing) a new framework ultimately comes down to selling it to everybody at the table — including non-technical people — and few engineering managers or PMs would agree to a re-write just because it’s the shiniest new thing. Worse still, many organizations have been burned by the high churn in JavaScript tooling, which sadly moves projects backwards as a part of moving the web forward. This post is not an attempt to teach you something new about React. It is an attempt at the Executive Summary; a starting point for your pitch to try to sell not just developers but everybody on the wonders of React."
https://blog.formidable.com/using-react-is-a-business-decision-not-a-technology-choice-63c4641c5f7#.xvzym8xjc
3 Likes
Mate, I don’t want to get down in the dirt with you, so I’ll take that with a smile. 
Listen, if you read what I wrote then it becomes clear your comment actually takes such a narrow view of what I said it becomes a distortion.
The thing is I’m not going to chunk what I have now for something new (React) just because it’s new mate, I’m going to slowly migrate over to React because if I don’t, I’ll be in a real quandary at some point not too far off for all the reasons I mention in that comment you linked to.
Have a good weekend mate,
Cheers!
@sonicviz, the posts that I’ve read from you have been balanced and well thought out so far mate. Your last post, where you go into React, I think would be welcomed in the ‘Next steps on Blaze and the view layer’ thread too.
The “Phoenix tutorial” that is declining in popularity is the software for flashing Nokia phones called Phoenix. (See the related keywords below the main chart.) I don’t think that the Elixir framework is represented on that page.
(Sorry, I didn’t see the other replies when I posted this. Here’s another (imperfect) query though.)
3 Likes
I’m not as far along as you business wise as I’ve only done an MVP with Meteor, but I understand the position MDG has put you in and others in.
MDG needs to put business stability first over features.
I’m still 50/50 on whether big React push actually a solid technical decision driving it (why not Angular or as people point out keep their own) or Investors are pushing it in that direction hoping to move it closer to being an acquisition target.
re: Phoenix
I have some other potential projects on the boil so I’m willing to investigate Meteor alternatives.
I understand why people get excited about new technology and platforms but I wish the evangelism would take a backseat to objective tech and business eval criteria.
1 Like
Meteor is making a sound technical decision by future proofing the tech stack, allowing you to use whatever front-end you feel like. It’s not exactly code to interface, but it’s thankfully moving in that direction.
http://www.angular-meteor.com/
This includes angular, which will likely end up having better integration than react in the long run. MDG hired a single React dev, who doesn’t appear to really do much. Meteor claims to be working directly with the Angular team through Ugio, who appears to be doing quite a bit.
You seem to think there are not objective criteria at play and it’s all about shiny objects. Nothing could be farther from the truth.
For some folks being able to scale beyond 100 concurrent users is a business requirement. For some folks having an ACID compliant database is a business requirement.
Phoenix solves both of those meteor limitations.
Many of the folks discussing Phoenix in this thread have running meteor production applications and wish to solve those issues. They are in fact objective business and technology requirements.
1 Like
Not at all, but you don’t have to read to far into the thread to see elements of both. Which is what I was referring to.
Scaling and DB are two great examples.
However…
Pulling numbers out of thin air doesn’t help your argument, especially after what you just wrote above.
It makes you look like you’re suffering from Maslow’s Instrument law.
Where’s your evidence Meteor peaks at 100 current users? Because you’re implying Meteor is not the correct tech solution for > 100 concurrent users. I don’t think I misinterpreted that, seeing as you explicitly say “Phoenix solves both of those meteor limitations.”
Ditto for ACID db. MongoDB may be the official db but there seem to be people using it with PostgreSQL, for example.
Concurrent issues are debated quite well here: How Many Simultaneous Users Does the Biggest Current Meteor App Support? - #13 by serkandurusoy
Also:
“This meant around 200 concurrent users on the site for a whole day, with peaks around 250. And I have to say the app held up just fine, with no noticeable slowdowns or issues.” +
“A large Meteor app like Telescope will comfortably scale up to at least 200-300 concurrent users, which is more traffic than being #1 on Product Hunt will get you (in other words, more than 99% of websites out there will ever receive at once).”
http://www.telescopeapp.org/blog/screenings-launch-meteor-scaling-case-study/
Kadira has also done some heavy meteor scaling way beyond these levels afaik.
I get it that Phoenix/Elixir has been engineered for high concurrency.
Not surprising considering where it came from.
There’s plenty of use cases where using Meteor isn’t the best solution.
I’m sure the same also goes for Phoenix.
I fully agree with you on objective business and technology requirements.
2 Likes
You must be new around here.
1 Like
Actually I remember watching that in real time.
That’s your whole argument? blinks
1 Like
Try understanding how oplog tailing works and it’s limitations. There are no arguments, just statements of fact. There are multiple threads on the topic.
I’m now the second person you have tried to troll in this thread. blinks
4 Likes
So the people who are successfully using Meteor with more than 100 concurrent users are, by extension, trolling you because I don’t agree with you?
Sent from Samsung Mobile
1 Like
Your ignorance of the issue has only to do with your arguing from a place of ignorance, nothing else.
Applications with more than 100-200 concurrent users, such as Codefights with a claimed 690 max, has had to a) deploy across 10-20 meteor nodes and b) jump through hoops to eliminate oplog driven reactivity everywhere possible.
Phoenix can handle thousands on a single node using commodity hardware and Rethink or Redis pub/sub instead of oplog tailing. Hence the interest among meteor veterans.
Considering oplog tailing being a limiting factor on horizontal scaling is a well known issue, the only person you are trolling at this point is yourself.
2 Likes
So write the app in Meteor then when you hit #1 in product hunt hire geniuses to rewrite it in whatever. Pheonix, Go, C, Assembly, etc.
Facebook started out on PHP because it was simply a comfortable language. It could have been written with C even back then and would have started with better performance. None of that matters. It’s more important that you can add features and evolve your product quickly in the beginning. Once the time comes you could even invent your own framework to solve your specific problems.
1 Like
In general I agree that you shouldn’t micro-optimize for things that may never happen. However, going too far in that direction can be dangerous. I naively thought that MDG would fix scaling before I hit issues. I’m only offering anecdotal evidence from my own experiences but here’s my take:
I had the same attitude when I thought that I would only have a few hundred concurrent users. However, business requirements changed before I even got the project launched and now I need to handle several thousand concurrent users from the start and within a year tens of thousands of concurrent users are reasonable (due to the customer driving their own traffic to the app).
This puts me in a pickle. It’s also the reason I made the meteor_elixir repo, as a spike to prevent re-writing the whole app before it’s even launched. It basically just cuts out subscriptions and delegates that to Phoenix while the rest is handled by Meteor.
Second use case:
An app built in Meteor. The data transfer is very minimal/optimized because of the mobile restraint. We thought we wouldn’t have a lot of traffic but alas, one day we had 400 concurrent users blasting the system. Crap I had to spin up 4-5 instances to keep it from crashing (5 keeps 404 errors to little/none). 5 - 1gb servers cost $285 on Modulus and I couldn’t host on DO at the time (mup didn’t exist).
In this case Meteor is able to keep up but it was not efficient and expensive. It was for a ‘free’ app so no revenues to pay for hosting (that’s another topic 
).
I was able to reduce costs by cutting realtime on some features and using long polling every 30s (even though getting a new chat message instantly would be a better experience).
Phoenix is more efficient for these use cases and even though it’s more work upfront, over time it pays off. There’s no doubt that you can build an app faster with Meteor, there’s a tradeoff to be made. No free lunch.
11 Likes
@SkinnyGeek1010 I wonder if it makes sense to just build a wrapper in Node that emulates Meteor for Methods and Publications but speaks to a Phoenix layer instead of doing OpLog, Mongo, etc.
A framework built on Pheonix that fires up on the server and listens via API on which database entities to create, monitor, etc, and passes back the data to the Meteor server which then processes it and streams the data down the wire. If the bottle neck is OpLog processing this would solve the issue, no?
The winner of the hackathon made an app that pulls data on rest end points and deliver a ddp connection.
Here there is no pulling here. We are listening to channels between servers (Phoenix and Meteor) and returning a ddp websockets connection from Meteor on the server to client.
Can’t it be completely automated, requiring developer thinking strictly in JavaScript, with the proper compliment written on Phoenix?
1 Like
While spiking out this solution I was trying to do something similar. One of the solutions was to subscribe to Phoenix on the meteor server in the publish, and use low-level methods to send it down the socket.
However, you’re opening yourself up to a myrid of race conditions and limiting how much one server can scale. Node is really great at stateless requests like a JSON API but as one of the video from earlier showed, it’s hard to scale stateful websocket connections.
It’s quite possible to serve a million concurrent users with one Phoenix server and a few Meteor servers (enough to basically log in the user and return their profile). Offloading the initial Meteor index.html to a CDN can free up Meteor resources (i’ve benchmarked ~67 pages a second on a DO 1gb box to just server the index page).
If you proxied Phoenix through node you’re meteor cluster count would skyrocket because you can only scale so high vertically with Node.
Erlang was built from the ground up to handle this so it makes sense to let it handle it. Ironically this makes the system much much more simple than trying to proxy it though node/meteor.
At the end of the day I decided that all the extra work doesn’t buy you anything and doesn’t make life easier. Both ways require a knowledge of enough Elixir and Phoenix to setup a channel and query data ( a bit less if you’re using Rethink as it will push new changes down).
On the meteor client side all you need to do is:
// we'll use a local collection to store incoming data
Chats = new Mongo.Collection(null);
channel.join()
// prime minimongo with last 20 chats on join
.receive("ok", resp => {
resp.initialChats.forEach(doc => {
Chats.insert(doc);
});
})
/// ...
channel.on("new_msg", doc => {
// upsert because messages we sent will result in duplicates if we insert
Chats.upsert(doc._id, doc);
})
The amount you’d have to learn is minimal and it’s far easier than trying to write your own reddis pubsub to scale livequery. Like I said, no free lunch 
5 Likes
Thanks for the details. I still don’t see why not “cross that bridge when needed.” Like you said the server end of Meteor is often fairly straight forward. It’s great that Phoenix is there and it would be even better if there was a simple easy-breezy way to scaffold a Meteor-Phoenix project where you write your publications and methods on Phoenix and subscribe in Meteor using the same /Client /Server folder structure and then when you “Foobar Deploy” it does what it needs to do.
I don’t mind learning Erlang at all, I’m sure its a fine language.
Is there a sample project with Phoenix as the backend and Meteor on the front with instructions on how to get the Phoenix part up and running on Mac? I’d give that a try for sure!