Hello!
I worked really hard in the past months to bring Meteor to the next level. In an opinionated yet flexible fashion. (MDG style). MDG has given us a flexible/hackable platform with lots of goodies. But we can’t simply expect them to do everything we want/need or even wait for those! It’s up to us, they laid the foundation, we’ll build on top of it.
Fetching data
One problem that we tackled was data fetching. With MongoDB this is ridiculously hard, as we don’t have the joining ability provided by SQL, what we got is $lookup that doesn’t even work with sharded collections. That problem has been solved elegantly by:
Follow-up topic: Grapher - Collection Relationship Manager + GraphQL Like Data Fetcher
It’s Battle-tested + LTS, however because the docs are a bit hard to digest, it did not have the adoption I expected. I need to make a video tut for this.
The oplog
Next problem was MongoDB oplog, which is very ingenious but it kills the CPU, it may work for 50-200 online people, but if you trully want your app to be ready for scale, and you want reactivity, then it is simply impossible, because of how oplog tailing works. This problem has been solved by moving to Redis:
Follow-up topic: Meteor Scaling - Redis Oplog [Status: Prod ready]
It works very nice, however it’s not released yet, because it is not properly unit & integration tested, these things take time. It solves a lot of problems. And I plan on making an official release soon. For now you can still play with it and help me find bugs!
Free Tutorials
Then I realized people have a hard time understanding Meteor’s fundamentals just by looking at the docs provided by MDG. And other good books, like discover meteor, cost money, a lot of people from poor countries don’t have 30$. This is problem we aim solving here:
http://www.meteor-tuts.com/
Follow-up topic: Meteor Tutorials (The Plan) - We need you
We got the first round of feedback, not so good unfortunately, but we know what to do to make it great!
So what is next ?
Next step: Methods & Publications makeover
Context:
As your app code-base grows larger and larger, your methods and publications will also increase in number. Security problems may arise. Code-duplication may arise. Onboarding someone new will be a hard task to do.
Some of the problems of Methods have been addressed in the “ValidatedMethod” package, which is nice, but still, not nice enough!!
Concept:
Meteor.methods({
'post.update': {
// this makes method validation super-easy
schema: {
postId: {type: String},
data: {type: PostSchema}
},
// separating concerns even more, this checks if you are allowed to do it
firewall(userId, {postId, data}) {
// if userId not owner bla bla, throw new Meteor.Error()
},
// runs the actual function, keeping concerns separated.
run({postId, data}) {
// just execute what you need to execute.
},
// now this is the bomb, we allow a description for our methods
// so we could build a documentation for ALL METHODS and display them in an interface
// for developers
describe: ''
}
});
Same principles to publications:
Meteor.publish({
'post.list': {
schema: {},
firewall() {},
run() {},
describe: ''
}
})
Then we could have a “Self-documentation interface” (Like we have in Grapher-Live for Collections and Schemas), where we can see all methods/publications, description, (whether they have a firewall or not), the fields they accept, give a code snippet to call each so you can copy/paste it where you need it. You can search through all your methods, and get instant insight of what it does.
Again, I am very community focused, bc my intention is making something useful not for myself/my company but for every single Meteor developer out there. And lots of people have given very good feedback.
Use your imagination a bit, you write code, and then you have a friendly interface to see All collections, their schemas, the queries you can do, the methods you can call, the publications you can subscribe to. You can even expose an “API” to access these and give it to external devs. It’s so beautiful it hurts. For react evangelists, we may integrate this with GitHub - storybookjs/storybook: Storybook is a frontend workshop for building UI components and pages in isolation. Made for UI development, testing, and documentation. why not have your pure components visible as well ?!
If you have ideas for redis oplog/grapher/tuts, put them in their respective topics. Keeping concerns separated makes great code, and great communication too.
Again, I need your help with this Methods, Publications, give me some feedback. Critiques backed by arguments are the best kind! Cheers.
. Keep up the good work !