So that means we will be able to turn DDP/livedata/etc. off? Will it be done automatically if we choose to go with Apollo? Does this also not mean that if we choose to go the Apollo way, we will have to leave DDP behind once and for all?
Automating all this configuration based on selections will be very neat, if that’s what in the works. I think this is a very good movement.
Sorry, but as my reply on the pull request stood with various open questions for two months, having an npm integration is magnitudes more important to residing teams than the next feature slammed onto meteor.
We should try out apollo with the meteor build tool? No thanks.
To those who are interested in real time systems that integrate well into existing build chains, you may want to check out http://horizon.io
The video on the landing page also addresses the short comings of Meteor for npm and it’s build chain friendliness; which is one of the goals of horizon.
-> Get meteor on npm
-> Get apollo on npm
-> Archive the integration this way!
Is there any reason why MDG should give this a higher priority than the database thing? One of the biggest disadvantages of Meteor is the focus on MongoDB. If you need transactions you may go with a SQL database, if you need scalable live data you may go with RethinkDB - but both databases are only available with unmaintained plugins.
Adding Apollo into the stack is the next logical step for me. MDG doesn’t have enough resources to maintain all feature request at the same time - but I think we all know, that there will be an NPM version of Meteor in the future.
Grüße nach Köln
Most projects have already some sort of integration into node js currently running. It’s a no brainer to use meteor as a delivery pipeline as soon you add it to the existing node environment and are not required to transform the whole pipeline first.
And I don’t say apollo should take a massive step back, I love the project, but implementing it into the inflexible meteor build chain that receives continous heat over the past two years - gets sometimes more - sometimes less attention - is a nightmare.
(For years now, threads & problems like this Ideas For Faster Reloads )
I want to see meteor on the reliable and professional managed npm system with the rest of the JS community and than welcome any feature addition to the meteor system, leave it for installment via npm, or not.
I am personally really sick of “teaching people meteor” even though everybody already knows the node and npm environment perfectly well. And the barrier of acceptance is just getting larger. Especially in an Agile/Scrum driven environment.
Note: And rethink DB is a great data delivery pipeline.
Grüße zurück aus Köln 
️!
MDG Magic 8-Ball …
const numberOfPeskyCommunityQuestionsToAnswer = 3;
const potentialMDGAnswers = [
'Maybe',
'Definitely Maybe',
'Perhaps Someday Maybe',
];
for (let i = 0; i < numberOfPeskyCommunityQuestionsToAnswer; i++) {
console.log(
potentialMDGAnswers[
Math.floor(Math.random() * numberOfPeskyCommunityQuestionsToAnswer)
]
);
}
Well, for me one of the biggest current disadvantages of Meteor is lack of incremental loading \ code splitting - and they seem to totally neglect that one.
And also - they still don’t have a public roadmap available. Well, it’s 2016, I don’t even know what to say…
I also don’t really see why Apollo/Meteor integration is taking priority here… unless it’s for reactivity, it’s not impossible or even difficult to use other databases with Meteor currently
Well, I’t s not a roadmap, just a collection of fixes for 1.4 and possibly 1.5.
Would you call that a roadmap? Where are concrete features tied to concrete update versions? Where are dates? Where is feature list?
Even old trello roadmap was better.
Definitely true - I guess one of the main reasons why I’m excited to hear about this is that for the past little while, it seems as though MDG’s focus has been entirely on Apollo. I get why, and I’m really excited about its progress, but at the end of the day I still love working with Meteor (as we know it today), and am continuing to build successful apps with it. I’m happy to hear that MDG is still showing Meteor some love, and is going to be breathing new life into the platform with tight Apollo integration. Shortly after that I’m sure the next “monetization strategy” shoe will drop, but I’ve been so pleased with Galaxy that I honestly can’t wait to see what’s next!
Put another way, I’m happy to hear MDG isn’t planning on letting Meteor become introspective meme Pug …
Horizon is the future. After a few days with it, I’m convinced. It’s Firebase without the nasty limitations. If your app is CRUD or mainly CRUD, I’d strongly suggest looking at Horizon.
In terms of advancing Meteor, integrating Apollo is the most bang for the buck.
NPM integration is nice, but I don’t think it solves as many problems.
One of our biggest problems is that Meteor is its own thing right now. It’s a platform I love to use, but it’s always a hard sell having to be stuck using it standalone. NPM Meteor is top of my list as far as getting other people on board with it, though Apollo is right behind it.
The biggest issue is testing tools, Meteor not being on NPM makes this so difficult. It’s a place I don’t have full control either so it’s other teams trying to hack them in then stuff breaking because of meteors current import transform situation.
as someone building production apps for clients Apollo/GraphQL is by far the most important next step. At the moment if we can’t use Mongo that means no Meteor, and honestly, fine-grained control of reactivity in meteor is long overdue.
Having Meteor installable via NPM offers little utility in my world right now, and the developer experience in terms of getting meteor setup is pretty great. Would it be nice, sure, but Apollo definitely offers the most bang for my buck.
My personal experience with Meteor and it’s growing pains…
I used Meteor for 18 months to develop a product, but I then switched to webpack / react after blaze was essentially deprecated. At that time (1.3x), meteor build times were horrible, so switching to webpack was a blessing, my productivity and enjoyment returned. Since that point, build times have not improved so I’ve not developed on Meteor since, I won’t until it is npm compatible (so that I can continue using webpack).
I do feel this is most important at this point. I can understand why Apollo is attractive (taking the best of Relay / GraphQL and extending Redux) but it’s not going to bring me back to Meteor anytime soon. Especially when I can use Apollo without Meteor.
Despite the present growing pain, I do feel Meteor is evolving into a better framework release by release. Once the above are both resolved it’s future will look a lot more positive.
npm integration will make Meteor accessible to more developers as well as fix build and integration issues, which are both important. But it doesn’t change Meteor’s feature set or power.
GraphQL/Apollo integration is going to fundamentally make Meteor more powerful - no more dependence on Mongo, DDP may be deprecated in favor of something better, freedom to choose any DB/GraphQL backend, and better scalabilty/compliance with emerging standards are huge wins.
Right now Meteor is very opinionated and prescriptive - these are both its biggest strengths and weaknesses. We need a finer balance of integrating with the JS community while still preserving the ease of use, power and completeness that makes Meteor unique.
completely agree, and I think that solidifies the argument for doing apollo first. While NPM brings access, it’s apollo that will actually give the community flexibility and ease the ‘lock-in’.
