We can’t wait for Apollo, we have a deployment that is choking because of the oplog mis-deign.
Also, we don’t really want to invest in FB ecosystem, our stuff works and works well, so why bother switching just because something is in the best interest of the platform provider? We like pub / sub.
Finally, we have resigned to the fact that we have to start putting devs into meteor anyway to get what we want.
But they’ve already shown they aren’t super interested in things like making a build tool (see Saturn as an example of an effort they shutdown). They are hyper focused on the data loading pieces. Honestly, I don’t blame them for the choices, as a business it makes sense to me. Just sucks for the community that it will continue to happen slowly and quietly, as far as most are concerned.
I understand, but aren’t these two in conflict? The Apollo stack revolves around and integrates with FB-tech. Embrace the backend without the front? Won’t you miss out on integration points?
Please elaborate on this. Are you saying you think they’ll build out Apollo proper, without supporting infrastructure, in the classical Meteor sense.
So the work you-all are doing to ingrate RethinkDB into Meteor-classic won’t be lost by moving it behind Apollo?
I personally think that Meteor is changing forever, in a direction that supports new business, not current community. So regardless, we are on our own. So might as well start digging into it and improving it and start sharing with the community.
If things go south, we will simply maintain our meteor fork and slowly migrate out into expressjs, socket.io and so on. The Meteor code base is very solid and can be a great foundation.
I thought I have weird feeling when the whole UI babble started. These two paragraphs sum up best what’s happening. Time for all of us to roll-up the sleeves and try to make the best of what we got already.
I don’t like what they did and how they handled it. We need to hedge our bets better in the future.
I’ll give you once sentence: MDG sold us a bill of goods with Meteor.
Sorry. I suppose I didn’t click on the right ‘reply’ button. It is @ramez’s post above.
Yeah, I’m afraid so. But when you have apps written on top of it… you have to plan the best approach to maintenance. So you keep going.
Yeah, in hindsight I think it was MDG’s burning platform memo.
You have a deployment that is choking because of oplog? What…
Don’t get me wrong, that might make sense, but let’s look at the facts (that, by the way, are from real live people, not avatars on a forum site).
ClassCraft has 600k total users and 5k-10k users on their application at a time, and they’re full on Meteor with MongoDB. It appears to me that they haven’t had the scaling issues you’re talking about and their CEO and Lead Developer talk about it all in this video.
So I’m sorry to ask a question like this, but are you speaking out of your ass? If not, can you please cite some sources and tell us about the application you’re running into problems with?
I’d like to know, and many other prospective Meteor users would like to know as well, so that we can determine whether Meteor is the right stack to continue developing our pre-launch applications in.
At this point I’m tired of all of the opinionated FUD that is unsourced and unsupported by facts/statistics and just want some real facts, statistics, and company names.
And to target the concerns about Meteor focusing on data loading (Apollo) only:
THAT’S GOOD, AND THAT’S WHY WE USE METEOR.
Really, haven’t we been complaining about slow build times, lack of NPM integration, and lack of being modularized?
Those are just a few of Meteor’s flaws. And we put up with those flaws because Meteor makes data loading easy.
MDG has found the main pain point, and I applaud @gschmidt, @debergalis, and the rest of the MDG team for realizing that pain point, understanding that they can’t do everything, and focusing on what’s going to keep the Meteor community (not necessarily Meteor) alive.
That means we get our data loading happiness, and we can use NPM on our own (with webpack from the heavens), and deploy to Galaxy for effortless DevOps and scaling.
Everybody wins.
(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)
@aadams: you’re almost funny and I think that’s a great attempt to distract from the main point of this thread and garner a lot of likes.
Take a deep breath there @mz103, the gif was simply an attempt to point out that you could have worded that better is all (in a lighthearted way I might add). Also, @ramez is an active contributor to this community, and I might add, has kindly helped me and others on several occasions.
Thanks @aadams for your kind message.
@mz103, while I do believe your messaging needs to be sanitized (i.e. less rude) here is our situation. We are not young techies with no experience. On the contrary. Our application is very intensive in terms of reactivity. Also, I have tremendous respect for both meteor and MDG, and this is evident in my posts. Business is business, for them and us.
I can’t speak about classcraft, but I doubt there is as much data being sent back and forth as with our app (http://www.zegenie.com). Our app needs to have a very low response time (it’s a live continuous classroom control app). Also, there is price sensitivity of this market. We can’t just scale up blindly as it will eat our margins.
So a mix of business and tech issues. If you look at my prior post I went through some technical details.
Let’s say a district of 200,000 users purchase licenses. They expect them ALL to be operational AT THE SAME TIME. They expect live real time reports. Classcraft is a (1) side app and (2) the amount of data shared is going to be less.
AND they probably complained about this same issue too – which is why MDG recognized scalability as an issue.
[EDIT] As we are likely among the most reactive, it makes sense for us to take destiny into our own hands and support meteor development. This is what community is about. But oplog trailing … not gonna cut it!
As for my saying “Dyning” I think it’s the perfect term to describe what is going on, when MDG attention goes from PUB/SUB it means no more updates in that area and with no support it will die, I use pub/sub on small projects but it definitely will be dead when something else takes the attention (apollo) and I started using it, because it’s much better for bigger projects.
I feel like some of the pub/sub DDP dying stuff started because of the UN Meteor Camp talk by @arunoda…
Yeah, but @arunoda also abandoned most of his Meteor projects, without even bothering to help the community to pick up any of them, even when asked to via email (see FlowRouter).
Very talented man, and company, but ever so inconsistent it seems. The talks, predictions, and blog posts… Most of them about their own projects, now ailing or just dead. Kadira is responsible for on of the longest trails of abandonware in the Meteor community, so do take everything you hear from them with a good spoon of salt.
Instead of contributing to FOSS, you make demands on those who have already made incalculable efforts for not giving LTS. Interesting choice.