Meteor’s data system only works with MongoDB. Horizon only works with RethinkDB. Firebase only works with a proprietary service. Apollo works with everything.
4 Likes
Isn’t this the point of versions? If you want the stuff from 1.3 and not from 1.4, then you just stick to 1.3. And with the recent update to Meteor to decouple specific package versions from Meteor updates, it’s even easier to only get the updates you want.
If there’s one thing I would like to see in a future Meteor, it’s the stopping of automatic importing and no longer needing the imports folder to do it. I, like many, used to love the ease of simply adding a file and things working, but now, having built a large project, I recognize that imports are the way to go. Since this would be a breaking change, it would have to be in 2.0.
2 Likes
What these systems do with specific databases were pure fantasy before Meteor came along. I’m no expert in JS frameworks and history but as far as I know Meteor was the first to make it dead easy to move data between client and server.
If you told anyone how easy it could be, even if it was tied to a DB/service, you would have gotten a condescending pat on the head and “That’s a nice dream, but here in the real world…”
Saying it has to be hard because Apollo works with everything is like saying “moving data between client and server has to be hard” back then.
3 Likes
i’m down for anything if my build times are faster lol.
20 Likes
Yep I agree. I was thinking a 2.0 is clear to everyone that it’s a breaking change. It also allows MDG to set the build tool aside and start with something (anything) faster. Also it’s a clear marker in a different way of thinking about the view and data handling. It would be easier for people to keep packages up to date if this were that case as far as I understand, since atmosphere packages would not work on 2.0 at all, one could still assume mongo, accounts, etc…
Yeah I figured you guys have already been down this path. I wonder if it were re-asked with a strong priority on maintaining security fixes if that would change their answer? I also understand that the most vocal on the forums may not represent the community as a whole.
2 Likes
In fairness those same users would also have said they wanted support for insert favorite DB without migrating to Apollo if you had given them that option.
Really I think how this conversation is framed has a huge impact on what people will say.
If you give me the choices of:
- You can have a much faster build tool with lazy loading that is used by the larger js ecosystem in a relatively short timeframe but you will have to migrate some code.
vs.
- You can have a somewhat faster meteor specific build tool possibly without lazy loading in a longer timeframe but you won’t have to migrate any code.
Despite having a production Meteor 1.3 app, I really think I would choose the first option for a number of reasons:
- I don’t believe that improving the existing build tool is in line with the refocused part of the MDG philosophy of working on things that have wide applicability
- As part of the above I think any improvements will be a stop gap rather than an attempt to make the build tool more widely adopted
- I believe that MDG could come up with a relatively easy migration path
- I think it would take less time for MDG to do it and maintain the ultimate solution, freeing them up to do other awesome things
- It’s something people in the Meteor community want - sure some would want it only if it comes with backward compatibility, but for many I don’t think that is true
@sashko, my company is using 1.4, but just to keep updated, let’s say that we are coding in 1.2 style. From a company view, backwards compatibility is important, but not critical.
If MDG announces that is going to follow this path my main concern would be about support. We are used to incompatible versions. Of course that if you ask I’m not going to say that again 
But why do I want that? Simple, I want a stable meteor classic version. A version that I can rely on without thinking about what’s going to happen next. We are already following different ways, why not make this official?
Let’s keep in mind that I’m not talking about rewriting everything if I want to migrate. But maybe 1 or 2 weeks of work to go from 1.4.1 to 2.0? That’s ok.
If we keep pushing new things inside the same version a lot of things that I use on 1.2 will desapear over time, but not for me. With different versions we can release a 1.5 version with fixes that makes more sense for blaze users, for example. Are we going to do this with the current state? I don’t think so.
1 Like
For what it’s worth, the path to migrating Apollo/GraphQL is fairly straight forward with React. I presume Blaze will be a bit more tricky but i’m not sure. I’m also going to take a stab this weekend at recording a screencast doing just this (with React).
The largest hurdle IMHO is moving to page/template based subscriptions. Once you do that you can remove a subscribe call(s) one at a time and replace those with Apollo and the children should re-render just the same.
With React you would likely use the apollo-react module and replace getMeteor data with that (essentially replacing this.data.posts with this.props.posts.
With Blaze maybe setting the response data into a Session or local minimongo to keep the view templates the same. I think eventually someone will make an adapter much like the React one which can cleanup boilerplate.
[quote="moretti, post:18, topic:29058"] _Let's keep in mind that I'm not talking about rewriting everything if I want to migrate. But maybe 1 or 2 weeks of work to go from 1.4.1 to 2.0? That's ok._ [/quote]
I think the main benefit of potentially doing a 2.0 is that you could free the large barnacles, like Meteor packages and packager, minimongo/mongodb by dependency, etc… Otherwise a 2.0 wouldn’t do much good. If one was using classic Meteor that would be nearly impossible to quickly migrate to without those.
Anyway just throwing around ideas. I really doubt a breaking 2.0 change that’s not easily upgradable would happen. I guess a new product/name would be more ideal than that.
In two weeks I can (including my team) change packages to npm (if available) and do some good changes inside the app. I agree with you, but it needs to still be Meteor. Otherwise, let’s change this tread to “Does It Make Sense to Start a new Product?” 
That’s where we are coming from as well. Apollo is the “new product”, it’s questionable whether it’s valuable to rebuild a whole new full-stack framework from scratch, which is basically what we would be talking about if it wasn’t something current Meteor apps could all migrate to, and it didn’t use any of the parts of current Meteor.
1 Like
@sashko my opinion remains the same about what should be 2.0, but thinking about the other side:
I would fork (if needed) and create a separate product. By not doing this and keep improving (it’s pretty clear where MDG wanna go, for me) my guess is that new Meteor will replace the old one.
Having a more complex / extendable product is fine, but calling it 2.0 means, at least for me, that at some point I can migrate. I understand that there’re branding and business discussions around this, but that’s my point as a developer.
Maybe with this scenario it’s time to assume that the new is the chosen one and leave Meteor as classic? And, of course, to community.
Developers will always want compatibility. It’s a silly question. But what does it really takes? For you, as a Staff, why are you considering this?
We’re using Meteor 1.4 in production for two apps. So we’re not really keen to make something totally new ourselves either.
2 Likes
It’s interesting to me to think about this kind of issue, because I don’t think there’s every really a right answer.
I think what would make sense to me to have a fork/repo with the core packages (and maybe a router?) from 1.2 that a Meteor newbie could clone to get started with the basics of accounts, pub/sub, templating, methods, etc. If devs are keen on running on this antiquated stack, I could see security updates supported by production apps running at 1.2?
Otherwise, for me at least, every 1.x release so far has been worthwhile in terms of how long it’s taken to migrate and the payoff. (Of course it’s not always so obvious in the middle of broken deployments, etc.)
I guess I’m curious what the real issue is here. Is the cost/benefit to the current migration and upgrade pattern not working for a majority of devs/projects?
We already do ship security updates for 1.2 as necessary - we’ve historically shipped patches for every release since 1.0 in the case of security issues.
3 Likes
Sorry, not trying to throw you guys under the bus! More just thinking about long term strategies for 1.2 =)
1 Like
Exactly my point, over time mdg will have other priorities and issues with minimongo, for example, may not be fixed.
1 Like
Sure but if that’s the case we will certainly accept fixes from the community and help enable community maintainers.
1 Like
For me, it would make sense to slim down Meteor.
If Apollo is the new 2.0 then let’s strip out from Meteor what does not make sense anymore, that is what Apollo does better.
Meteor should then be installable via npm, as already on the roadmap, and be developed focusing on just few awesome features that can make it stand out from the crowd once again.
We would use standalone Meteor for easy, not complex stuff, and add Apollo for the supa dupa projects.
3 Likes
I think it’s worth mentioning that if you don’t want/need to have data handling with Apollo/non-mongo databases then it’s still ok to keep using pub/sub 
I have a Meteor app that is 99% clientside and the only server bit is logging in. I’m planning on migrating this app to a static html/js deploy via S3. It’s already using imports, React, and Meteor methods (to another Meteor server acting as an API) and npm based packages.
The planned migration path for this one is to migrate login/signup to REST via the Meteor rest package (on the API) and then switching Meteor methods to Apollo mutations, and a couple subscriptions to Apollo queries. It’s slowly getting migrated.
For really complex apps with lots of packages using pub/sub I think the best migration (if needed) may be to accept that the app will use both pub/sub and graphql and then slowly migrate to graphql as you add features or improve/bug-fix old features.
1 Like
Also after re-reading my last post I don’t mean to come across as migrating away from Meteor, rather the flexibility if gives you if your business needs require it.
I still have 2 apps that are 100% Blaze, Pub/Sub/, autoforms, etc… 