Google News
Meteor.js Interview Questions
If you are a package author, in addition to putting api.use('modules') or api.use('ecmascript') in the Package.onUse section of your package.js file, you can also use a new API called api.mainModule to specify the main entry point for your package :
  name: 'my-modular-package'

  moment: '2.10.6'

Package.onUse((api) => {
  api.mainModule('server.js', 'server');
  api.mainModule('client.js', 'client');
Now server.js and client.js can import other files from the package source directory, even if those files have not been added using the api.addFiles function.
When you use api.mainModule, the exports of the main module are exposed globally as Package['my-modular-package'], along with any symbols exported by api.export, and thus become available to any code that imports the package. In other words, the main module gets to decide what value of Foo will be exported by api.export, as well as providing other properties that can be explicitly imported from the package:
// In an application that uses 'my-modular-package':
import { Foo as ExplicitFoo, bar } from 'meteor/my-modular-package';
console.log(Foo); // Auto-imported because of `api.export`.
console.log(ExplicitFoo); // Explicitly imported, but identical to `Foo`.
console.log(bar); // Exported by server.js or client.js, but not auto-imported.
Note that the import is from 'meteor/my-modular-package', not from 'my-modular-package'. Meteor package identifier strings must include the prefix meteor/... to disambiguate them from npm packages.
Finally, since this package is using the new modules package, and the package Npm.depends on the “moment” npm package, modules within the package can import moment from 'moment' on both the client and the server. This is great news, because previous versions of Meteor allowed npm imports only on the server, via Npm.require.
Packages can also specify a lazy main module:
Package.onUse(function (api) {
  api.mainModule("client.js", "client", { lazy: true });
This means the client.js module will not be evaluated during app startup unless/until another module imports it, and will not even be included in the client bundle if no importing code is found.
To import a method named exportedPackageMethod, simply :
import { exportedPackageMethod } from "meteor/<package name>";
Note : Packages with lazy main modules cannot use api.export to export global symbols to other packages/apps. Also, prior to Meteor it is neccessary to explicitly name the file containing the module: import "meteor/<package name>/client.js".
These rules could become frustrating when one file depended on a variable defined by another file, particularly when the first file was evaluated after the second file.
Thanks to modules, any load-order dependency you might imagine can be resolved by adding an import statement. So if a.js loads before b.js because of their file names, but a.js needs something defined by b.js, then a.js can simply import that value from b.js:
// a.js
import { bThing } from './b';
console.log(bThing, 'in a.js');
// b.js
export var bThing = 'a thing defined in b.js';
console.log(bThing, 'in b.js');
Sometimes a module doesn’t actually need to import anything from another module, but you still want to be sure the other module gets evaluated first. In such situations, you can use an even simpler import syntax:
// c.js
import './a';
console.log('in c.js');
No matter which of these modules is imported first, the order of the console.log calls will always be :
console.log(bThing, 'in b.js');
console.log(bThing, 'in a.js');
console.log('in c.js');
For backwards compatibility Meteor 1.3 still provides Meteor’s global namespacing for the Meteor core package as well as for other Meteor packages you include in your application. You can also still directly call functions such as Meteor.publish, as in previous versions of Meteor, without first importing them. However, it is recommended best practice that you first load all the Meteor “pseudo-globals” using the import { Name } from 'meteor/package' syntax before using them. For instance :
import { Meteor } from 'meteor/meteor';
import { EJSON } from 'meteor/ejson';
You may combine both eager evaluation and lazy loading using import in a single app. Any import statements are evaluated in the order they are listed in a file when that file is loaded and evaluated using these rules.
There are several load order rules. They are applied sequentially to all applicable files in the application, in the priority given below:
1. HTML template files are always loaded before everything else
2. Files beginning with main. are loaded last
3. Files inside any lib/ directory are loaded next
4. Files with deeper paths are loaded next
5. Files are then loaded in alphabetical order of the entire path


For example, the files above are arranged in the correct load order. main.html is loaded second because HTML templates are always loaded first, even if it begins with main., since rule 1 has priority over rule 2. However, it will be loaded after nav.html because rule 2 has priority over rule 5.
client/lib/styles.js and lib/feature/styles.js have identical load order up to rule 4; however, since client comes before lib alphabetically, it will be loaded first.
By default, any JavaScript files in your Meteor application folder are bundled and loaded on both the client and the server. However, the names of the files and directories inside your project can affect their load order, where they are loaded, and some other characteristics. Here is a list of file and directory names that are treated specially by Meteor:
* imports : Any directory named imports/ is not loaded anywhere and files must be imported using import.
* node_modules : Any directory named node_modules/ is not loaded anywhere. node.js packages installed into node_modules directories must be imported using import or by using Npm.depends in package.js.
* client : Any directory named client/ is not loaded on the server. Similar to wrapping your code in if (Meteor.isClient) { ... }. All files loaded on the client are automatically concatenated and minified when in production mode. In development mode, JavaScript and CSS files are not minified, to make debugging easier. CSS files are still combined into a single file for consistency between production and development, because changing the CSS file’s URL affects how URLs in it are processed.
HTML files in a Meteor application are treated quite a bit differently from a server-side framework. Meteor scans all the HTML files in your directory for three top-level elements: <head>, <body>, and <template>. The head and body sections are separately concatenated into a single head and body, which are transmitted to the client on initial page load.
* server : Any directory named server/ is not loaded on the client. Similar to wrapping your code in if (Meteor.isServer) { ... }, except the client never even receives the code. Any sensitive code that you don’t want served to the client, such as code containing passwords or authentication mechanisms, should be kept in the server/ directory.
Meteor gathers all your JavaScript files, excluding anything under the client, public, and private subdirectories, and loads them into a Node.js server instance. In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node.
* public : All files inside a top-level directory called public/ are served as-is to the client. When referencing these assets, do not include public/ in the URL, write the URL as if they were all in the top level. For example, reference public/bg.png as <img src='/bg.png' />. This is the best place for favicon.ico, robots.txt, and similar files.
* private : All files inside a top-level directory called private/ are only accessible from server code and can be loaded via the Assets API. This can be used for private data files and any files that are in your project directory that you don’t want to be accessible from the outside.
* client/compatibility : This folder is for compatibility with JavaScript libraries that rely on variables declared with var at the top level being exported as globals. Files in this directory are executed without being wrapped in a new variable scope. These files are executed before other client-side JavaScript files.
It is recommended to use npm for 3rd party JavaScript libraries and use import to control when files are loaded.
* tests : Any directory named tests/ is not loaded anywhere. Use this for any test code you want to run using a test runner outside of Meteor’s built-in test tools.
The following directories are also not loaded as part of your app code :
* Files/directories whose names start with a dot, like .meteor and .git
* packages/ : Used for local packages
* cordova-build-override/ : Used for advanced mobile build customizations
* programs : For legacy reasons
* Meteor apps are by default real time. The data in the templates automatically gets updated, as soon as changes to the data are made.

* Coding is very simple and beginner friendly.

* The development process is highly simplified as frontend, backend and database all uses one language i.e. JavaScript.
* Meteor is not very much suitable for large and complex application.

* The Meteor API is rapidly changing, so each new version may bring breaking changes.

* Due to newer in industry there are not as many hosting services available for Meteor apps yet (Meteor 1.0 version).
Meteor template uses three important tags. These are head, body and template. Head and body tag has same function as in regular HTML, but template tag is used to connect HTML to JavaScript.
   <title> </title>  
 <template name = "">   
EJSON is an extension of JSON syntax that supports Date and Binary types. The date and binary can be deserialize using the parse method.

For example :
if (Meteor.isClient) {  
   var ejsonDate = '{"$date": 1455029631493}';  
   var myDate = EJSON.parse(ejsonDate);