Core vs expanded vs community phylosophy

core
1

So recently I had a discussion with few other Meteor devs and we struggled to formulate what should be in core, what should be an optional package and what should be left up to community.
In the end we came to this example that made sense to us when it comes to Meteor methods:
Core: The current simple straight forward version.
Expanded: Functionality with all the common things like validation, hooks, easy client/server. Pretty much a merger of https://atmospherejs.com/cultofcoders/mutations and https://atmospherejs.com/mdg/validated-method
Community: Everything else that builds on the expanded version to facilitate specific uses or connects with other things.

There was also an interest to introduce more hooks in general into Meteor to make easier to use without the needs to hack the core. Still besides that we are struggling with a coherent philosophy around that. As such I want to open this to everyone to see if we can come up with something coherent either based on my example above or something completely different.

3 Likes
2

I think every time I’m reading the docs, and the official documentation tells me to install a package, that functionality should be in core.

11 Likes
3

I think stuff like Collection Hooks should be in core. I’ve always installed it and find is so useful.

4

I agree with @cereal, it’s weird when you go through the official docs, and it recommends to install some weirdly named package to achieve very basic functionality.

I don’t mind if it gives a list of packages that let you take things further than what the docs explain, but it shouldn’t include examples or tutorials on how to use third-party packages. That should go into a « recipes » or « examples » section. You can’t have packages explained in the official docs that are outdated and unmaintained either (Again, a list of packages is fine, but not an official tutorial). Examples of external packages meteor relies on to work:

  • tmeasday:check-npm-versions
  • meteortesting:mocha

My opinion is that the meteor core should offer all the necessary abstractions to allow anyone to easily hook into meteor and write whatever code they need, without needing to use hacks.

My recent experience building a Gatsby website felt like that (thanks @stolinski for the tutorials btw :wink: ): As you learn more about the functionality of Gatsby, you realize that all the plugins you install, and much of the built-in configuration, simply uses the public APIs that Gatsby makes available. I.e. Gatsby uses their own low-level APIs to build Gatsby itself. You quickly get the feeling that you too can just use those APIs and rebuild those plugins yourself.

As a counter example in Meteor, when you look at the code in matb33:collection-hooks, or the packages that need meteorhacks:meteorx, it’s just hacks. It’s not discoverable, it’s not easy to use. In Meteor you’re always left doing the function replacing dance:

const originalMeteorFunc = Meteor.someImportantFunctionWithNoApiOrDocumentation;

Meteor.someImportantFunctionWithNoApiOrDocumentation = (...args) => {
  doMyOwnStuff(...args);

  return originalMeteorFunc(...args);
}

It’s fine, it’s not too difficult, but you’re completely on your own. I don’t understand why you need a “hacks” package to build a proper monitoring solution like Kadira for example, that stuff should be built using 100% public APIs.

So I would summarize it like this:

  • Anything that gives you deep access to the meteor code-base, be it through good abstractions or through unofficial hacks, should be in the core.

Candidates I can think of, you’ll notice that all these things do the same thing: give more control to the developer:

2 Likes
5

I would also add my 2 cents from a maintenance and trust perspective:

core - highest stability, maintenance can be expected, highly to be trusted to not break in the future
expanded - high stability, maintenance can be expected, could break in the future due to changes in the api
meteor community packages - high stability, maintenance can be expected but can be slow, could break much faster, due to faster changes being implemented
community - stability depends on the owners, maintenance can stop anytime, can break anytime

1 Like
6

This is an interesting perspective, goes back to the LTS debate.

The proposed Meteor method API is also partially based on seba:method-hooks. I mostly agree with what you suggest integrating into Meteor.
For me personally I’m trying to find time to integrate some new stuff from MongoDB like insertMany.
Still going back to the topic, the PR you reference is actually a new package that doesn’t change the core method. The question is if that is how it should be.