see: https://meteorhacks.com/cluster-performance-test-its-impressive.html
Although it’s not official.
see: https://meteorhacks.com/cluster-performance-test-its-impressive.html
Although it’s not official.
I agree with @manrashid. I was meeting with a developer yesterday who is just getting started with Meteor and said that things like Publications & Subscriptions were a bit confusing. Would be good to see the docs get some examples. Even higher level stuff, too. I was trying to wrap my ahead around this but found myself wishing for a practical example just beneath the API description.
Stuff like this could go a long way!
Yeah I saw that - and thanks for all the work you’re doing on cluster, Arunoda.
I’m thinking more of something where we show a progression beyond 10 servers… what can we do with 100 servers or 1000 servers? If we can show Meteor scaling to 2000connections*1000servers = 2M real-time connections, that’s great ammo to squash the “can meteor scale” concern.
Okay. That’s a big deal.
We’ve planned to do a massive load test in the march with the support from VmWare.
Not exactly sure about that. Let’s see.
I think this thread is full of awesome! Personally, I’d love to see advanced package api, creation tips & best practices regarding package development/maintaining.
Would also be cool to see some tutorials/demos with the best way to maintain a meteor app that targets multiple platforms.
Just two ideas off the top of my head, looking forward to seeing this develop.
I think Let Its Crash to see how far can Meteor scale to the limit of computation cores in AWS, Google Compute Engine or CloudSigma?
I’d like to see something about doing joins with meteor collections and how to keep them synced. I’ve seen that post in discover meteor but all the options they show have their shortcomings. I’d rather like a single obvious way to do it.
Thanks for reaching out to us for input!
Your question really deserves a formal survey to go out to ALL the registered Meteor accounts. Particularly since a considerable portion of the existing meteor documentation is more like a spec rather than a hands-on programming guide. (When there’s not an operational code example, the docs can be quite abstract.)
Here are some suggestions:
In any screencasts that you produce, please:
Thanks again for reaching out to us for input and best of luck with the screencasts!
@interfusion that’s a great list! Thanks.
I’m looking for ways to make the documentation better by harnessing the power of the community. One of the options I’m exploring is making it easier for people to contribute code samples and tips on the docs.meteor.com page through a comment system - do you think that would be helpful?
As long as there’s a bit of quality control on the code samples that get added to the docs, I think that’s a great idea, Sashko.
The Meteor community has some very capable and generous people who would, no doubt, get behind this initiative.
@sashko
I think code samples would make the docs even more helpful to newcomers. I do like the idea of comments, the people that want to improve the docs will most likely submit quality code samples.
Thanks for considering my suggestions @sashko. I definitely think that harnessing the power of the community would be helpful. I have often lamented that there is no way to ask a question about a specific clause in the documentation. Then, if community members could respond with answers or code samples, that would be fantastic! The question is whether you need to build all of that, or simply provide a comment with link to StackOverflow, Github, MeteorPad, etc.
Folks already mentioned security, authorization (access control) and use of allow/deny rules to be addressed in future blog posts and screencasts.
But I’d like to ask more specifically for a post (similar to @sashko’s recent post) which can demystify or reason about:
when and how is it better to use Meteor method calls and allow/deny rules in combination and,
what are the recommended ways to use Roles and Permissions (or other) packages in combination
Deploying a mobile app using Meteor, maybe even adding it to the App Store or Google Play Store
I love this idea! There will be a nice symmetry about having one post about getting data and another about setting it.
hey @chadkruser, I had a similar confusion (coming from Ruby), but eventually was able to find a simple way of doing this. wrapAsync really simplifies the code so maybe this will help you/others out:
var Stripe = StripeAPI(process.env.STRIPE_SECRET_KEY);
var stripeCustomerChargeSync = Meteor.wrapAsync(Stripe.charges.create, Stripe.charges);
var stripeCustomerCreateSync = Meteor.wrapAsync(Stripe.customers.create, Stripe.customers);
var customer = stripeCustomerCreateSync({
card: token,
description: 'payinguser@example.com'
});
var charge = stripeCustomerChargeSync({
amount: 1000,
currency: 'usd',
customer: customer.id
});
// then use customer and charge objects to do whatever you need to do
A more concrete/simple explanation on when to use Tracker and its functions would be really helpful. I was confused as to its role when I was first learning (still don’t completely get it). The one in the official manual was a bit much to handle all at once.
Maybe that’s a good direction: give people a guide about how to accomplish things with Meteor…
I would love to see blog posts or screencasts that complement/extend the existing meteor documentation instead of jumping topics. Documentation has to be concise but screencasts or blog posts can go further by showing use cases and different implementation/examples…
As long as there’s a bit of quality control on the code samples that get added to the docs…
I think code samples would make the docs even more helpful to newcomers…
I think that’s a pretty good description of what the Meteor Cookbook has been trying to do!
For what it’s worth, most of these questions have been asked in one form or another on the email lists, and people have been trying to write some docs and best practices (with code samples) and the like for people to refer to. It’s debatable how well written those documents are, but 900+ people seem to think there’s some progress being made.
So, going through the above comments, lets pull out all the suggestions and look at topics:
Fundamentals
Design
Debugging
Data Layer
Security
Deployment / Environments
Templating
Testing & Hardening
Scaling
Mobile
Tracker
I think it’s fairly obvious that there’s a dozen screencasts and/or blog posts right there.
However, I think it’s important to point out that there are already quite a few blog posts on these topics. Here are some topics that are just from the Cookbook (not counting what’s been written in Discover Meteor, EventedMind, etc.) So, if anybody wants to write a blog post or do a screencast, here is some source material to help you get started.
Design
Schema Design
Data Layer
Debugging
- Console Logging
- Debugging
- Performance Tuning
Fundamentals
- Event Cycle
Security
???
Deployment / Environments
Templating
- Event Cycle
Testing
Scaling
Mobile
Tracker
???
Also, for what it’s worth, I’ve recently started a sabbatical to work exclusively on the Cookbook and Clinical Meteor the next few months. I’m planning on adding end-to-end tests for all the examples in the cookbook, and to start extracting web components that can be shared between apps. I’ll be happy to try to make sure that the next rewrite of the Cookbook addresses some of these questions. This thread has given me quite a few ideas on how to maybe better organize the cookbook, and where some of the missing pieces might be.
If MDG has some specific formatting specs they’d like to see official docs written in, I would be happy to shift the Cookbook in that direction on my next rewrite.