Does It Make Sense to Start a Meteor 2.0 to Retain "Classic Meteor"?

@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 :slight_smile:

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?” :stuck_out_tongue:

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 :smiley:

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… :wink:

I very much agree with this. I see “future Meteor” – hereafter referred to as PAM (post-Apollo Meteor) whereas v. <= 1.4 is simply “Meteor” – as a build-tool. In PAM, Apollo is the data layer and it manages code that connects to data sources – React/Vue/flavor-of-today is the view layer and an Apollo plugin passes data into each component. PAM becomes an opinionated collection of development and deployment utilities (e.g. run web server + Apollo server + maybe spin up MongoDB in development, provide boilerplate shortcuts akin to Meteor.isDevelopment(), and perhaps facilitate hot-module reloading in development as a bonus).

Clearly, this functionality is a significant pare-down from today’s Meteor. That means builds are as fast and light as I think current tools allow (does it get faster than Webpack?). This also means that PAM is in no way compatible with Meteor packages. PAM would bear a new name, while what folks have referred to as “classic Meteor” can forever remain just “Meteor”.

This breaking change would be painful at first for devs who move on to PAM (before Apollo-compatible replacement packages are written), but would turn out to be a healthy choice in the longer run because it would foster a new ecosystem built expressly for Apollo. A clean split between Meteor and PAM would make it clear which packages fit with which platform.

2 Likes

For me Meteor has always been attractive because it’s the easiest way to do authentication, pub/sub or websockets, and in 2012, handling modules.

I think Meteor has a strong future with more than just a build tool. One of the things I hoped the “post apollo meteor” would turn into, is a very nice developer API on top of standard tooling that could be opted out of at any time.

For example making a really nice plug and play implementation of Redux, Mobx, etc… where it’s typically a lot of boilerplate to get it going. Instead of example apps they could have boilerplates with a convention and for different purposes (like user login). Perhaps a couple of standard authentication solutions could be provided (even if it’s just in boilerplate form), in order to work with other systems… basically preventing the walled garden issue.

Apollo has already done this by making GraphQL easier to use than any other solution, and were the first (as far as I know) to implement the cross platform GraphQL type definitions instead of verbose code.

5 Likes

Interesting. Do you see Meteor, then, as an abstraction built on top of those common libraries? Rather than Redux.createStore(), would you rather use Meteor.addReducer()?

I guess I envision a build tool because I struggle to see what’s left over when you remove Minimongo, (much of) DDP, and all the Mongo-specific packages from Meteor.

1 Like

So for Redux my personal take to setup React, Redux, react-redux, redux-devtools, and react-router-redux was this api. It sets up a router, wires up redux, react-redux, and redux-dev tools. It shouldn’t take 200 lines of code to set this up :slight_smile:

import {registerRedux} from './simple-react-redux'

export const {dispatch} = registerRedux({
  routes: require('./routes'),
  renderToElementId: 'react-root',
  reducers: {
    app:   require('./reducers/app'),
    posts: require('./reducers/posts'),
  },
});

and it could be further tweaked and augmented as needed for more complicated apps:

import {registerRedux} from 'simple-react-redux'

export const {dispatch} = registerRedux({
  // default options are overridable
  debug: false,                      // turns redux-devtools and logging on/off
  renderToElementId: 'react-root',
  disableLoggingMiddleware: false,
  disableDevTools: false,            // turns off redux-devtools middleware
  disableLogger: false,

  // pass in Routes component
  routes: require('./routes'),

  // router reducer is already included, add more as needed
  reducers: {
    app:   require('./reducers/app'),
    posts: require('./reducers/posts'),
  },

  // optioally add your own middleware
  middleware: [
    myCustomMiddleware(),
  ],
});

This is a wrapper I wrote a while ago: https://github.com/AdamBrodzinski/simple-redux-react

I guess I envision a build tool because I struggle to see what’s left over when you remove Minimongo, (much of) DDP, and all the Mongo-specific packages from Meteor.

Makes sense. I guess I always viewed minimongo as a really nice api/integration to an in browser cache/db like PouchDB.

I started out using Meteor packages for everything but stopped because there are so many bad ones out there, especially ones that don’t take performance into consideration. Building an app on these can result in something that crawls and is very brittle (Ruby on Rails has the same problem to be fair… the gem install hairball is too easy to save time upfront).

DDP is very cool but the lack of other systems being able to use it is a showstopper for me.

2 Likes

@SkinnyGeek1010 we are going on the opposite way here :stuck_out_tongue:

We were using s3 to serve a static web app built with Angular. After almost 2 years doing this we are moving back. 100% serverless app need to be deep studied before you implement that. Not saying that it’s your case, but it was ours (sharing experiences). At some point we needed to merge heavy API results, have a better control of caching and other stuff that are only (or way more easily achieved) with a server.

Agreed, but that requires a lot of compatibility. I thought that this wasn’t your goal here.

What about the npm module that creates a standalone DDP client?

I don’t think MDG would take to the idea of leaving potential customers to the “classic” business strategy. Therefore the metamorphosis into an Apollo integration point we go.

Apollo is the foundation for the new revenue stream. And every platform willing to open up is a winner.

1 Like