Meetup AthensExperiences, apps, workshops, fellow meteorites!

1

2014 1

1 2

5

# Collections vs Methods

# Organizationshare athens.meteor.com development

share docs and presentations

next meetup in December?

Best practices and DRY code

Collections vs. Methods

# Collectionlatency compensation, sync, reactive

all available, restrict as you need

Basics

# Methodencapsulated, async

all manual, add what you need

activities.find date: $gt: new Date()

Get data

Meteor.call ‘findA’, new Date(), (activities) -> ...

activities.insert date: new Date(), label: “mooo!”straight to DB, no data sanitization, no security (user

signed in?)

Write data

Meteor.call ‘createA’, “mooo!”, (activities) -> …“new Date()” on server-side (locale?), off the DB-on-the-

client paradigm, update client > update server

vote.insert user: Meteor.userId(), activity: @idactivities.update { _id: @id }, $addToSet: votes: uvote collection on client, potential vulnerability, instant

Linked data + denormalization

Meteor.call ‘vote’, @id@userId on server, updates both collections, delayed

Method

Meteor.methods

vote: (aid) ->

check @userId, String # what if not?

check aid, String

check (a = activities.findOne _id: aid), Object

< insert into collections >

security

vote.deny

insert: (userId, vote) ->

vote.user = Meteor.userId()

not (vote.user? and \

(activities.findOne vote.activity)?)

security #2

votes.deny

update: -> true

remove: (userId, vote) -> vote.user isnt userId

with collection hooks

votes.deny

insert: (uid, v) ->

not (uid? and (activities.findOne v?.activity)?)

vote.after.insert (userId, doc, …)->

< update activities collection’s votes field >

with collection hooks + protect field

vote.after.insert (userId, doc, …)->

< update activities collection’s votes field >

activities.deny

update: (uid, a, fields) -> ‘votes’ in fields

Too complicated?

How about ownership, being signed in?

Timestamping data entities?

Housekeeping (relations, counts)?

Soft remove?

> collection behaviours!

DRY Semantics :)

votes.signedIn()

votes.owned()

votes.denormalize ‘activity’, activities, ‘votes’

votes.count ‘activity’, activities, ‘voteCount’

Ensure data integrity, define once+use everywhere+reuse,

include security rules

Pro and con method collection

High security

Easier to implement

Encapsulation

Repetitive> potential security risks due to

inconsistent updates

DB-on-client flexibility

DRY code

Reactiveness

Collection on client> bandwidth, potential security rist by

exposing collection

So which one is the right one?

# Methods complex instructions to server, hide data, things you can’t

do on the client (send mails, …) # redundancy

#Collectionsfull Meteor power and flexibility, easy security rules w/t

dependencies, or use/reuse behaviours # security risk

Precious Packages

collection-behaviours

collection-hooks

publish-with-relations

work in process: voting, related-collections

# Collections vs Methods

# Organizationshare athens.meteor.com development

share docs and presentations

next meetup in December?