Beyond Meteor

This is a place to centralize questions about how we could one day move beyond the Meteor ecosystem.

Package-based Architecture

How does NPM handle package-based architectures? Should we use Lerna.js?

To clarify: in Vulcan’s current architecture, 100% of the code is inside separate Meteor packages, there is no “app” code per se. This means the entirety of the codebase can be overridden on a package-by-package basis if a developer needs to do so.

Server/Client Split

In a Meteor package you can do:

  api.mainModule('lib/server/main.js', 'server');
  api.mainModule('lib/client/main.js', 'client');

What would be the NPM equivalent? Can import foo from 'foo' have different values on the client and server like with Meteor?

What about things like

if (Meteor.isServer) {
  //…
}

Fibers

Where do we still rely on Fibers? Could we replace this by async/await code?

What about Meteor.wrapAsync? Meteor.bindEnvironment?

Meteor.startup(…)

What is the equivalent of Meteor.startup() in, say, Next.js?

Accounts

What do we use for Accounts? Auth0? Can we still preserve backwards compatibility with existing Meteor accounts?

Mongo

What do we do about Mongo.Collection? How do we run and connect to Mongo? What do we do about Collection.find()?

[SachaG]

@jay-jlm Migrating away from Meteor is not currently on the roadmap. I think it’d just be too much work at this point and would kill any momentum Vulcan currently has. Let’s see how far we can go with Meteor for now 😃

[SachaG]

Here’s an unofficial timeline for the next couple months:

• August: release OpenCRUD version with new API.
• September-November: work on Apollo 2.0 and React Router 4.0 version (work on client side first and optionally add in Meteor SSR support later)
• December-January: depending on current state of the Meteor ecosystem, work on Next.js migration.