Question for Meteor Developers

For me too, ensuring that Vue 3 works well with Meteor is probably the most important element I’d like to see in Meteor.

In general, I intentionally stay very close to the out-of-the-box setup of Meteor (regular methods and pub/sub, accounts etc). If I need third party packages, I pick something from the wide node ecosystem and only such packages that are well maintained. This has served me very well. So in general I’d like to see Meteor development focus on the things that make Meteor stand out and are not easily reproduced with other tools (again, regular methods and pub/sub, the accounts system, perhaps the build system). In line with that, and given that development resources are limited, I would not add any functionality to Meteor core that is already well covered with npm packages (such as the recent call to add a job scheduler to the core).

Oh, and of course the Fibers/async situation needs work in 2022. But I am assuming that this process is already going forward.


Only one you say… Well, getting rid of Fibers, of course (Change how Meteor executes Async code · Discussion #11505 · meteor/meteor · GitHub). I hope it’ll get solved somehow this year, so all of the projects will have at least a couple of months to catch up with that (remember: support for Node 14 ends in April 2023). One of the first steps would be to get Mongo Package Async API by filipenevola · Pull Request #11605 · meteor/meteor · GitHub done.


I second what @radekmie. Continuing the trend of further alignments with NodeJS by having alternatives to Fibers.

I’m also interested in using Meteor as a backend ass JAMStack/PWA with DDP/SDK. I think this is an excellent combo and value proposition for Meteor that is not getting much attention.

Micro Frontends support (
I have 3 “sister” platforms using the same user login.
I want to have the same Posts Wall and Chat app over all 3 platforms.
Post Wall - 1 Meteor Project (its own scalability env)
Chat App - 1 Meteor Project (its own scalability env)
3 Parent Meteor Projects (their own scalability env)

I wan to have seamless secure SSO from parent to child and build the Parent client bundle as a Micro Frontend.

This would open the door to easy team separation by interest and make it more possible to work with outsourcing for pluggable front end parts of a larger platform.

Fixes deploy speed issues reported by some by deploying smaller bundles.
Tests run fast as only smaller junks of a project get tested by a specific team.
I can hire Blaze teams, Vue, React etc … at the same time.
Have APIs open to child bundles only where needed and not to the entiere project.
Endless back-end scalability.
Separate Oplogs for different parts of the frontend in the case of chats, trading, crypto, gaming, even separate redis-oplogs where necessary.


No more meteor add and Atmosphere. Just one way of package management. All packages are being added or removed by NPM for instance.

1 Like

I’m not sure about that one. Atmosphere packages support full-stack packages and allow package-based architectures.

It is a major advantage to the framework, not sure why it needs to ve removed, you can use NPM only if that is what you prefer.


mongodb Change Stream supports

Easy integration of 2FA that works via an authenticator app. :slight_smile:


fyi there’s a whole section out there on Meteor’s github where people upvote the features they would like to see.

That makes this thread imho rather unnecessary and mostly a repetition of what’s already there communicated to Tiny


Thanks for your feedback @satya. I can see why you might see it as repetitive but I wanted to get a general consensus and spark some conversation on what fellow Meteor developers wanted to add to Meteor, IF we can add ANY feature in 2022. :wink:

1 Like

Multi-region support in Galaxy


Yes I agree with others - fibers and Node 16 support. Anything that improves scalability and performance is also very welcome. For example this PR seemed interesting Batching Oplog Entries & DDP messages by KoenLav · Pull Request #10478 · meteor/meteor · GitHub but it couldn’t be merged for some reason…

1 Like

I think meteor is a pretty low-level framework and It really needs to grow and become a CMS, comparing it to Strapi or Directus, Meteor has a long way.

That’s my personal opinion after using the framework for 3 years, I feel it really sets you back when you have to write everything from scratch.

The framework has improved but it hasn’t dramatically changed since 2012, it’s still pretty low level.

Why not have a built-in admin UI where you can create data models, security, and create a built-in event/hook system where developers can write business logic.

I mean it doesn’t even have an ORM or uses mongoose, if I want to add GraphQL it would take me days to write queries and mutations.

A headless CMS like Strapi gives you a head start with all of that baked in and configured.

A lot of the packages that are used today are either abandoned or not very well maintained.

  • Node 16 and MongoDB 5
  • ESM direct dependencies support
  • async collection API
  • no more fibers or replace with something else if necessary (workers?)
  • Meteor API for MongoDB transactions
  • Official support for code coverage in meteor test

Sacha Greif (the guy behind “state of js/css”) indeed created a kind of CMS based on meteor, which was Vulcan.js. Its no longer based on meteor though, but on nextjs instead.

  • SSR with React and Meteor in a simple working starter project example
  • Ability to have a view instead of pub/sub being the default way of sending data to the client. In the case of a homepage view of data which doesn’t require pub/sub and is just static but database backed (currently had to roll my own to achieve this simple funcionality)
  • Native support for MySQL (mongodb is great but doesn’t perform as well as MySQL specifically the percona build)
  • Offline support built into core (groundb)
  • Memcache support built into core
  • JSON Rest API token auth built into web app and part of core so creating an API doesn’t require any packages and is part of meteor’s base
  • Rollback CFS file upload module to the non foobar’d original that still works (new version is DOA, broken examples totally briked with no support.)

:raising_hand_man: Meteor users collection with ObjectID suport in _id, no more Strings.

1 Like

Right now my pain points are:

  • ESM packages
  • Testing, code coverage, etc. (yes, there are solutions, but it is not straightforward)

Other potential improvements I would appreciate (that are not in development):

  • Official login with Apple package (so that official OAuth supports all the major players, especially since Apple OAuth is required if you want to have OAuth on iOS)
  • Support for more MongoDB stuff (after MongoDB 5 update)
  • More awesome stuff around accounts (discussed on GitHub)
  • Private packages on Atmosphere and marketplace for paid packages

I would also look into integrating some other most used community patterns into core, but there are more important things to consider first. This is a bit difficult given Meteor’s modularity, so maybe a few reference/starter apps can be created for each front-ends with the necessary tools for each included. I’m working on one for social apps right now.


Hi, this the list of features that I would like to see them implemented on Meteor:

  • Upload files as form-data over DDP
  • Backward compatibility of Vue 3 Integration with Vue 2 Integration (I’m very excited to use it when Vuetify 3 is released the next month! :heart_eyes:)
    • Make possible to subscribe to publications like in Vue 2.
  • Transactions support for Accounts methods like createUser, sendEnrollmentEmail, sendVerificationEmail, etc. Mentioned here.
  • Node 16 and MongoDB 5
  • Official support for code coverage in meteor test

Things that I’d change about Meteor

  • Currently, the functions receives as parameter a callback to get the response of the meteor method, however, some co-workers and I think that would be nice to invoke that function by using await statements, for instance:
async saveUser(userData){
   const response = await'', userData);
   //Do more things with clean code (avoid callback hell), either async or sync tasks

The purpose of using async/await is to keep a clean code and avoid the callback hell. Currently, we are using a wrapper for, however, it’d be nice to include this in the core of Meteor.

  • Another thing that I’d change is how to subscribes to publications, since currently you need three things in the client side to invoke a publication: publication name, parameters and the collection which is used to return the cursor of the publication. So, I’d like that publications only receive the publication name and its parameters, without specifying the collection. So, I imagine to invoke publications with this new way:
//Client side
const subscription = Meteor.subscribe('users.list', params);
const reactiveData = subscription.findData(selector, options);//or just use: subscription.reactive() if no longer possible to use parameters with this new change.

I don’t know if this change is possible, but this would fix an issue that maybe many beginners have had when they are learning to use publications, which is the combination of data when 2 publications use the same collection and they’re invoked by the same client at the same time.

Features for Meteor 3.0+

I have been working in my current job with Nest JS and I can say this a very good framework to build web apps (actually APIs) based on REST. It’s is very similar in some way to Spring Boot and Laravel frameworks because have a well-defined directory structure and entities which allow to developers follow the same pattern to build apps. So, in Meteor we have in the documentation an example directory layout but it could be much better if it copy things from other frameworks like Nest. I know that Meteor is an isomorphic framework, so, I guess that is the reason because it can have different layout structures but maybe it’s better to have a standard structure which allows to new meteor devs have a concrete shape of Meteor framework to build apps and at the same time in an even faster way.

So, this is a list of features that Meteor can copy from other frameworks:

  • Have an standard directory structure
    • I use Meteor with Vue in the same project because Meteor allows to have both directory structures, for back-end and front-end in the same app. So, the standard directory structure which I mean, it’s specially for the backend which it should include folders to store files like middlewares, controllers, publications, services, dtos, models, helpers, constants, etc.
  • Create some commands for meteor-tool to create file templates (for back-end only). For instance: meteor make:controller products and a file is created with the validated method. So far, I have in mind commands to create controllers (validated methods), publications, services (business logic) and models (data layer). Also, it will be needed a flag to create a meteor app with the standard layout. For example: meteor create myapp --standard
  • Use Typescript as programming language for standard meteor apps.
    • Nowadays, it’s well-known that many companies are using TypeScript instead of pure JavaScript, since you can avoid bugs by using data types and this helps to build scalable big applications.
  • Include Astronomy for standard meteor apps.
    • Nowadays, all web frameworks use an ORM (Object Relational Mapping) for the data layer. Just to mention a few examples: NestJS uses TypeORM, Laravel uses Eloquent and Spring Boot uses Spring Data (based on Hibernate). Although Meteor uses a NoSQL database with MongoDB (which has primary support), its ODM (Object Document Mapping) is Astronomy since AFAIK is the only one created for Meteor and it works very well. The only thing it needs is to add transactions support in the main repository, but I have done a fork and I published a new version of this package in Atmosphere, however, it will need its typings of TS with this new version since the original typings only work with original meteor package which is jagi:astronomy.
  • Use NPM as Meteor’s only package manager.
    • When I started to learn Meteor, I was wondering what was the reason that Meteor didn’t use NPM as its package manager and I found that it was because Meteor was released when NPM was in its first versions, so, maybe MDG wanted to create their own package manager because NPM was not as developed at that time. Nowadays, npmjs is the platform with the largest number of packages (more than maven, composer, pip, among others), so, I think if Meteor use NPM as its only package manager, more benefits will come, for example: more nodejs/javascript developers could contribute to Meteor by creating only npm packages because it would no longer be working on a single Meteor ecosystem, but rather it would be using possibly packages that use other Node frameworks (such as Nest, Express, Electron, React Native, etc.). Also, another benefit it would be that deployments of meteor apps would be faster with an implementation of other NPM modules which are used by other frameworks like Express or Nest. Maybe this is an impossible change, because it would mean to migrate all meteor packages to NPM, but if we start to standardize meteor applications, we can identify the packages that would be worth migrating to NPM.

I have already some projects created which bring some of the things mentioned above. So, they’re the following:

Scaffold Meteor Vue (Complete version)
Scaffold Meteor React (Still in progress)

It’s worth mentioning that I have already some apps in production with some of these things, and I have been improving the scaffold when start a new project.


Backward compatibility of Vue 3 Integration with Vue 2 Integration (I’m very excited to use it when Vuetify 3 is released the next month! :heart_eyes:)

Regarding this point, I believe Meteor should sponsor Akryum. As Meteor takes special care of the React integration, Vue should be no different and they already sponsored @zodern and @storyteller for some work.