Hey, I work at MDG and I want to write more blog posts/make some screencasts about things.
My most recent post was about new Blaze features: https://medium.com/@stubailo/upcoming-features-in-meteor-blaze-b537cf9c09e9, and I’m currently working on one about security and data management using publications and subscriptions. I’m also probably going to create something about recommended/advanced uses of Tracker.
Are there any topics in particular that people want to know about? And I don’t think it’s just for me - there are probably a lot of people out there that would like to share their experience but just need a good idea for a talk/screencast/post.
Security is actually a topic I thought a lot for our acuttual product and I’m keen to hear more about it so definitely a +1 for that. also performance would be an interesting topic though @arunoda already covers some of that in BulletProof Meteor.
in general i would love more posts/screencast
about how meteors “magic” works
what i mean by that is things like how
livedata works or how we get from html to htmlJS to the client and how we rendered that to the screen
just to examples
@sashko I absolutely liked your post on Blaze and I’m really looking forward to getting the new features.
In various talks and interviews you guys mention that you envision Meteor more as a platform than as a framework. And I think in many ways this is really cool, because this way Meteor can be (and already is) very flexible in how one can use.
But I feel that at the moment there is very little convention about how to accomplish certain things (security, models, validation, callbacks, components, etc.). Surely, we can build packages for almost everything, but everybody seems to be doing their own thing and there are no ‘best practices’. That’s what was so great about Rails when it came out. It showed people how to build stuff and still be flexible.
Maybe that’s a good direction: give people a guide about how to accomplish things with Meteor.
Back when oplog was coming out, you guys did a demo that showed Meteor scaling linearly as servers were added. Would be really helpful if you did something like that again, that basically says “the more traffic the app gets, you just add more servers, and we can do this all night.”
Something like this would go a long way to convincing the doubters that Meteor scales (it convinced me when I saw it, but not too many people saw that demo.)
I am definitely on board with this idea - having some established best practices will really help people who don’t want to reinvent the wheel for each app. Is there a particular thing that will be most interesting? I’m going to do security for sure.
Yeah, I think security and especially authorization (who can do what in which situations) is a topic everybody is facing when building collaborative apps.
After the initial prototyping of an app (which is an absolute joy with Meteor), comes the hard work and thinking, kind of the ‘locking-it-down’ problem. You need to restrict what gets written into the database (maybe with schemas) and have to write allow/deny rules, which can get fairly complex in some situations.
Best practices / conventions in this field are very welcome!
I see continued confusion on sync vs async server-side method calls and how wrapAsync fits in. In fact, two of the first 5 questions on this new forum site were directly related
Part of it, I think, are lingering old references to the pre-wrapAsync days when Futures were the go-to solution. Another part (this is just a hunch from personal experience) are the many folks coming from Ruby getting their first taste of callback hell, folks coming from a MEAN stack (e.g. Promises), and many front-end developers using Meteor as their first foray into full-stack development (my personal scenario).
Consider (for example) the following Node and Ruby samples. The blog post I’d love to see is converting them to elegant Meteor code. My current implementation has about 2x the lines of code.
Node (Express)
var stripe = require("stripe")("sk_test_abcdefghi123456789");
var stripeToken = request.body.stripeToken;
stripe.customers.create({
source: stripeToken,
description: 'payinguser@example.com'
}).then(function(customer) {
return stripe.charges.create({
amount: 1000, // amount in cents, again
currency: "usd",
customer: customer.id
});
}).then(function(charge) {
saveStripeCustomerId(user, charge.customer);
});
Ruby (Sinatra)
post '/charge/:plan' do
customer = Stripe::Customer.create(
:email => params[:stripeEmail],
:card => params[:stripeToken],
:description => plan::DESCRIPTION
)
charge = Stripe::Charge.create(
:amount => plan::AMOUNT,
:description => plan::DESCRIPTION,
:currency => 'usd',
:customer => customer.id
)
erb :thanks
end
error Stripe::CardError do
env['sinatra.error'].message
end
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.
Hey guys! I’d like to thank all of you for taking time to make posts and screencasts and let me ask you whenever possible please structure your posts (or screencasts, or even comments) in a way that will highlight:
What is the problem (or issue) as of Some Date?
What do we need to be aware of (to understand why this is a problem)?
What are the known solutions (or alternative approaches) and pros & cons of those in your opinion?
What are the pros, cons & caveats of your way of doing things?
i.e. the “Whys” for every “How”.
Summary, key takeaways & updates (e.g., kinda like Answer wiki on Quora).
Personally, I’d like to see more posts/screencasts actually demonstrating (and discussing) the pros & cons of using various front-end related technologies (with Meteor) from such perspectives as:
cross-platform performance (various devices);
suitability for certain types of apps (business apps, games, social apps etc.);
ease of use (for dev.) and customization, extensibility, maintenance etc.;
perhaps some other considerations (mostly related to how Meteor works)?
Also I’d like to see more posts/screencasts on topics related to separating applications (or some parts) for different kinds of users.
So for ex., how to avoid downloading certain parts (code) of your app if the user is a regular user, or an editor/admin and how to build separate meteor apps (for different roles/purposes) working with the same database?
And yet reusing the code for DRY.
You’re right. Instead of spreading all this information over countless blog posts, it would be much nicer to have some official guides in addition to the (more api-reference-like) docs. I’m sorry to mention Rails all the time but they do a lot of things very right: Have a look at these awesome guides: http://guides.rubyonrails.org/
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.
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.
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’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.
but they do a lot of things very right: Have a look at these awesome guides: