React-ive Meteor
6 | 7 |An Example of React with a Meteor Backend
8 | 9 | 10 |
12 | Building a realtime backend for React can be difficult. Meteor makes it easy to buld an app with optimistic UI updating and realtime data streaming (view updates as DB records change).
16 | 17 |TL;DR
18 | 19 |This repo aims to be a sandbox that developers can learn how to create React apps with a Meteor backend. We'll have several branches with different ways to architect/use the app (such as a full flux spec).
20 | 21 |Meteor and Flux/Relay overlap quite a bit so the master branch will be the most simple version that beginners can pickup and start running.
22 | 23 |The data fetching layer of this app is based on the Flux and Relay ideas by allowing child components to declare the data field shape they need (coming soon). This data is passed down through props.
24 | 25 |The Meteor Development Group is working on making a deeper and more seamless integration with Meteor and React. Checkout the progress Here. Once this work is finished and released, this repo will be updated to use the official packages instead.
26 | 27 |Benefits of using React with Meteor
30 | 31 |-
32 |
- UI updates when DB updates (if needed) 33 |
- Isomorphic, share code on client and server 34 |
- Latency compensation (optimistic UI updates) 35 |
- Hot code reloads 36 |
- Easier data fetching than Flux 37 |
- Mini-Mongo client data store (easy querying) 38 |
- Query based data subscriptions (send me things for Feed) 39 |
- Easy microservice implementations via DDP 40 |
- Build system for preprocessing Sass, Babel, etc... 41 |
- Clean server-side code with fibers (soon with ES7 async/await) 42 |
- Modular Meteor, swap out any default components you wish 43 |
Cons of using Meteor
46 | 47 |-
48 |
- No official core SQL support yet (3rd party PostgreSQL and MySQL avail.) 49 |
- Limited server-side rendering (no first page html, but can send data if needed) 50 |
- No client-side file import system yet, uses packages, global namespaces and file load order instead 51 |
Fallacies of Meteor
54 | 55 |-
56 |
- Not secure - This has been resolved for quite a while... try to modify someone else's post! 57 |
- Not scalable - Many companies are using Meteor with large user bases 58 |
- Only supports Mongo - There's options just not official packages 59 |
- Meteor is only for realtime streams - works well with without realtime updates too! 60 |
These cons are on the core roadmap and will be resolved in the near future. However some of those could be blockers for your project.
63 | 64 |65 | 66 |
Usage
67 | 68 |-
69 |
curl https://install.meteor.com/ | shmore info
70 | make devormeter --settings '.config/devel/settings.json'
71 |
Views
74 | 75 |The master branch of this repo (and live example) use a mixture of Meteor's Blaze (handlebars like syntax) templates and React templates. Blaze is ideal for content that has no state and very little helpers. These large pages (like the about example) would be cumbersome to use in JSX.
76 | 77 |In this setup, the router renders 'page' templates which have the sole responsibility of handling static markup and rendering the topmost React components. These Blaze pages don't subscribe to data, that responsibility is for the topmost components. Example Code
78 | 79 |The rendering path looks something like this:
80 | 81 |-
82 |
- route /feed , routes.js render static
client/pages/feed.htmltemplate
83 | - static
feedtemplate renders FeedList and CreatePost React components
84 | - FeedList sets up data pub/sub and renders children 85 |
- CreatePost renders children 86 |
- view is ready 87 |
However if your app looks very 'app like' (Spotify, Slack, etc...) and not 'page like', using 100% React views is a better approach. See the full-react branch (soon) to see how you can render React views in using the React-Router module.
Data
94 | 95 |Fetching data with Meteor is quite different than a traditional REST system. Instead of making requests to single resource endpoints, you can subscribe to one or more publications of data. If this data in the database changes, you'll receive the new data in the client (instantly when using Mongo's Oplog). Using the MeteorMixin, this new data is synced with your subscription/state which re-renders your views.
96 | 97 |This new data is sent into a store called Mini-Mongo. It acts like an in memory Mongo database which turns out to be a really convenient way to access store data. Since this is in memory, ops are very fast (basically a key/value lookup). If you were using the PostgreSQL database you would use SQL to query the Mini-PostgreSQL store instead.
98 | 99 |The whole data cycle looks like this:
100 | 101 |-
102 |
- grandparent component renders children components 103 |
- children tell grandparent which data/fields they need 104 |
- grandparent subscribes to data all at one time 105 |
- server publishes data to client if authorized 106 |
- client accepts data and inserts into Mini-Mongo client store 107 |
- grandparent receives message that data they care about changed 108 |
- grandparent triggers re-render (via Meteor mixin) 109 |
- data flows from grandparent down to all children 110 |
New Meteor users can get tripped up in this process by sending too much data to the client, causing slowdown. This project uses a Flux/Realy type system to help prevent over publishing data. Each component specify what fields they need and their grandparent takes care of the actual query. This grandparent pushes down new data through their props. This makes testing very easy as the fetching only happens in one place. This data fetching system is a first draft so it may change some. It's also trying to stay simple by not trying to solve every edge case. We'll have a full flux/Relay branch for a more complex example of this.
113 | 114 |Meteor Methods
117 | 118 |Meteor provides an RPC style method that can be called on the client or on the server (even other non servers with a DDP adapter). You simply write a method on the server and on the client you call Meteor.call('multiply', 2, 5);. On the server the call would directly return 10 because we have fibers. On the client we can't block so the last argument would be a callback with params error and response. You also have access to a few resources inside the method like this.userId. It will contain the caller's userId if they are authenticated. Meteor uses these methods under the hood for the Authors.insert({name: 'foo'}) calls. However we're using our own model methods to bypass the hard to reason allow/deny rules.
Meteor provides an RPC style method that can be called on the client or on the server (even other non servers with a DDP adapter). You simply write a method on the server and on the client you call Meteor.call('multiply', 2, 5);. On the server the call would directly return 10 because we have fibers. On the client we can't block so the last argument would be a callback with params error and response. You also have access to a few resources inside the method like this.userId. It will contain the caller's userId if they are authenticated. Meteor uses these methods under the hood for the Authors.insert({name: 'foo'}) calls. However we're using our own model methods to bypass the hard to reason allow/deny rules. The Meteor methods turn out to be pretty good at standing in for a Flux Dispatcher.
Models
125 | 126 |The implementation of data models used in this project is just one of many ways to do it. Meteor does not have an ORM or Model layer so you're up to rolling your own or using a package. There are a few nice model packages but they have lots of magic involved. For simplicity i'm using a pattern i've used in several production apps. However to keep code a bit smaller, the inheritance uses __proto__ which is not supported in old IE. You would need a more verbose method to make this work with unsupported (old) browsers. These models also are not full featured like Mongoose or ActiveRecord, but again for simplicity sake these will work just fine.
Load Order
131 | 132 |Meteor doesn't currently have a file based module import system like Browserfy, Webpack, or ES6 modules (though we can import them and expose globally like this example). However i've heard this is coming in the near future. Currently Meteor has a set of rules it uses for loading. Read the full rundown here. client/ folders are only sent to the client and server folders are only sent to the server. The both folder will be sent to both client and server.
Code Generator
137 | 138 |No one likes typing boilerplate. If this project's folder structure works for you, Meteor Generate can save a lot of time. I'm in the middle of converting my old MVC patterns with Blaze over to Component structured React. This should be on NPM soon but in the mean time keep an eye out on this branch. It creates models, pages, routes, React components with Sass styles, and more.
139 | 140 |Security
143 | 144 |In short, trust nothing on the client. Assume everything being passed from the client to server could be a malicious value. Meteor provides utilities to check all inputs to make sure they are the shape and type you expect. This prevents Mongo injections. If they're not the shape/type you expect, reject it and throw an error. 145 | remove the insecure package. It automatically allows full access to insert/update/remove methods. This would be great for a throw away prototype or for learning the very basics but it's a security hazard.
146 | 147 |The autopublish package should also be removed. This will send your entire serverside database to the client and load it into the Mini-Mongo store. Not only is this slow with large data sets but it's a security hazard.
148 | Only send authorized data to the client. It's up to you to verify if a user should be allowed to subscribe to a publication. They can't access it in Mini-Mongo unless you send it to them. You only want to send data down that they are allowed/supposed to use.
Meteor Security Talk 151 | See Code Comments
152 | 153 |Additional Resources
156 | 157 |If you'd like to learn how to build an entire production app using Meteor and React, i'm finishing a screencast series that feels like a pair programing session. We'll start from scratch and build a production ready MVP of a photo sharing social network site.
158 | 159 |Check it out here: React Meteor Tutorials
160 | 161 |-
162 |
- TDD React Views Effortlessly in Meteor 163 |
- Scaling Production Meteor (no TODO apps here!) 164 |
- Serverside processing 165 |
- File uploads 166 |
- How to deploy with load balancing and elastic scaling 167 |
- Build for other mobile/desktop apps to connect to 168 |
- Explain Meteor's magic 169 |
- and more ... 170 |
We'll use techniques like TDD unit testing and acceptance testing to build a solid codebase. We'll talk about how to structure your app so it responds to change so it won't become brittle over time... something that other tutorials don't mention.
173 | 174 |We'll even TDD our React views, something that was previously too slow to even consider using traditional view frameworks.
175 | 176 |I've built several production apps that handle thousands of users a day. Learn some tips and tricks on making a production Meteor app that won't tip over with a few hundred concurrent users.
177 | 178 |Meteor can be very magical out of the box. We'll turn off a lot of that and build things manually at first. You can always add in the magic if you'd like. At the end you'll have a solid understanding on how the system is working.
179 | 180 |-
181 |
- Part 2 - React with Meteor Cordova iOS & Android Apps 182 |
- Part 3 - React Native iOS with Meteor Backend (Running Meteor in React Native JS) 183 |
- Part 4 - React OSX & Windows Desktop App using Electron 184 |