Meteor is a full-stack JavaScript platform for developing modern Web and mobile applications.
Within one project, you are able to build your client (browser and/or hybrid mobile App for Android and/or iOS) and server sides.
Reference pages:
On Mac and Linux, the meteor command line tool assumes that the ssh command line tool, used to make secure connections to other computers, is always present. On Windows, this tool needs to be installed. Below are listed two options for setting it up and using it.
Within Meteor's data subsystem, a server publication and its corresponding client subscriptions are the main mechanisms of reactive, live data transport where the underlying data is constantly synchronized between the server and the client.
An asynchronously wrapped function may still be ran asynchronously if a callback with parameters (error, result) => {} is given as a parameter to the wrapped function.
The incorporation of Meteor.wrapAsync allows for code ridden with callbacks to be simplified given that callbacks can now be neglected in compensation for making the call block its present Fiber.
To understand how Fibers work, read here: https://www.npmjs.com/package/fibers.
client
All code in the client directory is run only in the client-side, or web browser.
client/compatibility
The compatibility directory contains legacy or 3rd party code, such as jQuery libraries, etc.
lib
The lib directory is loaded before other directories in your Meteor project, and is loaded on both the server and client. This is the preferred place to define data models, isomorphic libraries, and business logic.
imports
The imports directory is a directory on the server that is available to both the server and client, but only before the client bundle gets shipped to the client.
packages
The packages directory is where custom packages are stored during local development. When using the standard command meteor add package:name to add a package, Meteor will look first in this directory if a local package has the corresponding description name in its package.js file. If not, it will poll Atmosphere as usual.
private
The private directory contains static files that should only be available on the web server.
public
The public directory contains static files that are only available on the application client. This may including branding assets, etc.
server
The server directory contains server-side assets. This can include authentication logic, methods, and other code that may need security consideration.
tests
The tests directory is omitted by default when your application is bundled and deployed.
As suggested by Richard Silverton it is a convenient idea to put not only the meteor project directory under version control, but also its parent directory.
That way you can keep files under version control without having meteor to deal with it.
The CollectionFS package has been shelved and discontinued by it's author; however, since there's no alternative package in Atmosphere or the Meteor ecosystem for using Mongo's GridFS functionality, and the code still works perfectly fine; we recommend not removing the example from StackOverflow Documentation until some other GridFS solution can be documented as it's replacement.
Additional Research
Filepicker.io Uploads and Image Conversion
Dario's Save File Pattern
Micha Roon's File Upload Pattern
EventedMind File Upload Package
React is a JavaScript library for building user interfaces. It's open source, developed and maintained by Facebook. Meteor has production-ready support for React.
Resources:
It should be noted that Meteor is simply Javascript and Node.js. Yes, it's a very specific implementation of those two technologies, and has it's own unique ecosystem, and leverages isomorphic APIs and a JSON datastore to achieve some truly amazing results. But, at the end of the day, Meteor is a web technology, and it's written in Javascript. So all of your typical javascript performance techniques still apply. Start there.
25 Javascript Performance Techniques
Performance Optimizations for High Speed Javascript
Optimizing JavaScript Code
Performance Tips for JavaScript in V8
10 Javascript Performance Boosting Tip
Write Efficient JavaScript
Improving the Performance of your Meteor JS projects
Further Appcache Research
http://www.html5rocks.com/en/tutorials/indexeddb/todo/
http://grinninggecko.com/2011/04/22/increasing-chromes-offline-application-cache-storage-limit/
http://www.html5rocks.com/en/tutorials/offline/quota-research/
https://developers.google.com/chrome/apps/docs/developers_guide?csw=1#installing
https://developers.google.com/chrome/apps/docs/developers_guide?csw=1#manifest
If you're not opposed to running a Ruby utility, Genghis is a classic: http://genghisapp.com/
But for scalable production use, get yourself to MongoHQ.
http://www.mongohq.com/
Also, the Mongo Monitoring Service, from 10Gen, the makers of Mongo:
https://mms.mongodb.com/
MongoClient is written in Meteor, Completely Free, Open Source And Cross-Platform.
RoboMongo Native cross-platform MongoDB management tool
It's often necessary to run maintenance scripts on your database. Fields get renamed; data structures get changed; features that you used to support get removed; services get migrated. The list of reasons why you might want to change your schema is pretty limitless. So, the 'why' is pretty self explanatory.
The 'how' is a little more unfamiliar. For those people accustomed to SQL functions, the above database scripts will look strange. But notice how they're all in javascript, and how they're using the same API as we use throughout Meteor, on both the server and client. We have a consistent API through our database, server, and client.
Run the schema migration commands from the meteor mongo shell:
# run meteor
meteor
# access the database shell in a second terminal window
meteor mongo
MDN documentation for imports: https://developer.mozilla.org/en/docs/web/javascript/reference/statements/import MDN documentation for exports: https://developer.mozilla.org/en/docs/web/javascript/reference/statements/export ExploringJS chapter on modules: http://exploringjs.com/es6/ch_modules.html
Server Aggregation
Average Aggregation Queries in Meteor
is it possible to package a 'real' mongodb library for use on the *server* side only in meteor 0.6
Client Aggregation (Minimongo)
https://github.com/utunga/pocketmeteor/tree/master/packages/mongowrapper
Publishing a Release Track is actually pretty simple if you understand a) that the publish-release command requires a .json file as a parameter, and b) what that file looks like. That's definitely the biggest hurdle in getting started, because it's pretty much not documented anywhere.
Just keep in mind that every package in the release has to be published and on Atmosphere. The .meteor/versions file of an app is a particularly good place for finding all the necessary packages and versions that should go into the release.
After that, it's a matter of figuring out what you're willing to support, what you want to include, etc. Here is a partial Venn Diagram of what the Clinical Release is currently working on; and should give you a general idea of how we're going about the decision making process of what gets included.
For more discussion, see the topic on the Meteor Forums:
https://forums.meteor.com/t/custom-meteor-release/13736/6
The above Blaze examples are highly compatible with the http://bootsnipp.com/ library, which only provides the HTML and CSS for components, and leaves the javascript up to the developer. This allows for components to share the same underlying sorting, filtering, query, and cursor methods.
For those not familiar, a Replica Set is defined as a redundant configuration of three servers. A Sharded Database is defined as a horizintally scalled database, where each Shard is defined as a Replica Set. Therefore, a sharded Mongo cluster involves a minimum of 11 servers for a 2 shard cluster, and increases by three servers for each additional shard. So, a sharded cluster always has 11, 14, 17, 20, 23, etc server instances. That is, there's 2 shards of 3 servers each, 3 more config controllers, and 2 routers. 11 servers total for a 2 shard cluster.
The package cron-tick is a very simple package for background tasks but it does not support multiple processes, if you run your app in multiple processes (or containers) use percolate:synced-cron instead.
A useful way to think about Mongo collections is in terms of Who, What, When, Where, Why, and How. Mongo has the following optimizations for different types of data:
Where - GeoJSON
When - ObjectID timestamps
Who - Meteor Account Strings
How - JSON for decision trees
Which leaves the default document in Mongo roughly representing a 'What'.
Nightwatch has been providing Acceptance and End-to-End testing for Meteor apps since v0.5 days, and has managed migrations from PHP to Spark to Blaze and to React; and all major Continuous Integration platforms. For additional help, please see:
Nightwatch has been providing Acceptance and End-to-End testing for Meteor apps since v0.5 days, and has managed migrations from PHP to Spark to Blaze and to React; and all major Continuous Integration platforms. For additional help, please see:
Nightwatch has been providing Acceptance and End-to-End testing for Meteor apps since v0.5 days, and has managed migrations from PHP to Spark to Blaze and to React; and all major Continuous Integration platforms. For additional help, please see:
Note that we did not discuss how to use & develop your local packages. There are several ways, I suggest to use the PACKAGE_DIRS environment variable described by David Weldon on his website.
This topic is heavily inspired by Nate Strausers Migrating Meteor Apps from Modulus to Galaxy with Continuous Deployment from Codeship.