For me the biggest issue has been backend issues in the past few months.
The two issues that bother me in particular are:
MUP and mupx not being developed anymore (MDG was never behind mup and it hurts them from a business perspective, but I hurts meteor that isn’t being maintained anymore. No one is at fault. It’s just the state things are in right now.)
there has been an infinite refresh bug for a while and it has affected multiple different websites, but no fix has been made (or attempted fix has been made).
While I personally feel many posts here are overblown, I can sympathize with where they are coming from:
People got burnt due to recent changes (or more likely than not, the way they were communicated)
People want to make sure MDG is staying profitable and healthy – while Meteor has a clear path to monetization, Apollo in itself, does not. Hence some of the questions.
Thanks to you and @marktrang for taking the time and your patience with some of the less-than-pleasurable questions appearing here. Your candid approach is a breath of fresh air.
Yes. The strong reason for using mup is that this is what I’ve been using for the past two years. And galaxy is 3 times the cost. I will have a look at this project. Thanks
Galaxy is a production-grade hosting system with scalability, uptime SLA, support built-in. Our own costs with production-grade deployment are not that far off. If you have a real App, with real users who expect things to work, you will have deployment and maintenance costs.
We tried using MUPX which is built on top of Docker. It was great as we were learning the ropes, but then moved away when we started knowing what we are doing. We didn’t like the fact that it was difficult pushing multiple instances, we don’t see the need for Docker when your server is fully dedicated to a single meteor app (and it adds a layer of management – see here https://www.andreas-jung.com/contents/the-case-against-docker).
Meteor is not marketed in this way (as a web-app pioneer that creates great libraries), it is marketed as an easy and quick way of creating webapps for a variety of different platforms using the same code.
One of the newsletters even mentioned a website built by a 12 year old. I made a simple app that used CollectionFS and graphicsmagick in Meteor 1.2, which was easier to abandon and start again then upgrade to 1.3.
So while the libraries that come out of Meteor may be great, it would be far better to not invest in Meteor as a developer but wait for libraries to be released and assessed.
My experience is that your users are definitely not prioritised.
I think Meteor’s number one problem right now is the lack of trust in the platform, both from MDG and from the community.
Most people who have used both Meteor’s package system and NPM seem to agree that NPM sucks in comparison. But I don’t know if Meteor’s package system will still be around a year from now, so I’m switching as many things as I can to NPM.
I like FlowRouter, but I don’t know if the Kadira team will keep maintaining it, so I switched to React Router.
I could tolerate the slow build times for now if I thought they would improve in the future, but I don’t know if they will so I’m looking into switching to Webpack.
Minimongo, pub/sub, methods, etc. work well enough for me (although they could definitely be improved) but I don’t know if they will see any further development in the future so I’m thinking about switching to Apollo.
And of course this is a vicious circle: the more people jump ship, the more anybody remaining is incentivized to follow suit and jump ship as well…
@sacha I totally feel your pain. But isn’t this the issue with open source in general? When are you sure that there will be updates when we don’t pay for big lawyer contracts guaranteeing support?
It’s nice that everything is backwards compatible, but that doesn’t change the fact that the “old Meteor” is slowly getting deprecated. We can act like it’s not by saying “you can still use it”, but that simply doesn’t cut it. We have the choice of either moving with Meteor, migrating all our apps, or get stuck with something that only some enthusiasts (or poor souls) are maintaining.
I think MDG is doing great stuff and what they are developing now, like Apollo, is awesome. But the new stack they are creating simply isn’t the same thing as the Blaze/DDP/(Mini)Mongo/Methods stack they used to have. A new name would almost be in place…
Our options:
Move to the new Meteor stack and (hopefully) we can work with it for a long period (in a fast moving JS scene)
Stick with the old Meteor stack, because it’s working just fine, and do a lot of maintenance ourselves in the near future
Drop Meteor and use our own stack, build from parts already available in the wider JS community, but with a lot more boilerplate
Conclusion:
Yes, MDG is doing some great stuff, but a lot of people who invested heavily in the previous Meteor stack have some very hard decisions to make. These posts do not come from no where…
Non-professional dev opinion here:
For me important that everything just works and development goes smoothly and easy, it was as this before 1.3 version, a ton of docs on blaze and meteor and blaze as MDG product was always well suitable with meteor. But then, MDG announce deprecating of blaze and switching to react. Okay, after few month I think I understood react and love it, but still, struggle with integration. Meteor guide written with blaze in mind, react part, to be honest, using not the latest and best react way practices and you should dig the internet and collect piece by piece the information and figure out how to integrate this with the meteor.
Now it seems that meteor is unbalanced. I really wish that MDG collects all pieces together and make a great full stack framework again with react, apollo, meteor, etc. Which just works from the box without digging the solutions for this and that.
P.S. I don’t see anything better among JS frameworks to switch from meteor and I will wait until this dark age is over. I believe that meteor will be great again!
So why on earth is Apollo beeing thrown into meteor? Instead of running the the rat race of keeping up with the JS ecosystem, make meteor a part of it first.
Meteor is Node. Node is JavaScript. And when people say, they can’t use another DB than Mongo with Meteor, than they either mean “they can’t use another DB reactively with Node” - which at this point, Apollo can not do either - or don’t understand that Node.js supports all DBs since ever. There is literally no change in value proposition.
Empowering the JS Community with meteor via fine grained availability of npm packages (resembling meteor) and than targeting special areas (such as Apollo) would take down pressure on so many ends instead of stressing limited engineering power for X and Y. For example, if the (terrible) meteor build tool does not keep up to expectations, it can be switched out by something else - leaving other aspects of meteor (node) untouched, while staying compatible to npm infrastructure.
The constant change in roadmaps is really a let down. If there is a wish for growth, make sure people can do a npm install meteor and gradually adapt the system. Than Galaxy can serve as the soundboard of high performant reactive apps.
Man, you really need to stop your transactional thinking. Open Source is a Multi-Sided-Market.
Just like the case of Whatsapp: “We” - the “user” - do not pay money, but rather time and dedication. That in return creates value for other players, who may monetize “us”.
So your comments are not really helpful here, because the community is not the place to monetize the product, but the reason that a product can be monetized at all.
I like Apollo and the freedom it offers in terms of databases. And at the same time understand that people are frustrated that the parts publications, blaze are possibly being deprecated . js community is fast moving and we need to embrace that. When we build apps for Clients make sure you take in to account the extra work maintaining it if u depend on the is stack .
Meteor is modularising and its a good thing. Maybe in the near future there will simply be Apollo and meteor accounts. And meteor build tool might not exist. Webpack or any other might replace it.
We just need to know the future risk and plan accordingly. At the same time appreciate MDG for their hard work esp @sashko@benjamn who interacts with the community ! Awesome work guys.
I’m on Meteor 1.2.2 and use mup to deploy to an EC2 instance. When I upgrade to 1.3.5.1 and use mup, the setup passes but the deployment fails. I haven’t tried mup, but here that devs are having issues using that when moving to 1.3.
I haven’t tried mupx, but the only success I’ve had was using vanilla docker 1.2 for mac and following these instructions.
Now I’m trying to learn about docker and deploying that to an EC2 instance – but this is a real pain and I’m not sure this is the right route for me yet.
It was so simple when everyone was using mup, and it just worked.
I’ve opened threads about this, but no one seems to have the answers (or is talking) when it comes to deployment.
All this has side tracked my upgrade efforts to 1.3 and my migration to React/Apollo. I hope the community can get the upgrade path and deployment story straight in this new NPM/Apollo era.
Meteor is now moving towards production and enterprise. I therefore expect quite a bit in the ecosystem to move in that direction. So MUP, Cluster and all that were (in my opinion) hack-like technologies. I can’t imagine real production working that way.
Deployment is a big deal. If you have a sysadmin on hand, they will likely have a deployment system setup like the one we had proposed in our Github repo (https://github.com/ramezrafla/meteor-deployment). In fact, meteor has a deploy command for Galaxy. All this is painful, I know. 99.99 uptime is indeed a challenge.
Right, I reviewed your scripts, but on a fresh EC2 instance, where’s the script to set up the environment (i.e. node, npm, fibers, etc.)?
Galaxy is way too expensive for my small startup mate. I’m going the EC2 route, where I can get a hefty box for cheap. I’m on the fence when it comes to the remote mongo installations – they’re very expensive for the resources you get.
Keep in mind that the discussions that happen here on Forums represent only one facet of the “the Meteor community”; we also take into account direct feedback from paying customers, official consulting partners, and lots of datapoints from other channels (e.g. Github, Slack, broader JavaScript community). As a result, sometimes our decisions or strategy may not totally serve the demands voiced here. It’s not because we don’t care; it fact, it’s quite literally the opposite. We’re a fairly cerebral bunch here at MDG and make practical decisions based on a large (yet sometimes incomplete) dataset about the software market. In order for MDG the company to maximize adoption of our open source projects (Meteor & Apollo), we sometimes need to make decisions that aren’t popular among some long-time community members here on the Forums.
I’m also not totally sure the the Meteor community wants or understands how to “make sure MDG is staying profitable and healthy”; my posts on this thread are an attempt to illuminate some of the complexity of balancing our open source and commercial strategies. Specifically on Apollo, I can assure you we’ve been building monetization paths since day 1 of the open source project as we’re already generating revenue from tools and services related to Apollo/GraphQL.
