Article outline

https://github.com/meteor/guide/blob/master/outlines/data-loading.md

Major decision points

1. Data loading is best done through publications
2. All subscriptions should happen inside UI components. Even "global" subscriptions should be done in the app layout component. Data loaded from a subscription should be accessed in the same component, and passed down through arguments, rather than relying on global data to be available in Minimongo
3. There's a strategy for pagination here, we should investigate what works well in production apps
4. Client-only data should be in a Tracker-enabled store, for example a ReactiveDict wrapped in an API
5. Relational data should be published using publish-composite
6. External data should be pushed to the client through publications - for example, you can poll a REST endpoint through a pub

Old outline:

Proposed outline

1. Loading and publishing data from Mongo on the server.
2. Subscribing to data on the client
   • For now, just in the straightforward way, emphasize autorun re-sub behaviour and workarounds
3. Client only data (Stores) vs persistent server data (Collections)
4. Modifying data ("actions"? -- store mutators or methods)
5. Complex publications:
   • Relational data - use publish-composite to publish relational data.
   • limiting data to what you need
   • reusing publications vs limiting them.
   • pagination patterns
6. Publishing data from 3rd party sources
   • Poll-publish pattern
7. Publications as RESTful endpoints

Open Questions

• Should webhooks be part of the methods article? I think so
• Do we encourage people to pass queries / options into subscriptions? I think no.

Designing a standard error format, so that when you throw an error from a method, it's clear what kind of error it is, how it should be displayed to the user, whether it's related to a specific field, etc. This way different packages can show the same kinds of errors. I'd love to see some prior art on this - most validation libraries either throw terrible errors (like check) or have a super custom form integration (like simple-schema).

I think apart from the design here we need to make sure technically that the ddp stack supports throwing errors with objects attached (one way or another, see meteor/meteor#4202).

Referencing this: https://github.com/meteor/guide/blob/master/content/routing.md

It says that for a route like /, action is not called. But that's not true, otherwise this wouldn't work:

FlowRouter.route('/', {
  name: 'home',
  action() {
    ReactLayout.render(Layout, {content: <Home />});
  }
});

Originally opened by mitar with the title "Server side reactivity" with the description below. This ties into managing/publishing relational data.

I think a topic on server side reactivity would be great:

• https://github.com/peerlibrary/meteor-reactive-publish

And how to keep denormalized documents in sync:

• https://stackoverflow.com/questions/25344444/best-model-for-representing-many-to-many-relationships-with-attributes-in-mongod/32921323#32921323
• https://github.com/peerlibrary/meteor-peerdb

In general my observation is that people are trying to use too many relations in Meteor/MongoDB because they are not used to the idea that you should denormalize data and you can have embedded subdocuments in documents.

In MongoDB, the important idea is that you get in one document all the data you need to display that one view (or Meteor template) (which aligns really well with data context, which is also maybe why I am having less issues with data context being a way to pass data then those who anyway have to make multiple queries to get all the data to display in the template, like making additional local collections queries in template helpers). The issue is that people like to keep stuff separate in collections and then try to do joins. Which is really bad. And really hard to do well in a reactive way.

So the approach I think is better (and for which we made packages) is that you for relations which are inherit in the data you declare them declaratively and then Meteor embeds stuff and keeps them in sync. It is really great because you can then query on the subdocuments as well very efficiently.

And for joins which are not inherit on data (so not relations between data, but for example permission checks) you can use server-side reactivity because they are most often 1-to-many joins which work pretty well as a server-side reactivity (does the current user has access to this document I am about to publish).

(Obviously, disclaimer, I am involved with both projects.)

Outline

1. Thinking about deploying a web application
   • Staging vs Production
   • Secrets etc
   • Acceptance tests
2. Deployment options
   • Deploying to meteor.com (free)
   • Deploying to modulus
   • Deploying w/ mup
   • Deploying to Galaxy
3. Monitoring your users
   • Integrating with popular analytics platforms to track method calls, publications, and URL hits
4. Monitoring your production app
   • w/ Galaxy
   • w/ Kadira
5. Deploying new versions
   • how HCP works with rolling updates
6. Load testing your application (?)

Build a wrapper around methods, of the form:

Todos.methods.insert = new Method({
  name: '/todos/insert',
  validator(doc) => { Todo.Schema.check(doc); },
  permission(doc, userId) => {
    if (!doc.ownerId == userId) {
      throw new ForbiddenException("...");
    }
  },
  body(doc) {
    Todos.insert(doc);
  }
});

Article outline

https://github.com/meteor/guide/blob/master/outlines/ui-ux-outline.md

Major decision points

1. Components should be either 'pure' reusable components, or 'smart' app-specific data-loading components, regardless of which view framework you are using.
2. tap:i18n is the best internationalization library for Meteor today

Old outline

Sections

1. Reusable components
   • "pure vs impure" components
   • Using global singletons carefully (router / mongo / "stores")
   • Testing them / component harness (more to come later, just something for now)
2. UX patterns
   • Throttling event handling
   • Building a responsive / cross device application
   • Internationalizing an application
     • use https://atmospherejs.com/tap/i18n
   • Accessibility - @stubailo can you let me know what you had in mind here?
3. Realtime UX patterns
   • Using animation to reveal changes in a understandable way
   • Allowing the user to choose when changes happen to the UI.
   • Dealing with Latency Compensation - optimistically or otherwise

Article outline

https://github.com/meteor/guide/blob/master/outlines/testing-outline.md

Major decision points

Lots of new stuff needs to exist to make testing palatable in Meteor, but the outline lists the packages and approaches we want to promote now.

1. Packages/modules are the best units in which to test code
2. practicalmeteor:mocha is the best package test runner

Old content below:

@samhatoum, I'd love to hear your ideas about what would go in an official Meteor testing guide. We've talked about this issue at length already, so you know a lot of my opinions on the issue. What do you think?

My proposed outline is below.

Meteor guide: Testing

Write some extra code now to make sure you don't break your code when you add more code later. Add features and refactor your app with no fear.

1. How to test:
   1. Methods
   2. Publications
   3. Models
   4. Routes
   5. UI components
2. How to structure your code with modules/packages so that it can be tested more easily
3. How to stub parts of the Meteor framework so that you can test a small part of your app at a time
   • Stub collections/publications?
4. How to mock data in a realistic way
   • Factories?
5. How to set up continuous integration and pre-push hooks so that you can't forget to run the tests
   • Use spacejam here

It should have examples of publications, methods, routes, components, and a good app structure. People have been asking for this for forever, now that we will have a recommended structure it's a good opportunity to build it in. It's not quite scaffolding, but it's on the way there.

Relevant issues on meteor/meteor:

• meteor/meteor#3795
• meteor/meteor#5283

@tmeasday what do you think? I don't think this was in the original outline at all. What article would it go in? Probably not really routing, more like APIs or something.

Article outline

https://github.com/meteor/guide/blob/master/outlines/routing.md

Major decision points

1. Flow Router because it works well across Blaze and React, and is relatively simple
2. The URL/Router is not the main driver of the app - it's just another data source
3. Only "smart" components should read the route data (see more in the Blaze or UI articles)
4. Server side routing/HTTP API is not covered here

This way users have a chance to start playing with examples/demos within seconds instead of having to set up an example manually or cloning a repo to get started.

Implementing internationalization in your app doesn't take that much work thanks to the aweseome tap:i18n, so I think it'd be worth mentioning it.

I assume we will all send in PR's to this repo. It would be nice to figure out how/when/why a PR should be accepted into the guide. This seems like the first major hurdle to developing trust with potential writers.

Article outline

https://github.com/meteor/guide/blob/master/outlines/accounts.md

Major decision points

1. useraccounts:core and friends are the best account UI available
2. Custom data about users should be added in new top-level fields on the user document, you should not use profile. This is partially for DDP performance, partially to make security easier.

My recollection from investigations a few years ago:

1. Jekyll is pretty unmaintained (or at least the version that GH pages supports is old). So trying to do custom stuff like plugins is a pain.
2. Although GH pages gives a really easy way to host static sites, it's also pretty straightforward to use a CI tool like codeship to hook git commits to some other hosting service like heroku.
3. Middleman is another ruby-based static site generator that's much more mature.

@SachaG - perhaps you have some thoughts here.

Article outline

https://github.com/meteor/guide/blob/master/outlines/blaze.md

Major decision points

1. Blaze templates should be used as encapsulated components, using the following strategies:
   1. Validation of data context and always passing it explicitly on template inclusion
   2. Explicitly naming variables, contexts, and helpers
   3. Storing internal state on the template instance
2. Developers should make a clear distinction between "smart" components that load data and access state, and "pure" components that just render UI

Previous proposed outline:

1. Introduction to spacebars, Blaze's templating syntax
   • Basic builtis
   • Template lifecycle
2. Making a Blaze template a reusable component:
   • Being explicit about data contexts
   • Never use this.title, instead post.title (does the new iterator syntax help with this?)
   • Storing state on the template instance, patterns for access in helpers/spacebars
   • Being careful about using this.$ and event maps
   • Passing callbacks as arguments
   • How to use a component as a layout and Template.contentBlock
   • Integrating w/ 3rd party libraries (i.e. jquery)
3. Accessing data from a template
   • Template level subscriptions
   • Accessing collections
   • Accessing stores from templates
   • Understanding reactivity
   • Pure vs impure components
4. Reusing code between templates
   • Global helpers (and what they should be used for)
   • Utility code
5. Testing Blaze components (or is this in the testing chapter?)

Versioning has been mentioned en passant, but it needs some clear focus.

One of the great things about the current Meteor docs is you always get the latest version.

One of the bad things about the current Meteor docs is you always get the latest version. Well, to be more accurate you can't (easily) get to an older version.

So, as a minimum, I'd like to see an easy "release switcher" for the docs. For bonus points, in-doc flagging of differences between this and the previous release.

Article outline

https://github.com/meteor/guide/blob/master/outlines/forms.md

Major decision points

1. autoform is the best Meteor form solution available today, we're going to make sure it integrates seamlessly with the method solution above
2. CollectionFS is the best file upload solution

Old info:

Related PR: #27

Today I got the chance to spend some time talking to @tmeasday, who's visiting from Australia! He's bringing his years of experience writing production apps as part of Percolate Studio and MDG, and his learnings from co-writing Discover Meteor, to the Meteor Guide project. Awesome!

Let's get into what we talked about regarding forms, methods, and user input in general.

Features of a good form solution

1. Form UI - can be expressed in HTML or auto-generated
2. Validation - optionally done in realtime while user types, then is done on submit, then is done inside the method on the server-side
3. Runtime errors from the server - not everything is a validation error, and certainly not all can be caught on the client
4. Methods - you want to control exactly what code is running when you submit a form. Automatic handling via default insert/update can get you to a certain point, but it's hard to go from there

The biggest requirement we identified here is a need for a standardized pattern for different kinds of input errors you might want to display to the user. Then we also came up with some ideas about the code that could be involved:

1. The form, button, or other UI
2. The validation logic for user inputs/schema, which happens to coincide with the arguments of the method so it can be reused to check the method arguments as well
3. Authorization for the method
4. The method body itself

This suggests some idea of a "validated method" - a method that isn't just a single function, but perhaps several that can be run separately. Similar to @SachaG's two-tiered methods, except all of the tiers are conceptually part of the method, and there might be more than two of them.

Here's a diagram that represents the picture I have in my mind. Obviously it's not finished, but it outlines the shape of things that I see:

Action items

1. Designing a standard error format, so that when you throw an error from a method, it's clear what kind of error it is, how it should be displayed to the user, whether it's related to a specific field, etc. This way different packages can show the same kinds of errors. I'd love to see some prior art on this - most validation libraries either throw terrible errors (like check) or have a super custom form integration (like simple-schema).
2. @aldeed's AutoForm is awesome, and has a ton of different plugins and integrations on Atmosphere. We'd like to use that, and work to improve its integration with the validated method pattern. Basically this means making it simpler to work with hooks and supporting the error format from (1) so that it can be used with errors outside of simple-schema.
3. Simple schema is possibly the best JavaScript schema definition and validation library out there. We'd like to deprecate the check package by bringing the best parts of that into simple-schema; in particular that means having a way to just do a one-shot check of an object against a schema without needing to first initialize a validation context. This way it will be much more natural to reuse the schema in the form and the server-side validation.

Notes

• Methods should be idempotent where possible due to reconnect re-runs

I think it's pretty clear when you take a look at the application development landscape these days that people are pretty excited about reusable components. Blaze is a great templating system, but it doesn't quite give you everything you need to be able to reason about small parts of your app independently.

Mainly the issue is that it can be hard to look at a Blaze template and know how it will behave when used in different parts of your app. This involves a few issues:

1. The tendency to use global data via Session - partly because using Template.instance() all the time is a lot of boilerplate
2. The tendency to use global jQuery selectors, or HTML IDs, like $('.error')
3. The data context being passed from outside of the template means the functionality depends on the outside environment in a poorly-defined way
4. The way event maps work means they also catch events from child templates, which is something you might or might not want

@mitar, can you help me understand to what extent your Blaze Components package solves these issues? Unfortunately, you're right - I haven't had enough time to look at it in depth, but I would like to learn more now.

Copied below, the outline of the Blaze guide as proposed:

Blaze guide: The Tracker-based reactive templating system

Write “HTML with holes” just like you're used to, and get a fast, fine-grained, reactively updating page with no sweat.

1. Spacebars syntax, and how to use the built-in helpers
2. Building reusable components with Blaze
3. How to use reactivity in a principled way
4. Writing maintainable helpers and event handlers that aren't tightly coupled to HTML
5. Reusing logic and HTML snippets between templates

Article outline

https://github.com/meteor/guide/blob/master/outlines/build-tool.md

Major decision points

1. Use ES2015+ everywhere via the ecmascript package, if you really want to you can use coffeescript instead but all of our code samples will be against ES2015.
2. Use autoprefixer by using one of the community minifier packages that have it built-in, rather than by building it into the CSS compiler. In the future, we will need a separate build step for CSS post-processing.
3. Ideally the Meteor 1.3 build tool will support NPM on the client and server natively, but until then meteorhacks:npm and cosmos:browserify are the best options

Article outline

https://github.com/meteor/guide/blob/master/outlines/mobile.md

Major decision points

1. Hammer.js for touch gestures
2. Users should be relatively in control about when the app updates under them, and we should work on improving that experience
3. Offline data is currently not a smooth experience out of the box - we will mention one or two approaches but we can't stand behind their reliability

See #51.

@stubailo do you have written down all the details of what these were? If not I can tease them out as I start to work through the forms chapter / todos implementation.

1. Make it simpler to throw a Meteor.ValidationError from simple schema w/ one line of code.

Needed for #9.

Currently, to make insert, update, and remove work on the client, every collection defines methods called /collection-name/insert, /collection-name/update, /collection-name/remove. There's no way to remove them.

It would be reasonable for people to want to define methods called this, especially with the code style we are prescribing. Also, since we are recommending for people to avoid allow/deny, these methods are useless and would clutter any list of app methods.

The best option would be for these methods to simply not exist unless allow/deny is used. That leaves an open question about Meteor.users, which has allow/deny rules defined by default, but if we removed the profile field that would no longer be the case. I would be happy if a future release of Meteor made profile opt-in.

We suspect it's simple schema. If so, we should work with @aldeed to get it (the non-meteoric parts anyway) on NPM, and promote it as a cool thing that's come from the Meteor community.

One thing that @timbotnik and I noticed about it: it seems slower than it needs to be. Perhaps there are some simple optimizations that can be made?

TODO items

1. Browse around for alternate validation libs
   • http://mongoosejs.com/docs/guide.html
     • OK, but not super expressive once you get beyond the basics
   • https://github.com/molnarg/js-schema
     • seems sort of experimental, no explicit support for subobjects
   • Some others that don't particularly seem worth mentioning
2. Investigate speedups
3. Consider replacing check / audit-argument-checks with it.

Article outline

https://github.com/meteor/guide/blob/master/outlines/collections.md

Major decision points

1. simple-schema for schemas
2. collection2 for schema validation (just as an error checking mechanism, input validation is covered in the forms/methods article)
3. Sometimes for performance you want to denormalize certain fields, but mostly data should be relatively normalized to work well with Meteor
4. percolate:migrations for migrations
5. Use dburles:collection-helpers to add "helpers" to your collection documents. Use this to handle relations

Old info:

Here are some decisions we need to make, and my ideas:

Defining schemas and validations

Basically simple-schema, right? I feel like this is a de-facto standard right now so it's what we should use. Are there any downsides to simple-schema? Are there any competitors? @aldeed what are your thoughts here?

Designing a schema that works for Meteor

We know there are certain limitations with DDP right now; for example the lack of nested diffing. This means it can actually be an advantage to have a more flat and normalized schema.

Adding setters and getters to your models

It makes sense to me to use the Meteor transform option to turn objects retrieved from Mongo/Minimongo into model objects with getters/setters/etc that basically just call Meteor methods. Is this a good approach, or is it better to call methods directly? Do we lose something by not having the data that comes out of Mongo be a plain object? (for example, you can't reliably clone "smart" objects, they might have surprising reactivity, etc?)

Meteor guide: Collections and models

We'll explain how to deal with collections across client and server. Then we'll reduce code repetition by extending database documents with model classes.

1. How to define and use MongoDB collections in Meteor
2. The distinctions between collections on the client and collections on the server
3. How to define a model with schemas and validations for a collection
4. How to add setters and getters to your model to centralize your database logic
5. How to design a schema that works well with Meteor's data system and can be extended over time
6. How to migrate data when you want to change the structure or schema of your collections
7. How to model relational data, even when your database is not relational

Designing a standard error format, so that when you throw an error from a method, it's clear what kind of error it is, how it should be displayed to the user, whether it's related to a specific field, etc. This way different packages can show the same kinds of errors. I'd love to see some prior art on this - most validation libraries either throw terrible errors (like check) or have a super custom form integration (like simple-schema).

I think apart from the design here we need to make sure technically that the ddp stack supports throwing errors with objects attached (one way or another, see meteor/meteor#4202).

The only drawback of GitHub pages is the lack of support for versioning, but we don't need that to get started writing content.

• Set up gh-pages branch and make that the default branch
• Initialize basic Jekyll site with a basic sidebar/table of contents layout
• Import the guide outlines to create a skeleton site
• Set up "Edit this page" buttons

Article outline

https://github.com/meteor/guide/blob/master/outlines/packages.md

Major decision points

1. We are recommending exporting exactly one symbol from each Meteor package, named the same as the package itself. We believe this will result in the smoothest transition to ES2015 modules.

Perhaps this goes in UX, perhaps in testing.

@debergalis is excited about it, @tmeasday and @dominicnguyen have experience using such a system.

We need to do this to get a feeling for what an app looks like when it follows all of these recommendations. Some apps we have built in the past are pretty close, but we need to make sure everything we say meshes well together and ends up with an app that feels good.

Todos

• Move files to packages + rename according to our scheme.
  • Basic package-per route + collection
  • Place global CSS and resources in the right spots
  • Ensure names fit our scheme
• Switch to flow router
• Modularize properly (stores etc)
• Unit tests
• Integration tests
• Acceptance tests

I think this is a code ticket? I'm not quite sure what would be involved here. Do we need to work with the publisher of the CI integration?

While this is still in discussion, we can have a look, how similar is done in Laravel framework, which is deeply loved by a lot of php devs.

The documentation:

• is divided into sections and pages. Makes it easy to find what you need, goes from basic to advanced things.
• has framework versions (divided by gh branches). Even the navigation sidebar changes from version to version and has different sections.
• is held in a separate repository. Easy to contribute, maintain and see the differences from version to version. (3000+ commits, 400+ contributors)
• has search input box. Easy to find what you need when you are already in the docs.
• has great seo. Google laravel xxx - 99% you get to the docs.

The website is also held in an open repository so that everyone can see, how it is build. It is also updated to the latest version of the framework.

Here's a thought: what about using Microscope as an example app, instead of to-dos? It's a little more complex, so it features a lot of concepts that are not present in To-Dos (for example, pagination). And it's also an app that many people are already familiar with.

As far as official (MDG) documentation is concerned we currently have the docs, the wiki, a number of READMEs in packages, some of which are better than others and the Meteor Manual - does Maria still work at Meteor?

There is already an issue with overlaps (saying the same thing), contradictions (saying something different) and holes (not saying something).

A proportion of this project's time needs to be devoted to addressing the confusion surrounding all these disparate ways of presenting The Meteor Way.

@stubailo : I think you've already said the useful knowledge in the wiki will be absorbed into the guide?

I see the docs as the reference book - all methods, etc. are documented much as they are now, with links to the appropriate guide sections (and vice versa) - is that right?

I think the Meteor Manual should go the way of the dinosaur (think of it as a K/T meteoric extinction event 😉) - maybe it could be a permanent redirect to the guide.

The package READMEs should all be high quality and become the appropriate package reference section in the guide (imported as part of the guide's build process).

What do you think?

We need to think about things like the 'voice' of the content, who the articles are written for, and what authors can and can't promote within their posts.

Article outline

(to be updated potentially for the Meteor 1.3 module world)

https://github.com/meteor/guide/blob/master/outlines/structure.md

Major decision points

1. Code should be structured around features, not stack layers (backend/frontend). You should co-locate all code that works together
2. You app should be all ES2015 modules
3. For the case where you want separate UIs for admin, mobile, etc, the pattern is to have multiple separate "meteor apps" or entry points and share code via packages/modules

I wrote these articles for MDG some time ago.

https://meteor.hackpad.com/Meteor-Cookbook-Using-Dates-and-Times-qSQCGFc06gH
https://meteor.hackpad.com/Meteor-Cookbook-Reactive-D3-Visualizations-YUR9JT4mrm9
https://meteor.hackpad.com/Meteor-Cookbook-Filepicker.io-Uploads-and-Image-Conversion-hIpSwJQV3HJ

A couple more are less polished / still drafts here https://github.com/nate-strauser/meteor-cookbook

Do you think this type of content belongs in the guide? I'd be happy to help update these and get them ported over.

How about a short section on getting the most out of atmosphere?

Maybe this is a bit too basic for the intended audience, but given the number of forum questions which end up answered as "try adding package xxx:yyy", some guidance would appear to be useful.

• Search strategies
• Refining the list:
  • Things to look for that are good
  • Warning signs

• Package
• Avoiding spam
• MX records
• Tracking emails
• Popular services - get services to write us guides or link to their own

Atmosphere is great, but it's also a little hard to navigate sometimes. So I've been keeping track of useful packages on the side as well.

Note that the end goal for this list is to eventually publish it as a free eBook to give away on the Discover Meteor blog. But until that happens, I suppose there's no harm in discussing it here :)

Models & Collections

• https://github.com/aldeed/meteor-simple-schema
• https://github.com/aldeed/meteor-collection2
• https://github.com/dburles/mongo-collection-instances
• https://github.com/dburles/meteor-collection-helpers
• https://github.com/matb33/meteor-collection-hooks
• https://github.com/jagi/meteor-astronomy
• https://github.com/richsilv/meteor-dumb-collections

Forms

• https://github.com/aldeed/meteor-autoform
• https://github.com/meteortemplates/forms

Files

• https://github.com/CollectionFS/Meteor-CollectionFS

Routing

• https://github.com/iron-meteor/iron-router
• https://github.com/meteorhacks/flow-router

Tables

• https://atmospherejs.com/aldeed/tabular
• https://atmospherejs.com/aslagle/reactive-table

Templates & Components

• https://github.com/peerlibrary/meteor-blaze-components
• http://viewmodel.meteor.com
• https://github.com/aldeed/meteor-template-extension
• https://github.com/meteor-space/ui
• https://github.com/themeteorites/blaze-magic-events/

Publications & Subscriptions

• https://github.com/meteorhacks/subs-manager
• https://atmospherejs.com/tmeasday/publish-counts
• https://github.com/meteorhacks/fast-render
• https://atmospherejs.com/peerlibrary/reactive-publish

Performance

• https://github.com/meteorhacks/meteor-down
• https://github.com/meteorhacks/cluster

Security

• https://github.com/meteorhacks/sikka
• https://github.com/matteodem/meteor-easy-security
• https://github.com/ongoworks/meteor-security
• https://github.com/alanning/meteor-roles

Accounts

• https://github.com/meteor-useraccounts/core

Other

• https://github.com/dandv/rate-limit
• https://github.com/percolatestudio/meteor-migrations
• https://github.com/percolatestudio/meteor-synced-cron
• https://github.com/bengott/meteor-avatar
• https://github.com/mizzao/meteor-user-status
• https://github.com/Meteor-Reaction/Herald
• https://github.com/cmather/meteor-handlebars-server
• https://github.com/alethes/meteor-pages
• https://github.com/matteodem/meteor-easy-search
• https://github.com/mizzao/meteor-autocomplete
• https://atmospherejs.com/anti/fake
• https://atmospherejs.com/manuelschoebel/ms-seo
• https://github.com/TAPevents/tap-i18n
• https://github.com/raix/Meteor-EventEmitter

Admin

• https://github.com/gterrono/houston
• https://github.com/yogiben/meteor-admin

Article outline

https://github.com/meteor/guide/blob/master/outlines/security.md

Major decision points

1. The security surface area of your app is:
   1. DDP - user login, methods, and publications
   2. Source code files served by Meteor
   3. Any HTTP endpoints you have
2. Use Meteor methods, not allow/deny, so that you can understand the attack surface of your app better
3. Methods and publications should never accept generic black-box objects as arguments, you should know exactly what the properties are on every argument
4. App secrets should be passed in through Meteor.settings
5. SSL is a must-have for any app
6. We have a security checklist, there are lots of points in there

Needed for #9.

<template name="a.b.c">
...
</template>

Should be accessible via:

Template.a.b.c.helpers({ ... });

It should also be OK to simultaneously have a template called a.b and a.b.c, so that you can do something like:

// Reusable list of widgets
Template.widgets.WidgetList

// Page tied to a specific URL/layout that does data loading (like a controller)
Template.widgets.WidgetList.Page

The idea of this guide is to give some guidance about how to publish a package onto Atmosphere, to contribute and share with the community.

Meteor Guide: Publishing a Package

1. Considering what's involved in publishing a package (i.e. do you have time to maintain it? Is it complete enough to be used by someone else?)
2. What should go in a single package, when should it be split?
3. Writing great documentation
4. Ensuring your package is solid/tested (especially in the face of public changes)
   • Use travis
5. Licensing your code
6. Publishing the package to atmosphere + publicizing it?
7. How to maintain a package -- PRs + Issues
   • Be polite, don't be afraid to point people to the Meteor contribution guidelines if you want a repro