Meteor
A better way to build apps.
This is not a small project. There are many big problems to tackle, such as: How do we transition the web from a "dumb terminal" model that is based on serving HTML, to a client/server model that is based on exchanging data?
Welcome!
Who am I?
Tim Heckel | tim@slatebox.com
https://github.com/TimHeckel
http://twitter.com/TimHeckelr
I work at TIES, a consortium of school districts in MN developing software for 1/3 of the students in the state.
- Built slatebox.com / slateboxjs / appboxr / jQuery plugins
- Active in the SignalR (Microsoft OSS project) community
- InfoQ Javascript/HTML5 editor
The Dream of the 90s is alive
Ah, 1996 how you've shaped us.
The high latency connection is between
the CPU/DB (rails, et al) AND the user
App Development Today
It's all in the cloud, served to rich JS, iOS, and Android clients.
The high latency connection is NOW
between the client's CPU and the DB
Back to the future
Meteor takes inspiration from
the client/server days of old
Two Historical Implications
-
HTTP is a
fundamentally flawed
protocol that is not designed for the modern app.
-
RESTful processes were developed to embrace the
statelessness of HTTP
.
While these may be true, nothing is going to change
the prevalence of HTTP anytime soon.
So....Meteor negotiates the constraints of the PAST
while building toward the future.
Seven Principles
How does Meteor achieve this balance?
- Data on the Wire
- One Language
- Database everywhere
- Latency Compensation
- Full Stack Reactivity
- Embrace the Ecosystem
- Simplicity equals productivity
HTML: Three Tags to Rule All Others
- <head>
- Title
- <script> <link> tags like normal
- <body>
- {{renderPage}} if using meteor-router
- <template>
- reusable Handlebar templates
Flattened File System
Meteor scans the entire app's folder structure
and "flattens" everything into the root.
Global environment inside V8 on the node.js server.
/client - client side code
/server - server side code
/tests - not loaded anywhere
/everywhere else - client & server
No ORMs / APIs
- Every client gets an in-memory database.
- Mongo is the only supported platform right now.
- Write directly to the client database; if the update passes server-side security, the server database gets updated.
Reactivity
- Declarative style. A + B = C. If A or B changes, C will auto-update.
- `C` lives in a Reactive Context: (1) inside a Template, or (2) inside a Meteor.autorun code block.
- `A` and `B` are Reactive Triggers: (1) Session variables (not to be confused with traditional Sessions); (2) Database queries; (3) Meteor.user properties.
Meteor.autorun(function () {
Meteor.subscribe("messages", Session.get("currentRoomId"));
});
Security
When you're beyond prototyping:
meteor remove autopublish
meteor remove insecure
Clients are sandboxed.
Only the server can run privileged code.
Let's build an app!
Helpful Links
- http://docs.meteor.com (pay attention to the upper-right Server / Client / Anywhere)
- https://github.com/oortcloud/unofficial-meteor-faq (a very good FAQ for development in meteor)
- http://www.youtube.com/watch?v=kZumPtYMR3Y (David Greenspan gives a talk on Spark)
- http://www.youtube.com/watch?v=vpp-8gkPWVE (Matt Debergalis' talk on Meteor)
- https://trello.com/board/meteor-roadmap/508721606e02bb9d570016ae (Roadmap)
asd
By timh
