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

## Meteor data transfer
Meteor is famous for its speed and reactivity of data, which is evident when a change is made and an application is updated instantly. This is as a result of its DDP.

The server publishes the data that’s subscribed to by the client. Meteor applications consist of two data stores, as illustrated in the diagram below:




## Publication
A publication is a named API on the server and sends data to the client through DDP. Publications server-only function that accepts two arguments. The first argument is the name of the publication, which must be a unique string, while the second argument is a function that’s called on the server each time a client subscribes to that publication.

Assuming we have a Mongo collection in Meteor referred to as `Students`, we can create a publication that returns a subset of data to the client, like this:

````javascript
//called only on the server
Meteor.publish("student.listBoys",function() {
   return Students.find({sex: "male"})
});
````
The code snippets above create a publication called `“student.listBoys”` that returns a subset of data (male students) to the client as a cursor. Meteor publishes the cursor to all subscribed clients.

We can also return an array of cursors from different collections. We can’t return two cursors from the same collection. The code sample below doesn’t work because we return two cursors from the same collection.

````javascript
//called only on the server
Meteor.publish("student.listBoys",function() {
  return [
  Students.find({sex: "male"}),
  Students.find({age: {$gt: 14}})]
});
//Will not work, because each cursor is from the same collection.
````
The following sample code that returns an array of cursors works because the cursors are from a different collection:

````javascript
//called only on the server
Meteor.publish("studentorders.listAmount",function() {
   return [
   Students.find({sex: "male"}),
   Orders.find({amount: {$lt: 300 }});
});
//This will work as we are returning two cursors from two different collections.
````
We might occasionally want to check for a `userId` before returning a cursor. To do this, we can access `this`, which points to the publish handler object.

Here’s a sample code:

````javascript
Meteor.publish("student.listScores",function() {
  if (!this.userId){
     return this.ready();
   }
   return Students.find({},{fields: 
   {scores:1 }});
});
````
The code above checks for a `userId` in the `this` object of the `publish` handler. The `This.userId` refers to the person calling the code. If it doesn’t find a `userId`, it informs Meteor that the publication is ready and should return from the function.

We should explicitly tell Meteor that our publication is ready to be returned, or better yet, we should return an empty array. Consider a case in which we don’t have a `userId` in the sample code above. Not having a `userId` makes the publication run forever without returning.


## Publication notes

+ It’s a server-only method defined in a server-only file.
+ It returns a cursor.
+ The string of a publication must be unique.
+ The `this.ready()` keyword indicates that the data is ready to send to the client.

## Subscription
A Meteor data transfer is incomplete without the subscription part of the chain. Subscription takes place on the client. To use a publication, we have to subscribe to it.

````javascript
import {Meteor} from "meteor/meteor";
Meteor.subscribe("name-of-publication-we-are-subscribing-to");
````
When we run the code above, it open a subscription to that publication. Then, the server starts to send data to the client to ensure that our client collection is current with the data on the specified server.

Take, for example, the `student.listBoys` publication we created above. Subscribing to it ensures that an up-to-date version of the list of boys in the server database is constantly synced with the client.

The `Meteor.subscribe("student.listBoys")` returns a ready property that informs the client that the data is ready and present in minimongo so that a query can be run against it to pull out data.

Here’s some sample code:

````javascript
.... component code above

 const student = useTracker(() => {
 const subscriptionHandle = Meteor.subscribe("student.listBoys")
//we performs a check here to find out if the subscription is ready.
if (subscriptionHandle.ready()){
 //data is now present at the client-collection
//lets query for it here
 return Students.find({sex: "male"})
}

}, []);

..... rest of our component code

````
Once again, the `useTracker` hook is both a React hook and a reactive function that reruns when one of its dependencies change. In this case, the dependency is the reactive data source (cursor), defined as `subscriptionHandle`.

When it’s ready, the function inside `useTracker` is rerun. Then, the minimongo client can be queried to retrieve our data.


## Subscription notes

+ Always subscribe to the exact data we want. Don’t oversubscribe data because it can lead to performance issues.
+ Subscribing to data puts it on the `client-side` collection stored in minimongo.
+ We can subscribe to more than one publication by using an array.

# Meteor data transfer
Meteor is famous for its speed and reactivity of data, which is evident when a change is made and an application is updated instantly. This is as a result of its DDP.

The server publishes the data that’s subscribed to by the client. Meteor applications consist of two data stores, as illustrated in the diagram below:




# Publication
A publication is a named API on the server and sends data to the client through DDP. Publications server-only function that accepts two arguments. The first argument is the name of the publication, which must be a unique string, while the second argument is a function that’s called on the server each time a client subscribes to that publication.

Assuming we have a Mongo collection in Meteor referred to as `Students`, we can create a publication that returns a subset of data to the client, like this:

````javascript
//called only on the server
Meteor.publish("student.listBoys",function() {
   return Students.find({sex: "male"})
});
````
The code snippets above create a publication called `“student.listBoys”` that returns a subset of data (male students) to the client as a cursor. Meteor publishes the cursor to all subscribed clients.

We can also return an array of cursors from different collections. We can’t return two cursors from the same collection. The code sample below doesn’t work because we return two cursors from the same collection.

````javascript
//called only on the server
Meteor.publish("student.listBoys",function() {
  return [
  Students.find({sex: "male"}),
  Students.find({age: {$gt: 14}})]
});
//Will not work, because each cursor is from the same collection.
````
The following sample code that returns an array of cursors works because the cursors are from a different collection:

````javascript
//called only on the server
Meteor.publish("studentorders.listAmount",function() {
   return [
   Students.find({sex: "male"}),
   Orders.find({amount: {$lt: 300 }});
});
//This will work as we are returning two cursors from two different collections.
````
We might occasionally want to check for a `userId` before returning a cursor. To do this, we can access `this`, which points to the publish handler object.

Here’s a sample code:

````javascript
Meteor.publish("student.listScores",function() {
  if (!this.userId){
     return this.ready();
   }
   return Students.find({},{fields: 
   {scores:1 }});
});
````
The code above checks for a `userId` in the `this` object of the `publish` handler. The `This.userId` refers to the person calling the code. If it doesn’t find a `userId`, it informs Meteor that the publication is ready and should return from the function.

We should explicitly tell Meteor that our publication is ready to be returned, or better yet, we should return an empty array. Consider a case in which we don’t have a `userId` in the sample code above. Not having a `userId` makes the publication run forever without returning.


# Publication notes

+ It’s a server-only method defined in a server-only file.
+ It returns a cursor.
+ The string of a publication must be unique.
+ The `this.ready()` keyword indicates that the data is ready to send to the client.

# Subscription
A Meteor data transfer is incomplete without the subscription part of the chain. Subscription takes place on the client. To use a publication, we have to subscribe to it.

````javascript
import {Meteor} from "meteor/meteor";
Meteor.subscribe("name-of-publication-we-are-subscribing-to");
````
When we run the code above, it open a subscription to that publication. Then, the server starts to send data to the client to ensure that our client collection is current with the data on the specified server.

Take, for example, the `student.listBoys` publication we created above. Subscribing to it ensures that an up-to-date version of the list of boys in the server database is constantly synced with the client.

The `Meteor.subscribe("student.listBoys")` returns a ready property that informs the client that the data is ready and present in minimongo so that a query can be run against it to pull out data.

Here’s some sample code:

````javascript
.... component code above

 const student = useTracker(() => {
 const subscriptionHandle = Meteor.subscribe("student.listBoys")
//we performs a check here to find out if the subscription is ready.
if (subscriptionHandle.ready()){
 //data is now present at the client-collection
//lets query for it here
 return Students.find({sex: "male"})
}

}, []);

..... rest of our component code

````
Once again, the `useTracker` hook is both a React hook and a reactive function that reruns when one of its dependencies change. In this case, the dependency is the reactive data source (cursor), defined as `subscriptionHandle`.

When it’s ready, the function inside `useTracker` is rerun. Then, the minimongo client can be queried to retrieve our data.


# Subscription notes

+ Always subscribe to the exact data we want. Don’t oversubscribe data because it can lead to performance issues.
+ Subscribing to data puts it on the `client-side` collection stored in minimongo.
+ We can subscribe to more than one publication by using an array.

Understand the MeteorJS concept of publication and subscriptions.

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

Publications and Subscriptions

Meteor data transfer

Publication