SlideShare a Scribd company logo

MeteorJS Introduction

•
•
Nitya Narasimhan
Nitya Narasimhan

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.

Related slideshows

D2W Branding Using jQuery ThemeRoller
D2W Branding Using jQuery ThemeRollerD2W Branding Using jQuery ThemeRoller
D2W Branding Using jQuery ThemeRoller
 
Angular Data Binding
Angular Data BindingAngular Data Binding
Angular Data Binding
 
Scalable Architectures - Microsoft Finland DevDays 2014
Scalable Architectures - Microsoft Finland DevDays 2014Scalable Architectures - Microsoft Finland DevDays 2014
Scalable Architectures - Microsoft Finland DevDays 2014
 
1 of 20
Download to read offline
Meteor : Blazing a trail..
¡  Background   ¡  The  7  Principles   ¡  Ge6ng  Started     ¡  Core  Concepts   ¡  More  Resources   ¡  Advanced  Topics   ¡  Q&A      
¡  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..)  
Meaningful  Mission   +  Meaningful  Funding   +   Incredibly  Smart  &  Passionate  Team     Mix  of  entrepreneurs,  researchers,   engineers  (ex-­‐MIT,  Stanford,  Asana,   Google,….)    
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  
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  
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  
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  
¡  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  
http://docs.meteor.com/#quickstart
¡  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  
¡  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
¡  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)  
¡  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)  
¡  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,  …    
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”  
On  September  25,  2013  (public,  on  Trello)  -­‐-­‐  (current  Meteor  version:  0.6.5.1)  
¡  Best  Learning  Resources  (link)   ¡  Discover  Meteor  (Book)   ¡  Evented  Mind  (Tutorials)   ¡  Meteor  Hacks  (Posts)   ¡  Atmosphere  (packages)   ¡  Stack  Overflow  (quesQons)   ¡  GitHub  (examples)    
¡  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)  
  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’    

More Related Content

MeteorJS Introduction

  • 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  
  • 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’