username

password

stripe_secret

stripe_publishable

Gain insights into Meteor.js, explore JavaScript concepts, and discover how to build full-stack applications with React integration, email support, and Stripe payment processing.

meteor-docker.tar.gz

CreateMeteorApp

CreateMeteorAppSettingsFile

CreateReactiveApp

RunAppWithAuthentication

RunAppWithInstallation

Meteor.js is a Node.js framework for developing JavaScript applications. It's used to create full-stack applications that use a single language on both the server and client sides. Meteor.js is easy to use and simplifies the development of web applications.

This course will begin by discussing the fundamental concepts of Meteor.js before moving on to refresh the learner's knowledge of some key aspects of JavaScript used in React, another JavaScript framework. Then, through hands-on experience, you will learn how to build a production-grade Meteor.js application with a React frontend. Following that, you'll learn how to set up an SMTP server to send transactional emails and how to integrate Stripe into your Meteor.js application to accept payments.

By the end of this course, you will be able to create a full-stack application from scratch using Meteor.js and feel confident working with MongoDB as well. You will also be able to integrate Stripe into any Meteor.js application you create.

Building Full Stack Applications Using Meteor.js

## The settings file

Meteor provides a way to store information such as keys and configuration data in a JSON file. This JSON file is added to the root of our project. We can call the file whatever we want, but the convention is that it’s usually named  `settings.json`.

A JSON file is a human-readable file that ends in a `.JSON` file extension. It normally consists of an object with key-value pairs. Meteor exposes the values in the JSON file through the `Meteor.settings` object. Below is an example of a settings file:







{
  "googleAPI" : "Qrtgeheh34525262",
  "magicNumber" : "0404oio44o4oo4"

}

The values in the settings file can only be accessed at the server. If we want to access it at the client, we should nest a public key in our settings object. 

### Nesting private and public keys 
Keys nested on the public object can be accessed on the client, while those nested on the private key object can only be accessed on the server.

Meteor doesn’t automatically become aware of our `settings.json` file. In our code, we have to explicitly tell Meteor that we have a settings file with important values. 

### Loading a settings file
There are two ways to load a settings file. These are :

1. Load them during Meteor startup by adding the `--settings` flag to the `meteor run` command below: 
   ````javascript
   meteor run --settings settings-development.json
   ````
   The command above loads the settings file named `settings-development.json` and makes it available during the lifetime of the application through the `Meteor.settings` object. To access the `clientApi` key stored in the public key above in “Settings File B,” we write the code below on the client:

   ````javascript
   import { Meteor } from "meteor/meteor";
   const clientApi = Meteor.settings.public.clientApi
   //23441990Educative"
   ````

2. The other way to load our settings file is to do so as an environment variable. This is how the file is loaded in a production environment. The exact method differs between different hosting providers, but if we use Galaxy, it’s very easy to do.

   ````javascript
   //at the command line containing the project type:
   meteor deploy myapp.meteor.com --settings settings-production.json
   //assuming we have a settings file for production at our project root.
   ````

### Best practices for the settings file
We should have different settings files for different environments. For example, there should be a separate settings file for development, staging, and production.

> **Note:** Never save the production settings file in version control. Doing this creates security risks. 


# The settings file

Meteor provides a way to store information such as keys and configuration data in a JSON file. This JSON file is added to the root of our project. We can call the file whatever we want, but the convention is that it’s usually named  `settings.json`.

A JSON file is a human-readable file that ends in a `.JSON` file extension. It normally consists of an object with key-value pairs. Meteor exposes the values in the JSON file through the `Meteor.settings` object. Below is an example of a settings file:







## Nesting private and public keys 
Keys nested on the public object can be accessed on the client, while those nested on the private key object can only be accessed on the server.

Meteor doesn’t automatically become aware of our `settings.json` file. In our code, we have to explicitly tell Meteor that we have a settings file with important values. 

## Loading a settings file
There are two ways to load a settings file. These are :

1. Load them during Meteor startup by adding the `--settings` flag to the `meteor run` command below: 
   ````javascript
   meteor run --settings settings-development.json
   ````
   The command above loads the settings file named `settings-development.json` and makes it available during the lifetime of the application through the `Meteor.settings` object. To access the `clientApi` key stored in the public key above in “Settings File B,” we write the code below on the client:

   ````javascript
   import { Meteor } from "meteor/meteor";
   const clientApi = Meteor.settings.public.clientApi
   //23441990Educative"
   ````

2. The other way to load our settings file is to do so as an environment variable. This is how the file is loaded in a production environment. The exact method differs between different hosting providers, but if we use Galaxy, it’s very easy to do.

   ````javascript
   //at the command line containing the project type:
   meteor deploy myapp.meteor.com --settings settings-production.json
   //assuming we have a settings file for production at our project root.
   ````

## Best practices for the settings file
We should have different settings files for different environments. For example, there should be a separate settings file for development, staging, and production.

> **Note:** Never save the production settings file in version control. Doing this creates security risks. 


Learn about the MeteorJS settings file and understand its sections.

Getting Started

Meteor Framework

Introduction to MeteorJS

Working With Data

A Pop Quiz On Data Access With Meteor

A Simple Idea Vote Application

JavaScript Refresher

Pop Quiz: JavaScript Refresher for React Development

An Overview of React

Pop Quiz: React

Coding an Online Bookshop

Deployment

Appendix

The Meteor Settings File

The settings file

Nesting private and public keys