What if Meteor Was Created in 2025?

core
21

what I meant is that Meteor is not just about reactivity. If it were only focused on that, we’d probably be talking mostly about backend concerns.

The truth is, Meteor has evolved into something much broader: it’s a productivity framework. It gives developers the tools to ship production-ready applications incredibly fast, and that’s one of its strongest value propositions today.

That’s why I think this discussion shouldn’t be purely technical. We also need to focus on product-level features like the suggestion I made about integrating curated community packages. These kinds of features are what make Meteor so approachable and practical, especially for teams that want to move quickly without sacrificing maintainability.

So yes, Meteor core is the reactivity since from day one but Meteor’s real power go beyond reactivity

5 Likes
22

Yes, I think that will be a major thing for better integration into modern client libraries.

This is an issue that I’m running into a lot lately. I want to switch to Solid works better with Tracker, but the ecosystem doesn’t have the necessary things that I need (though I will probably have to switch to universe:i18n after some improvements and then I should be able to handle the rest).

On another note, another thing to keep in mind that I think we will need to upgrade at some time is minimongo.

2 Likes
23

Interesting point @storyteller. Why do you think we should upgrade Minimongo? Do you have any alternatives?
I believe we need to modify Minimongo to potentially support SQL databases like Postgres in the future or to make it database-agnostic.

1 Like
24

I personally, have never updated/seen our minimongo be updated(in the upgrade sense of the word).

We could make some effort to update it to be close to this minimongo—which I do not recall the history behind. Maybe @storyteller can enlighten us here on why we do not use it as an npm dependency.

Or we could try updating it to be more agnostic – supporting other dbs(SQL and Redis for example)

1 Like
25

Exactly, that is the problem. Minimongo hasn’t been touched in years. If we want to add any new Mongo functionality then it needs to be added to Minimongo as well. Not to mention new functionality offline, etc.
Given our current situation it might be too much to maintain so maybe switching up with the already mentioned minimongo or some other solution. This is for a more detailed solution and investigation, but it is something to keep in mind.

1 Like
26

Yes, exactly. DDP has been a websockets implementation for the past 10 years. It’s got some fallback support for pre-WebSocket browsers; but it’s websockets by default. Use DISABLE_SOCKJS if you don’t want the extra overhead of legacy browser support.

Yes, seems an obvious inclusion.

Having a unified JSON architecture from database to client is a major reason that Meteor is reactive and developers are productive. It’s not just oplog tailing… minimongo is a client-side replica set partition.

JSDoc, sure. Swagger and OpenAPI should also be in core by default.

NodeOnFHIR has spent at least 5 years now, adding in an Express.js server and full support for both HTTP and DDP. It’s a great combination. HTTP allows external systems to write into the MongoDB with a well documented API. Once in the MongoDB, the replica set synchronizes with minimongo as a client-side replica set via websockets/DDP; and react auto renders. It’s beautiful, and solves all our problems with an elegant design.

Read this again: It’s not just oplog tailing and having a Mongo backend… minimongo acts as a client-side replica set partition . There have been experiments with having mini-sql in the browser; and it fails because it’s not native JSON. Instead of a collection of JSON objects on the server synchronizing with a collection of JSON objects on the client; you have a rubiks-cube of tables on the server synchronizing with a rubiks-cube of tables on the client. Uggg^n

You could maybe get some of the same success synchronizing minimongo with Postgres JSON columns; but Postgres doesn’t have half of the sorting/filtering/querying on the JSON column that Mongo has.

Think in terms of JSON from the client to the server to the database. Think in terms of synchronized V8/SpiderMonkey instances. If you’re trying to swap out the backend for something that’s not V8/SpiderMonkey and isn’t JSON native, you’re going to have troubles.

This makes no sense to me. React has been more performant and productive across the board, due to re-usability and composability. Would never look back. Contrary to some misconceptions, React does export to ES6. And importantly, has the largest libraries of UI components; and the LLMs are well trained on it.

That being said, the magic happens with Functional Components (methods), not classic React Components (objects). It’s a classic object-oriented programming vs functional programming mismatch. Yeah, the life cycle on React Components is basically a mismatch for Meteor; but once a project converts to Functional Components, it’s functional programming from the server to the front-end UI, and it’s a thing of beauty.

Mongo+DDP+minimongo is the crown jewel of the entire framework. Client-side replica sets for the win.

5 Likes
27

All the above being said, the most obvious 2025 hotness hasn’t been mentioned yet: Model Context Protocol (MCP) Server needs to go into core.

3 Likes
28

I agree with what you’re saying but I’m not sure how it relates to my statement of Meteor needing to ditch oplog tailing. Minimongo is a gem but is orthogonal to oplog tailing.

Reactivity can / should be preserved with an official, mongo-supported approach, e.g. change streams, and in a way that doesn’t preclude scaling horizontally.

Oplog tailing was originally a hack introduced long ago that mongo never officially support. It lived on because the MDG team got distracted by enterprise and graphql, after which there hasn’t been anyone on the core team dedicated to providing an alternative solution.

Fwiw, I agree. React is a legacy solution that doesn’t succeed based on technical merit but rather inertia. Sure you can make it work with Meteor but it isn’t an optimal pair.

4 Likes
29

Agreed with that history, and with change streams as a better solution!

Also, let’s remember that inertia, adoption, documentation, and community support are features also! It’s not just about technical considerations.

2 Likes
30

As I understand, MCP is more developed on top of aplications that you can manipulate via prompts, how do you see a MCP layer on Meteorjs?

1 Like
31

Well, step through the official SDK a bit…

Good news for Meteor is that it’s already based on Express and Typescript. Check and check. So, at a minimum level… make sure that the Express instance is well integrated, not running in a second thread (or if it is, it’s being done so intentionally), make sure it’s working with other middlewares like oauth or @accounts, etc. That’s one part.

Second part is that there’s some quirky protocol syntax in there. I don’t think this should be too much of a problem, and will mostly be handled by the browser and network stack.

config://app
users://{userId}/profile
github://repos/{owner}/{repo}

There’s also some Streamable HTTP, CORS, and Session management issues that need to be aligned with Meteor flavored Node.js.

That’s basically the easy stuff, and mostly all well defined in the SDK. After that’s in place, it’s a matter of creating a sample app and registering tools; and where the opinionated Meteor architecture comes into play.

My $0.02 is that the fetch-weather example is a good starting point, in that it shows how to fetch out to basic vanilla HTTP call. That’s sort of the MCP-2-HTTP example, that will do a lot of the heavy lifting.

Personally, I’d like to see it integrated with Swagger/OpenAPI. Then, when HTTP endpoints are defined on the Express server, they can immediately be consumed by the MCP server.

The idea here, is that the MCP endpoint(s) is the orchestrator, and all of the Swagger/OpenAPI endpoints are the instruments in the orchestra. I’ve been told that well defined Swagger endpoints make MCP implementation a breeze.

Happily, the Node on FHIR stack has an entire bank of well defined HTTP endpoints. So mapping them to Swagger/OpenAPI, then to MCP will be very straightforward. For others in the Meteor ecosystem, it will be more of a bring-your-own-API.

Aside: It’s kind of funny, the more I read into this MCP architecture, the more I’m reminded of Apollo/GraphQL. Both are orchestrator APIs, with a “one HTTP endpoint to rule them all” concept. Apollo approached the problem with structured graphs; but MCP is approaching the problem with unstructured text (!) and language models.

For those who still haven’t quite groked the MCP model… my $0.02 understanding of what the architecture overview and sdk are describing, is that it’s a single /mcp syntax endpoint that is implemented by all the MCP compliant servers. And you feed into it your prompt query and context (which can include toolchains), and then the server recursively calls itself and other /mcp endpoints on other servers, and just makes recursive calls until completion.

And it kind of works, apparently. ¯_(ツ)_/¯

2 Likes
32

Bringing more inputs for this topic, I’m creatting a deep dive explanation about Meteor’s DDP(the reactivity core) module here