Help Tiny: Post Your Most-Wanted Features for Meteor

I was attracted to Meteor because of its original advertised features: real-time, DDP and most importantly easy Blaze. You can make an app within a week.

And now, what’s the direction? totally opposite. Why should I still use it instead of other more main stream frameworks? When you try to maintain the high end money-making user base with new features like apollo/react/…, you lose the new comers/beginners/hobbyists, which means it’s dying.

At least, I want a copy of the simplest original meteor/blaze.


We’ve implemented payments in our app, it’s not so hard to do with stripe, just a web hook really, but I think it would be totally specific to each use case. Sales are easy enough but subscriptions have rules that are business dependent so im not sure how meteor would develop this.


Yes it is. In my case I need multiple use cases. Subscriptions, single payments that can be split between multiple parties, reoccurring payments with the same functionality.
My goal is to create platform for creators where they can get supported like on Patreon, while also sell stuff and subscribe to premium services from the platform. Also when selling the payment needs to be split (sometimes) between multiple creators + platform cut. Well that is a tool set that not even most payment processors have.

Still if there was a single endpoint that would allow me to make, easy standardized method calls which would then get translated to the API of the service I choose, that would be quiet a help. But even after that, there are so many other additional things to consider, so that is why I said you will probably need something like Kill Bill if this should be of any more use beyond just an API wrapper.

1 Like

Support for Mongo change change streams to deliver reactive data sources instead of oplog - another enterprise security concern I’ve run into

If there is a way to emulate ddp over http instead of websockets - Websockets is a blocker for adoption at my corp because that protocol is not as nice to work with from a security, network tuning and monitoring perspective.

Developing on MacOs is awesome - but on Windows I freq hear gripes - have we achieved delightful windows development yet? i am not a windows user so am a bit out touch but the windows community is huge so would love to c Meteor as a first class windows developer experience

Finish and adopt work started by the community concerning React hooks

Develop patterns around serverless

An earth shattering amazing apollo integration


Isn’t change streams permission-wise exactly the same?

Speaking of a high-end user base, adding first-class support for SQL would probably triple Meteor/Galaxy’s revenue.

There is a worldview-bubble here – forum participants do not represent the wider world of companies that depend almost exclusively on “classic” SQL databases. That wider world, measured in budget dollars, is at least 1,000 bigger than the Mongo/Apollo world. Customers of that type have different sensibilities than often found in these forums, but those are exactly the sensibilities that Meteor originally appealed to. We are legion, and we:

  • Spend virtually no time in forums
  • Don’t want to “look under the hood”
  • Don’t care about the JS library du jour
  • Want ease-of-use, and to save time
  • Regard $100/month, for a service, as a rounding error

MDG has been fascinating via its mix of brilliant tech and terrible strategy. How did you lose Arunoda, a 20x dev and evangelist? A blunder for the ages. Next time, try money. (smh)

The original MeteorJS strategy was brilliant: among other things, it convinced VCs to part with 30 MILLION DOLLARS (Apollo came later). As you observed, htchd7, the project has since drifted away from the original, excellent thesis.

I urge the new owners to research and survey this much broader market, which has more customers AND more money (smh again). Were it possible to do so, I would eagerly invest money towards the above sentiments.


@efrancis thanks for sharing the article. Unfortunately it allows to run with jest unit tests only. Integration tests are way more useful with meteor IMO.

Chimp is the best option for Meteor integration tests and let’s you use mocha so it’s the same syntax as Jest. 2.0 is being worked on but 1.0 is still great

SQL is a must. Being able to have a product within a week is another must. Especially true for large corporations I’ve worked for.


There are a few things that are different -

Agreed, SQL support would be great

Problem of SQL support is how to achieve reactivity. I have played with this quite a bit, but it is at the “polling level” currently. Getting to reactivity like oplog (or redis-oplog) would require more work because you have to know how SQL statements impact results.

See this package and this issue for more info.

1 Like

I vote for new shiny tutorials and Meteor Guide revision.


I would love to have a better development experience in Windows, because of my work I swift around MacOS and Windows a lot and the reload times in windows are 10times higher than in Mac (which makes things a little annoying).


Apollo can be very helpful here. It supports client-side data cache, so data need not be refetched, optimistic UI, reactivity, etc. and is very easy to use with React.


Support for microservice.


Is there something preventing you from using blaze now?

Genuinely curious, did one of the recent update break it?


While i wrote this post, i noticed, there are two directions meteor could take:

the apollo route (probably what mdg wanted)

Embrace the ecosystem around react or vue and apollo: I think meteor’s biggest contender in this is next.js and nuxt.js. I never tried nuxt.js but i guess it’s similar to next.js. Both lack a data-layer however, which is usually fullfilled with apollo and any db (mongodb, sql, whatever). What’s also missing is reactivity, which made meteor really unique, but its also a not needed in many projects.

So to seperate it from next.js I would:

  • deep and seamless apollo integration. Seriously, this was promised by mdg, but never done properly
  • out-of-the-box authentification&authorization through graphql and meteor’s account system
  • out-of-the-box reactivity using graphql-subscriptions, websocket-channel and some pub/sub like redis for cloud-environments
  • client-libs if needed to help with these features for react and vue, building upon apollo-client
  • out-of-the-box integration of apollo-platform (optional, but mdg could be interested in a deeper integration)

and maybe:

  • give a good migration path from ddp-pub-sub to apollo so that we can deprecate ddp-pub-sub, because it is holding meteor back.

Having said that, here is the other path:

2. back to the roots

You can create a stack like described above without meteor using current best practices. This is initially more effort, but gives you a flexible stack.

However, meteor was great, because you could setup a project so fast and it needed nearly 0 configuration. So tiny could just add some missing pieces to meteor:

  • focus on ddp-pub-sub, add missing features, make it scale using
  • focus on one view layer, maybe even go back to blaze or settle on one of the others
  • first-class router and server-side-rendering

Personal thoughts

I guess mdg themself had the same thoughts about which direction meteor could take. This resulted in a split of the community. Some prefered to stay with the original way, others migrated to react (or vue) and graphql. Arunoda, who contributed a lot to meteor also did not believe anymore in the original, monolythic nature of meteor. I also share many of his thoughts. Meteor in its original form (blaze, mongodb and pub/sub) is a dead-end. It’s great in the beginning, but its hard to scale it application-wise, e.g. add more clients like native clients, split the backend in services, integrated other services, etc. (of course its possible, but not without a lot of research, experience and effort).

So i personally would love to see it going in a direction like these create-xxx-app:
They create an (opinionated) setup using best practices, but hide the configuration until you “eject” it. So if you need to diverge from the original setup, you can eject a part of it, and customize it. This could give the best of both worlds.

Some words for mdg/apollo

I think giving meteor to tiny was the right decision, but i would love to see you guys give us some of this sweet meteor magic in our apollo-stacks. E.g. build a library for next.js that adds easy authorization/authentification through apollo. Or a library for 0-config graphql-subscriptions. Or a nice orm-layer, a 0-config prisma2/photon integration would be awesome.


It’s no longer maintained and updated. No new features.

That scared people away from it.

1 Like

There’s such a thing as a library being “done”. If it’s not mired with security vulnerabilities due to neglect, it could just be the case that it’s “done”.

It could also be the case that MDG got pulled off onto apollo before they finished it, and now it’s “good enough”.

Hopefully with the Tiny aquisition, it gets some more support. I’ve never used it myself, but a lot of the meteor projects around the web use Blaze, and it always looked like a nice option.

1 Like