Google News
logo
Meteor.js Interview Questions
Meteor is a full-stack JavaScript platform for developing modern web and mobile applications (iOS, Android and Windows). 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 allows you to develop in one language, JavaScript, in all environments: application server, web browser, and mobile device.
 
* Meteor uses data on the wire, meaning the server sends data, not HTML, and the client renders it.
 
* Meteor embraces the ecosystem, bringing the best parts of the extremely active JavaScript community to you in a careful and considered way.
 
* Meteor provides full stack reactivity, allowing your UI to seamlessly reflect the true state of the world with minimal development effort.
Meteor is a full-stack JavaScript App Platform that assembles all the pieces you need to build modern web, desktop, and mobile apps with a single JavaScript codebase. React and Vue.js are JavaScript UI frameworks that can be used in conjunction with Meteor. Think of React, Vue.js, Svelte and Blaze as the 'V' in MVC. Meteor automatically manages the data flow between cloud and client applications, as well as client UI state and rendering regardless of which UI framework you use. You can also use Meteor with GraphQL or REST if you prefer.
Any database with a Node.js driver is supported by Meteor as we are a Node.js application on the server. MongoDB is usually the most used in Meteor community as it has more integrations with Meteor as well as a subscriptions model implemented on top of it.
You can get involved with Meteor’s community in a number of ways. Some of these include reporting bugs, triaging issues, or maintaining a community package. If you have any questions or would like to chat with like-minded developers, we recommend you check out our Slack community, Meteor Forums or GitHub. In these channels, you'll be able to collaborate with developers, learn best practices and even answer questions yourself.
In Meteor, it is also simple and straightforward to use the import syntax to load npm packages on the client or server and access the package’s exported symbols as you would with any other module. You can also import from Meteor Atmosphere packages, but the import path must be prefixed with meteor/ to avoid conflict with the npm package namespace. For example, to import moment from npm and HTTP from Atmosphere:

import moment from 'moment';          // default import from npm
import { HTTP } from 'meteor/http';   // named import from Atmosphere​
Web and mobile : Meteor provide platform for developing Android, IOS and Web apps.

Packages : Meteor support huge number of packages that are easy to install and use.

Universal Apps : The same code is used for mobile device and web browser.

Meteor Galaxy : Meteor offers Meteor Galaxy Cloud service for app development.
Hot code pushes are loaded by client devices, e.g. phones, in the background while the app continues to run. Once the new code has been fully loaded, the device is able to switch over to the new code quickly. This reduces or in some cases entirely eliminates the need to update code via the App Store and Google Play.
In Meteor, import statements compile to CommonJS require syntax. However, as a convention we encourage you to use import.
 
With that said, in some situations you may need to call out to require directly. One notable example is when requiring client or server-only code from a common file. As imports must be at the top-level scope, you may not place them within an  if  statement, so you’ll need to write code like:
if (Meteor.isClient) {
  require('./client-only-file.js');
}
Note that dynamic calls to require() (where the name being required can change at runtime) cannot be analyzed correctly and may result in broken client bundles.
 
If you need to require from an ES2015 module with a default export, you can grab the export with require("package").default.
CoffeeScript has been a first-class supported language since Meteor’s early days. Even though today we recommend ES2015, we still intend to support CoffeeScript fully.
 
As of CoffeeScript 1.11.0, CoffeeScript supports import and export statements natively. Make sure you are using the latest version of the CoffeeScript package in your project to get this support. New projects created today will get this version with meteor add coffeescript. Make sure you don’t forget to include the ecmascript and modules packages : meteor add ecmascript. (The modules package is implied by ecmascript.)
 
CoffeeScript import syntax is nearly identical to the ES2015 syntax you see above :
import { Meteor } from 'meteor/meteor'
import SimpleSchema from 'simpl-schema'
import { Lists } from './lists.coffee'
You can also use traditional CommonJS syntax with CoffeeScript.
Use in your application package.json file the section meteor.
 
This is available since Meteor 1.7
{
  "meteor": {
    "mainModule": {
      "client": "client/main.js",
      "server": "server/main.js"
    }
  }
}
When specified, these entry points will define in which files Meteor is going to start the evaluation process for each architecture (client and server).
 
This way Meteor is not going to eager load any other js files.
 
There is also an architecture for the legacy client, which is useful if you want to load polyfills or other code for old browsers before importing the main module for the modern client.
 
In addition to meteor.mainModule, the meteor section of package.json may also specify meteor.testModule to control which test modules are loaded by meteor test or meteor test --full-app:
{
  "meteor": {
    "mainModule": {
      "client": "client/main.js",
      "server": "server/main.js"
    },
    "testModule": "tests.js"
  }
}
If your client and server test files are different, you can expand the testModule configuration using the same syntax as mainModule:
{
  "meteor": {
    "mainModule": {
      "client": "client/main.js",
      "server": "server/main.js"
    },
    "testModule": {
      "client": "client/tests.js",
      "server": "server/tests.js"
    }
  }
}
The same test module will be loaded whether or not you use the --full-app option.
 
Any tests that need to detect --full-app should check Meteor.isAppTest.
 
The module(s) specified by meteor.testModule can import other test modules at runtime, so you can still distribute test files across your codebase; just make sure you import the ones you want to run.
 
To disable eager loading of modules on a given architecture, simply provide a mainModule value of false:
{
  "meteor": {
    "mainModule": {
      "client": false,
      "server": "server/main.js"
    }
  }
}