The document provides an overview of the Meteor platform for building web applications. It discusses that Meteor uses JavaScript on the client, server and database, promotes reactivity through its data publication and subscription system, and aims to provide a simple yet powerful platform for building "next-gen" web apps. Advanced topics like application structure, reactivity, and deployment are also covered at a high-level.

1. Meteor : Blazing a trail..

2. ¡ Background
¡ The
7
Principles
¡ Ge6ng
Started
¡ Core
Concepts
¡ More
Resources
¡ Advanced
Topics
¡ Q&A

3. ¡ A
pla@orm
for
building
‘next-­‐gen’
of
web
apps
¡ JavaScript
all
the
way
(client,
server,
database)
¡ Ecosystem
friendly
(mix
and
match
with
‘DDP’)
¡ InnovaQve
ideas
(‘data
everywhere’,
reacQvity..)

4. Meaningful
Mission
+
Meaningful
Funding
+
Incredibly
Smart
&
Passionate
Team
Mix
of
entrepreneurs,
researchers,
engineers
(ex-­‐MIT,
Stanford,
Asana,
Google,….)

5. Controller
Controller
Application
Logic,
Controllers
&
Helpers
Model
Model
Model
SMART
SERVER
View
View
Application
View
User
Events
Server
Events
DUMB
CLIENT
Render
returned
‘page’
views
DATABASE
Send
user
event
Cache
Maintain
state

6. Controller
Controller
Application
Logic
Model
Model
Model
SMART
SERVER
Application
View
User
Events
Server
Events
SMART
CLIENT
Update
view
page
inline
DATABASE
Request
templates,
Get
data
Controllers
&
Helpers
Handle
events
Cache
Maintain
state

7. Controller
Controller
Application
Logic
Model
Model
Model
SMART
SERVER
Application
View
User
Events
Server
Events
METEOR
CLIENT
Sync
data
proactively
DATABASE
Subscribe
to
data
Controllers
&
Helpers
React
to
events
Cache
React
to
data
Session
DDP
Distributed
Data
Protocol

8. Controller
Controller
Meteor
“bundle”
(app
+
core
packages)
Model
Model
BSON/
JSON
NODE
RUNTIME
Handlebars
Templates
User
Events
Server
Events
BROWSER
Sync
data
proactively
MONGO
CLUSTER
Subscribe
to
data
JavaScript
Mini
Mongo

9. ¡ Data
on
the
wire.
Client
craSs
all
the
HTML.
¡ One
language.
Client
+
server
+
database
=
all
JS
¡ Database
everywhere.
Same
API
at
client,
server
¡ Latency
compensaQon.
Fake
it
Qll
you
make
it
¡ Full
Stack
ReacQvity.
“Real-­‐Qme”
is
the
default
¡ Embrace
the
Ecosystem.
Integrate
before
replace
¡ Simplicity
=
ProducQvity.
Clean
and
classic
APIs

10. http://docs.meteor.com/#quickstart

11. ¡ Define
‘collecQons’.
Data
models
for
Mongo
DB.
¡ Publish
data
‘cursors’
on
server.
Query
results
¡ Subscribe
to
cursors
on
client.
Auto-­‐updated
¡ Write
view
templates.
Structures
&
Styles
¡ Write
view
helpers.
‘Bind’
cursor
results
to
view
¡ Define
routes
&
controllers.
Navigate
views
¡ Make
it
reacQve.
Use
dynamic
Session/cursor
vars

12. ¡ ApplicaQon
Structure
Maaers
¡ Data
Security
(pub-­‐sub,
cache,
simulaQon)
¡ ReacQvity
(in
data
source
+
computaQon)
¡ Live
HTML
(in-­‐place
reacQve
DOM
updates)
¡ Templates
(clear
separaQon
of
view
&
helper)
¡ Packages
(core
+
official
+
unofficial)
¡ Name-­‐spacing
(automated
wrappers)
¡ Deploying
(run
vs.
bundle
vs.
deploy)
¡ ContribuQng
(wriQng
packages)
http://docs.meteor.com/#concepts

13. ¡ Directory
structure
impacts
inclusion
§ /client
loaded
to
client
only,
/server
loaded
to
server
only,
/tests
never
loaded
§ /public
files
‘served’
(staQc
assets),
/private
files
access
to
server
(via
Assets)
§ Other
files
are
loaded
(and
shared)
across
client
and
server
¡ Name,
locaQon
depth
impacts
load
order
§ /lib
loaded
first,
main.*
loaded
last
§ Subdirectories
before
directories,
in
alphabeQcal
order
within
directory
¡ Deployment
(as
bundle)
§ Server
runs
in
Node
fiber
(1
thread/request)
§ Client
Templates
(HTML)
converted
to
JS
funcQons
(Template.*)
§ Client
CSS
bundled,
JS
minified
&
bundled
(creates
1
file
each)

14. ¡ Client
&
Server
have
the
same
database
API
§ Queries,
validators,
etc.
are
idenQcal
BUT
§ Code
on
server
runs
against
actual
DB,
code
on
client
runs
against
cached
DB
§ ‘Autopublish’
and
‘insecure’
packages
to
‘fine-­‐tune’
access
levels
¡ Mongo
as
‘signature’
database
(only
opQon)
§ Document-­‐oriented
database
organized
into
‘CollecQons’
§ Documents
in
JSON-­‐like
format,
good
query/aggregaQon
support
§ Uses
‘minimongo’
as
client-­‐side
Mongo-­‐compliant
in-­‐memory
cache
¡ AuthenQcaQon
(Accounts),
Input
ValidaQon
(check)

15. ¡ Automated
re-­‐computaQon
on
data
changes
§ Writer
regular
code
(imperaQve
style
programming)
§ Create
reacQve
data
sources
(add
dependency
on
‘Session’
variables)
§ Trigger
reacQve
computaQon
(when
variable
value
changes)
¡ ReacQve
Data
Sources
§ Session
variables,
CollecQon
queries
(cursors),
Meteor.user,
…
¡ ReacQve
Data
ComputaQon
§ Template
handlers,
Deps.autorun,
…

16. Simplicity
(JavaScript)
Reactivity
(Event
Driven)
Interoperability
(via
DDP)
Community
(smart
packages)
Maturity
(changing,
not
yet
v1.0.)
Scalability*
(need
for
patterns)
Consistency*
(legacy
creep)
Testability
(but
wait
for
it..)
*
“With
great
power
comes
great
responsibility”

17. On
September
25,
2013
(public,
on
Trello)
-­‐-­‐
(current
Meteor
version:
0.6.5.1)

18. ¡ Best
Learning
Resources
(link)
¡ Discover
Meteor
(Book)
¡ Evented
Mind
(Tutorials)
¡ Meteor
Hacks
(Posts)
¡ Atmosphere
(packages)
¡ Stack
Overflow
(quesQons)
¡ GitHub
(examples)

19. ¡ How
Does
It
Work?
§ Data
Consistency
(CollecQons
&
‘Smart’
CollecQons)
§ ReacQvity
(Dependency
tracking
and
automaQon)
§ Interoperability
(DDP,
The
Distributed
Data
Protocol)
¡ How
Do
I
do
“X”?
§ TemplaQng
(with
Handlebars)
&
Styling
(with
Bootstrap)
§ RouQng
(with
Iron
Router)
§ TesQng
(with
Laika)
&
CI
(with
Travis)
§ Asynchronous
Ops
(with
Node
Fibers
&
Future)

20.
QuesQons
or
Feedback?
(influence
content
and
coverage
in
future
talks)
Close
the
loop
..
¡ Twiaer
è
@nitya
or
#meteor-­‐nygdg
¡ Google+
è
hap://gplus.to/nitya
¡ Meetup
è
NYC-­‐GDG
‘comments’