Meteor – The Fastest Way to Build Javascript Apps

Why Meteor is great for prototyping as well as for bigger apps. Showing you the key features of Meteor.

I held this presentation at the SeeIT meetup in Constance, Germany.

Transcript

1. The Fastest Way to Build Javascript Apps * @vuhrmeister * says Meteor
2. That’s me … • Javascript / Frontend Developer • Co-Founder at nemms • Formerly worked at HolidayCheck, Namics, innoQ • Passionate in creating great web experiences • Experience with Meteor since 2015 • I like Material Design :) Valentin Uhrmeister Twitter / Github: @vuhrmeister
3. My Meteor Projects
4. Blitzvote
5. Smide
6. https://nemms.app
7. nemms
8. What is Meteor?
9. Javascript Node.js MongoDB Websockets Optimistic UI Frontend Backend Web Mobile Desktop Cordova Dynamic Imports Server Side Rendering Realtime Hot Deployment Hot Code Push Open Source Build & Bundling Modern / legacy Browser Code Splitting Isomorph Universal Javascript
10. “Meteor is a full-stack JavaScript platform for developing modern web and mobile applications. Meteor includes a key set of technologies for building connected-client reactive applications, a build tool, and a curated set of packages from the Node.js and general JavaScript community.” – meteor.com • One language • Data on the wire • Integrate technologies you already use • Full stack reactivity • Build apps for any device • Ship more with less code
11. who tried it already? who used it in a real project? Some hard facts • Released in 2012 • > 40.000 Github stars • > 41.000 websites built with Meteor * … but: who actually heard of it? * https://trends.builtwith.com/framework/Meteor
12. Let’s get started … It’s as easy as: $ curl https://install.meteor.com/ | sh $ meteor create myapp $ cd myapp $ meteor
13. Let’s explore the features
14. Build system It transpiles, minifies and delivers … without any configuration
15. Database everywhere Server Client MongoDB by default Minimongo realtime
16. Collections • Abstraction of a MongoDB collection • Can be used decoupled from MongoDB • Working the same on server + client • Reactive
17. Collections // common code on client and server declares a DDP-managed mongo collection. const Messages = new Mongo.Collection('messages') // Return a cursor const myMessages = Messages.find({ userId: '123' }) // Return one document const myMessage = Messages.findOne({ _id: 'xyz' }) Messages.update({ _id: 'xyz' }, { $set: { important: true } }) Messages.insert({ text: 'Hello, world!' }) // Declare a local collection // Same API as for mongo collections available const LocalMessages = new Mongo.Collection(null)
18. We need a way to limit data sent to and manipulated on the client. Wait ... what about security?
19. Publish & Subscribe Concept of updating local data store Source: https://www.netvlies.nl
20. Publish & Subscribe if (Meteor.isServer) { Meteor.publish('messages', function ({ userId }) { return Messages.find({ userId }) }) } if (Meteor.isClient) { Meteor.subscribe('messages', { userId: 'someUserId' }) }
21. Security: Allow & Deny Rule set per collection for the client Better don’t use it!
22. Allow & Deny Messages.allow({ insert (userId, doc) { return (userId && doc.owner === userId) }, update (userId, doc, fields, modifier) { return doc.owner === userId }, remove (userId, doc) { return doc.owner === userId } })
23. Allow & Deny Messages.deny({ update (userId, doc, fields, modifier) { return !!fields.owner }, remove (userId, doc) { return doc.locked } })
24. Methods … are like RPCs (Remote Procedure Calls) Use them instead of defining “Allow & Deny” rules Define once, use everywhere …
25. Methods Meteor.methods({ 'todos.updateText' ({ todoId, newText }) { if (!this.userId) { throw new Meteor.Error('Unauthorized') } Todos.update(todoId, { $set: { text: newText } }) } })
26. Methods Meteor.call('todos.updateText', { todoId: '12345', newText: 'This is a todo item.', }, (err, res) => { if (err) { alert(err) } else { console.log(res) } })
27. Methods / Optimistic UI pay that coffee ok, coffee paid ok, coffee paid Client Server stop, no balance! coffee not paid
28. Methods / Optimistic UI Source: https://meteor.com
29. Choose your Frontend
30. Extend your App With tons of Meteor specific packages or (and) NPM packages
31. Deploy your App Meteor Galaxy Meteor Up meteor-now Scalingo (and others) Custom $ meteor deploy $ mup deploy $ meteor-now $ git push scalingo master $ meteor build
32. Hot Deployment Hot code push (during development) – of course! Instant update of connected clients – nice!
33. Ready to do some Prototyping? Let’s sum up …
34. • No initial setup • Don’t care about the build process • No need for separating API and UI * • Don’t write code that others have done already • Quick deployment Ideal for prototyping because …
35. * make use of these two packages: autopublish + insecure Don’t use in production ready apps!
36. Want to be really dirty? Don’t use ES modules, use globals That’s how Meteor worked before ES2015 That’s the backwards compatibility philosophy Ok, forget about that!
37. Ok, that’s all nice. But … what’s about real projects?
38. Code Splitting Load modules dynamically with ES proposal dynamic import Benefits: - Lower initial bundle size - Less execution time - Caching import('./my-module')
39. Code organization • Fully supports latest ECMAScript standard • Modularize as you need • Make use of packages
40. Evergreen vs. Nevergreen Need to support older browsers? Want latest browser to benefit from latest Javascript features? Just lean back and keep on coding
41. Evergreen vs. Nevergreen Benefit from: - Less code - Lower bundle size - Less execution time while still supporting older browsers Modern browsers
42. Server side rendering Supported Benefit from fast initial page load
43. Going mobile Need to be present in app stores? Benefit from Cordova Benefit from Hot Deployments * $ meteor add-platform android $ meteor add-platform ios $ meteor run ios $ meteor run ios-device
44. Are you convinced? Let’s sum up …
45. • Flexible • Performance in mind • Support for modern Javascript • Future proof Suitable for big apps because …
46. Why did we choose to use Meteor for nemms?
47. • Easy to set up • Existing accounts system * • No hassle with deployment setup • Powerful • Integration with Cordova • Personal experience
48. Was it the right decision?
49. What are some learnings?
50. • Great if you use Meteor out of the box • If you have a more complex architecture ◦ It can get complicated ◦ You may lose some of the features • MongoDB as the Bottleneck → Indexes • Reactivity needs performance ◦ Use Publications sparingly ◦ Restrict fetched data to contain only necessary fields ◦ Possibly use Redis Oplog when scaling
51. (or at least for being here tonight) Thanks for listening