search

meteor / guide

:book: Articles about Meteor best practices
http://guide.meteor.com/
Other
839 stars 306 forks source link

Data Loading and Management #33

Closed tmeasday closed 8 years ago

tmeasday commented 9 years ago

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.
mitar commented 8 years ago

I'm thinking about any time the sort order is not knowable on the client. For instance if you query a fulltext search endpoint (think ElasticSearch) to get a ranked set of documents for the publication.

You can just pass that extra score to the client in that case. See the example here: https://github.com/peerlibrary/meteor-subscription-scope

tmeasday commented 8 years ago

Well sure if you are ok about adding extra fields to the document. What I was thinking about was something similar to what you've done where the extra field is stripped somehow before coming back out to the query-er

mitar commented 8 years ago

Yes, but that score field is something you might even want to display to the user. Anyway, those are details. I am explaining my rationale. :-) As you noticed, it is something easy to change. And also I on purpose on the client side check only for existence of the field so that in theory we can add any extra payload.