Learn to employ the framework Sails 0.12 to build a backend RESTful API that serves JSON. Its design was based off the Ruby on Rails framework paradigm. Sailsjs is useful for fast prototyping and makes it very convenient to quickly make a server using Nodejs.

Quick Start Introduction to Sails

# Summary of Sales.js Course Introduction

This course provides a brief introduction to **Sales.js**, focusing on the following key topics:

- **Installation**: How to install Sales version 0.12.
- **Project Generation**: Guidance on generating a new Sales project.
- **Application Structure**: Overview of the app's structure, including models and controllers.
- **RESTful API**: Instructions on how to utilize the blueprint API for creating a RESTful API automatically.

This introduction is intended to give a general understanding of Sales.js without diving deeply into every detail of the application structure. 

**Next Steps**: The next video will cover the installation of Sales and the generation of the app.

This course is a quick introduction to Sales.js.
We are going to learn how to install Sales version 0.12
and how to generate a project.
Then we're going to look at the app structure.
We're going to look at the models, controllers,
and how to get your sales application
to provide a RESTful API right out of the box
with the blueprint API that is provided by Sales.
This is supposed to be a brief introduction to Sales
and is not going to go into very much details
into every aspect of the application structure.
So I hope you like it and let's get started in the next video
where we're going to start installing Sales
and generating the app.


01 Quick Start Introduction to Sails

Installing Sails and Generating a Project

# Lecture Summary: Installing Sails and Generating a Project

In this lecture, we learn how to install Sails and generate a new project. Here's a summary of the key points:

1. **Open the Terminal**: Begin by opening your terminal.

2. **Check Node Installation**: Ensure that Node.js is installed. The speaker is using Node version 6.11 and npm version 3.

3. **Install Sails Globally**: Use the command:
   ```bash
   npm install -g sails
   ```
   This command installs Sails globally on your machine.

4. **Sails Version**: The lecture focuses on Sails version 0.12. For more information, you can visit:
   - [Sails Documentation](http://sailsjs.com)
   - [Sails GitHub Repository](https://github.com/balderdashy/sails)

5. **Ignore Warnings**: While installing, you might encounter warnings, but they can be ignored.

6. **Generate a New Project**: After Sails is installed, create a new project using:
   ```bash
   sails new sails-quickstart
   ```
   This command generates a new Sails application named "sails-quickstart."

7. **Navigate to the Project Directory**: Change directories to your newly created project:
   ```bash
   cd sails-quickstart
   ```

8. **Next Steps**: The next lecture will cover an overview of the application structure for a Sails app.

This concludes the lecture on installing Sails and creating a new project.

In this lecture we are going to learn how to install sales and how to generate a project.
First let's open up the terminal.
So before install sales we have to make sure we have node install.
Alright.
I am using node version 6.11 with npm3.
Once you get that you can just say npm install dash g for global install sales.
So the sales command will allow us to generate a project.
So it's going to take a little bit to install.
So we are installing sales version 0.12.
This course is about sales version 0.12.
If you want to learn more about sales you can always go to its website and take a look.
Have very good documentation there.
If you are on github they also have their repository here.
github.com slash boulder dash slash sales.
Another dash is one of the creators of sales.
And sales is also npm module the one that we are installing right now.
In this course version 0.12.14.
You might get these warnings but it's okay.
Alright so almost there.
Okay we got sales installed.
Globally now what we have to do is call on that command sales okay.
And then new and the name of your project.
So let's call this project sales like quick start sales dash quick start.
That's the project name right here.
So sales is going to generate the app.
You may ignore this thing too.
So sales is going to create a project directory with the same name as the project that he
specified.
This case sales dash quick start.
Alright we got it.
So it creates a new sales app called sales quick start.
If I list the files in my directory I have this directory here.
Let's cd to it sales quick start.
And here's the generated project.
So that's it for this lecture.
Next lecture we're going to go through those files and have an overview of the application
structure for a sales app.
Until then.


02 Installing Sails and Generating a Project

Overview of the Sails App Structure

# Sales.js Project Structure Overview

In this lecture, we explore the structure of a project generated by Sales.js 0.12, specifically the **Sales Quick Start** project created previously.

## Key Components of the Project Structure

1. **Root Directory**:
   - Contains `package.json`, defining it as a Node.js project.
   - **Entry Point**: `app.js` serves as the application's main entry file.
   - **Grunt File**: Used for asset management tasks.

2. **Directories**:
   - **API Directory**: Holds sub-directories for:
     - **Controllers**: Contains controller files.
     - **Models**: Contains model files.
     - **Services**: Includes helper methods and additional functionalities.
   - **Assets Directory**: Stores static files such as:
     - JavaScript files
     - Stylesheets
     - Images

3. **Tasks Directory**:
   - Contains files for Grunt tasks.

4. **Pipeline Configuration**:
   - `pipeline.js` is used to set up script injections into view files.

5. **Views Directory**:
   - Default template engine is EJS (can be changed to alternatives like Pug).
   - Contains:
     - `layout.ajs`: Main layout file.
     - Additional pages (e.g., `homepage.ajs`).
     - 404 and error templates.

6. **Configuration Directory**:
   - Holds files for:
     - Database configuration
     - Environment configuration
     - Middleware
     - Custom routes (`routes.js`)
     - Data sources (`connections.js`): Defines databases used (e.g., disk adapter for development).

7. **Environment-Specific Configurations**:
   - Located in `config/` for different environments (development, production, etc.). 
   - Allows selection of database types based on the running environment.

## Conclusion

This lecture provided an overview of the structure of a Sales.js application, highlighting the organization and purpose of each directory and file. The next session will delve deeper into implementation details. 

See you in the next lecture!

In this lecture we're going to look at the app structure for the project that is generated by sales 0.12.
So in the last lecture we created this project called Sales Quick Start.
And then here's the listing of all the files in this directory.
Let's switch to the Finder to see it visualizes better.
So sales is going to create a package.json because it is a node project.
Okay? And then the entry point for the application is this file called app.js.
Because sales uses Grants for some of its tasks related to asset management, there's a Grant file.
Now the directories. So we have an API directory that is going to contain directories for the controllers, models,
services and other stuff. Okay? Controller, model and other stuff like services.
We have this assets directory.
Assets directory is for like things like images, JavaScript files and style sheets.
We have JS, styles, okay? And images.
So we have this tasks directory is mostly for grunt tasks.
Okay? You can take a look if you want.
Now there's a file called pipeline.js.
That's where you're going to set up your pipeline to inject scripts in your Vio files.
Okay? This is not that useful if you were making an API only without the view.
All right?
And then we have the directory for the views.
And by default it uses EJS but you can change it to anything you'd like.
For example, Jade, which is now called pug and things like that.
All right? So layout.ajs is the layout and then you can inject a page like homepage.ajs in the layout.
And these are the 404 and other error pages, templates. All right?
So this is the structure of those sales application.
So let's open here the text editor.
In this case I'm using Adam.
So take a look at more closely at the most important parts.
So we already had an overview.
So mostly you want to see also the config directory I forgot to mention.
This directory here is where you're going to do all your configuration, database configuration, environment configuration, middleware, routes and so on.
So inside the configuration here there's this file called routes.js.
This is where you're going to set up your custom routes. All right?
config slash routes.js.
There's also this file called connections.js, very important.
So you can set your data sources here.
You can define what kind of databases to use.
By default it uses this what's called an adapter.
So sales has many adapters for different kinds of databases.
This is called the sales disk adapter and is meant for development only.
So it's a local disk database.
Okay, so config slash and is where you set up the environment specific configuration.
So typically here you can choose which connection to use.
For example, in development I could use just a local disk database,
but in production I would use some other database like my Am I a screw L or MongoDB or something else.
So you can change what kind of database depending on the environment using these files.
config slash and slash development, production or anything else.
You can just create a file here to define your own environment.
All right, it doesn't have to be that those environments.
So these are environment specific files.
And there's other files here that also has more configuration.
Now going back here, we had an overview and just going again to the API directory.
This is where you're going to see your controller directory where all your controllers are going to be.
API slash models where all your models are going to be.
If you need to set up services that is helper methods, you can put it in the services directory.
There are also other stuff like policies and responses.
All right, so this was an overview of the application structure of a sales.js file project.
See you in the next lecture.


03 Overview of the Sails App Structure

Lifting the Sails App

# Lecture Summary: Starting Up a Sales App

In this lecture, we learn how to start a sales application called **SalesQuickStart**. This app was generated using the command `SalesNew, SalesQuickStart`. The entry point for the app is the **app.js** file.

## Starting the Sales Server

1. **Lift the server**:
   - You can start the sales server by executing:
     ```bash
     node app.js
     ```
   - This starts the server in the development environment on port **1337**.

2. **Accessing the App**:
   - Once the server is running, you can visit:
     ```
     localhost:1337
     ```
   - This will display the home page, which uses **views/homepage.ejs** and **layout.ejs** for rendering.

## Other Methods to Start the Server

- You can also start the server using a script in **package.json**:
  - The script defined under "scripts" is **start**, which executes the command to lift the server.
  - Run it with:
    ```bash
    npm start
    ```

- To stop the server, use **Control+C** in the terminal.

- Alternatively, you can use the Sales command:
  ```bash
  sales lift
  ```
  
## Preferred Method

The preferred method for starting the server is using:
```bash
npm start
```
This ensures the application uses the Sales version specified in **package.json**, ensuring consistent behavior with the installed modules.

## Conclusion

You now have a sales server running. Until next time, goodbye!

In this lecture we're going to learn how to start up a sales app.
So we already have this sales app, SalesQuickStart, that was generated using SalesNew, SalesQuickStart,
remember?
So the entry point for the app is this file called app.js.
So you can simply say, nodeapp.js to lift the sales server.
Okay, so the sales server was lifted.
In sales they like to say lift, to mean it started.
So the server was lifted in the development environment with the part 1337.
It's like lead part anyway.
So now that the server is running, you can just go to localhost, localhost 1337.
And you're going to see this started page here.
You're looking at views slash homepage.ejs.
So this whole thing here is the layout.ejs and then they injected the views slash homepage.ejs.
So it tells you how to generate a REST API and all that stuff that we are going to do.
Okay?
Now there are other ways to lift the sales server.
So we did nodeapp.js, but if you look at the package.json, there's already that script
that calls nodeapp.js.
If you notice, go to package.json and notice there's under scripts, there's the start script
that does exactly what we did.
So you can also say npm start and that will call upon nodeapp.js.
All right?
To start.
So that's yet another way to, that's another way to lift the sales server.
Okay?
Now I can kill the server using control C in the terminal.
The signal to interrupt.
All right?
Now, to finalize just with yet another way of lifting the sales server.
Some people like calling the sales command sales followed by lift.
All right?
This way.
This also works.
Now the preferred way is I prefer calling the npm script.
That way it always uses the sales version that was defined in the package.json.
So my preferred way will always be this way, npm start.
All right?
This guy will make sure to use the sales version determined in the package.json because it's
already installed in the node modules and it's going to use the correct module instead
of the global one.
All right?
So that's it for this lecture.
You now have a sales server running and until the next time, bye.


04 Lifting the Sails App

Setting Up the Data Source in Sails

```markdown
# Quick Start Introduction to Sales - Building a RESTful API

## Overview
In this section, we will set up a RESTful API to serve information about companies, focusing on their name, founding date, and employee count. Before diving into the model, we will configure our database.

## Database Configuration

### Default Database
- **Default Database**: Sales uses a default local disk database with the Sales disk adapter.
- **Configuration File**: The database setup is managed in `config/connections.js`.

### Setting Up Connections
- **connections.js**: 
  - Configures various database connections.
  - The default connection is named `local disk db`, which can be altered as needed.
  - You can enable other databases (e.g., MySQL or MongoDB) by uncommenting specific lines and installing the appropriate adapters using npm.

#### Example of MySQL Setup:
- Uncomment the MySQL section in `connections.js`.
- Install MySQL adapter: 
  ```
  npm install --save sails-mysql
  ```
- Define the necessary connection parameters (host, user, password, database name).

### Default Connection in Models
- **Model Configuration**: The default database connection is specified in `config/models.js`.
- Even if the default is commented out, it defaults to `local disk db`.

### Migration Strategy
- **Migration Options**: Specify the migration strategy in `models.js`. This handles how data is managed when the server starts (e.g., creating new schemas, modifying existing data).

### Environment-Specific Configuration
- **Environment Configurations**: Go to `config/env` to set up database connections specific to different environments (development, production).
- Example: Under the development environment, specify which database connection to use.

## Summary
1. **Configure Connections**: Set up in `config/connections.js` with adapters for MySQL, MongoDB, etc.
2. **Set Default Connection**: Define in `config/models.js`.
3. **Define Migration Strategy**: Handle how data updates on server lift.
4. **Environment-Specific Config**: Specify different connections for dev and prod environments.

## Next Steps
In the next lecture, we will begin building our first model.
```


Welcome back to Quick Start Introduction to Sales.
So from now on, we want to start building our RESTful API.
So let's build an API that serves information about companies.
For example, a company has a name, has a founding date, and an employee account.
But before we jump into the model, let's get our database all set up.
By default, Sales is going to have a default database,
the so-called local disk, using the Sales disk adapter.
So let's take a look at those configuration files to get more
acquaintance with that database configuration.
So let's go to our project.
I'm going to open here my text editor.
So we're going to have a look at the directory called config.
So under config, we have this file called connections.js.
So connections.js is where you set up your connections,
that is the different types of databases.
In the case of the sales, by default, it's going to set up this connection called local disk db.
This is an arbitrary name that you can choose, and it's using what's called a sales adapter.
So sales adapter is going to take care of configuring database and setting it up, everything for you.
So all you have to provide is the database username and all that stuff.
But in the case for the local disk db, there's not much configuration going on.
All you have to say is which adapter you're going to use.
Okay, so this sets up this connection, local disk db, that's the name of this connection.
It's an arbitrary name.
We can have multiple connections, for example.
If you scroll down, there's this some MySQL server connection.
Comment it out, then you can uncomment if you want to set up a MySQL connection.
For example, in this case, if you want to set up MySQL, you would use the sales MySQL adapter.
Just as a reminder, you have to install this guy using npm install dash dash save sales and MySQL.
So you can see it's using the sales MySQL adapter.
Then you set up the connection using the host, user, password, and the name of the database.
So you can use any database you want.
There's also support for MongoDB using the sales Mongo adapter.
So you can set up some MongoDB server, that's the name of the connection.
So you can use MongoDB.
And it uses the sales Mongo adapter that you can use.
You can install using npm install sales Mongo and so on.
So you can have multiple connections that you can use.
Okay, postgres and others.
You can take a look here at the website for more information.
Now, once you have that connection set up, in this case, let's just use this local disk db.
We have to tell what's the default database of this application.
That's in the file called models.js.
So under the config directory slash models.js, you can say what's your app's default connection right here.
This case is commented out.
So in this case, it's going to be local disk db by default, even if it's commented out.
So this is where you set up which connection you want to use by default if it's not specified.
So you can choose which one you want to use by default.
Also in this same file, models.js, there's the migrate option.
We're going to have this...
Sales is going to ask us what kind of migration strategy we want to adopt once we create the models and we lift the server.
So if you keep commenting it out, it's going to complain about that unless you determine what kind of migration...
migration strategy you want to use.
Let's just leave it at that, but keep that in mind that you're going to have to change that later to adopt the safe choice for your production or development of different kind of environment.
You can add more information if you go to their documentation.
Anyway, so let's just remember that in the models.js, you can set your default connection and you can set the migration.
Okay, the migrate strategy.
Now, with that in mind, we can also have environment-specific configuration for what connection you want to use.
In that case, go to config slash end.
For example, under the development environment, you can determine what connection you want to use.
In this case, if I comment this out, it's using some MongoDB server.
It can be anything.
You can see my SQL connection or whatever you want to say.
All right.
So this guy is going to say, under the development environment, please use this connection.
So you can have different kinds of connections.
For example, in production, you might want to use some other kind of database.
You want to use MySQL or something else.
So you can have different kinds of databases for different kinds of environments.
Okay.
So let's wrap this up and once again, review the database configuration.
First, you go to config slash connections to set up your connections.
You can choose a sales adapter for your corresponding database type, MySQL, sales and MySQL, sales
Mongo, sales postgres, and so on.
And then you just set up the connection with the username, password, database name, host
board, and that kind of stuff.
Okay.
Once you got the connection set up, you can go to the models.js where you can specify the
default connection for everything if not specified.
And then you can also specify the migration.
How to handle the data when the server lifts.
Are you going to delete the database and start over?
Are you going to keep the records and build a new thing?
Are you going to alter the records, keep them as they are, and just add more data?
That kind of stuff.
All right.
And then you can set up specific environment configuration and config slash m slash the
name of your environment.
In this case, there are two environments already by default, development and production.
So you can say, I want to use this connection for production.
Oh, no.
I want to use this different auto-connection for development.
Okay.
With that in mind, this is it for this lecture.
In the next lecture, we're going to start building our first model.
See you then.


05 Setting Up the Data Source in Sails

Generating a Model and Controller in Sails

# Lecture Summary: Building a Company Model in Sales

In this lecture, we will create a model for a company using the Sales framework. The model will include the following attributes:

- **Name**: a string representing the company's name.
- **Founding Date**: a date type indicating when the company was established.
- **Employee Count**: an integer representing the number of employees in the company.

## Steps to Generate the Model and Controller

1. **Generate API**: Using the command line, we will execute the command:
   ```
   sales generate API company
   ```
   This command creates a model and a controller for the company resource.

2. **Check Project Structure**: The project will have the following structure under the `API` directory:
   - `controllers/companyController.js`
   - `models/company.js`

3. **Define the Schema**: In `models/company.js`, we will define the model's attributes as follows:
   ```javascript
   module.exports = {
     attributes: {
       name: {
         type: 'string'
       },
       foundingDate: {
         type: 'date'
       },
       employeeCount: {
         type: 'integer'
       }
     }
   };
   ```
   Here, we used Waterline ORM to map these attributes to the database.

4. **Verify the Controller**: The controller file `controllers/companyController.js` set up automatically handles RESTful routes using the Blueprint API, although no explicit code is shown in the file.

### Next Steps
In the next lecture, we will explore how to work with the data using the Blueprint API features generated by Sales.

In this lecture we're going to build our model for the company.
So say we have an API that serves information about a company.
So a company has a name which is a string.
Company also has a founding date, the date of establishment.
What is going to be a date type in sales?
Now we also have an employee count and that is going to be an integer data type for sales.
Alright, so we're going to generate a sales model along with a controller.
And then we're going to define the schema for this company type.
Okay, this company has a name, a founding date, and an employee count.
So sales is going to automatically figure out how to map this guy to the database.
In this case we're using the local disk database provided by sales by default.
So let's go to the command line and we're going to learn the command to generate a
model as well as a controller at the same time.
So we're going to say sales, okay, generate API and then you give the name of your resource.
For example, we're generating information about a company.
So I can just say company here.
Doesn't matter if it's lowercase or uppercase for the first letter here.
So this guy is going to generate what it's called an API in sales.
Basically it's just going to generate a controller file and a model file.
So let's take a look at the app structure here.
I'm going to my text editor for the project.
So let's look at the directory called API.
Under API we have the controllers directory and the models directory.
So let's look at models here.
So you see it created a model file company.js.
But knows also that it created a controller for that model.
So we have company controller.js under the controllers directory too.
So it automatically creates both the model and the controller when you say sales generate
API resource name.
So with that in mind, let's go to the model file.
API slash model slash company dot j s.
So we have a model dot exports that exports the whole module.
So the whole module is essentially an object.
And this object has a property called attributes.
Attributes in turn is an object.
So here inside attributes, we are going to define each field for this resource.
So a company has a name.
So what we do is we type name.
And then we give an object as a value.
Okay and then we say the type.
In this case, name is going to be a string.
So we write it like so.
This is a sales way of writing the schema.
Okay.
Sales uses the waterline ORM to map this schema to the database.
So it's called waterline ORM.
So we got the name attribute of type string.
Now let's get the other ones.
The other ones is founding date and employee count.
So let's do it.
Founding date is going to be a date, the date of establishment of this company.
So the founding date is going to be of type date.
Simply like that.
Okay.
Now let's do the employee count.
Employee count.
Well the employee count is just going to be an integer.
So we can say type integer this way.
And just like that, sales is going to know how to map these attributes for the company
resource to the database.
Okay.
So now we got our company model set up.
The next step is see if this is actually working.
So sales, as we saw before, generates also a controller called company controller.
If you click the file api slash controller slash company controller dot js, you see there's
a module that exports assigned to.
There's an object assigned to the module, but there's nothing inside.
Actually there is something, but sales does it behind the scenes.
So sales already made a RESTful API for you.
You don't see anything here, but by default sales creates a RESTful API.
It's RESTful routes using what's called the blueprint API.
So that's the topic of the next lecture.
We're going to learn how to work with this data using the blueprint API.
See you then.


06 Generating a Model and Controller in Sails

Sails RESTful Controller Actions

```markdown
# Lecture Summary: Sales Blueprint API and RESTful Routes

In the previous lecture, we focused on creating a model and setting up its schema. This lecture will cover the **Sales Blueprint API** and how it generates **RESTful Routes** for our resource, specifically the **Company** resource.

## Overview of Company Resource
- The Company resource model includes:
  - Name
  - Founding date
  - Employee count

## Automatic Controller Generation
Using the command `SalesGenerateApi`, Sales automatically creates a controller for the Company resource. Initially, the controller file contains an empty module. Behind the scenes, several RESTful controller actions are created that map to each HTTP request type:

### Actions Mapped to HTTP Requests
- **GET /companies**: Retrieves all companies (`find` action)
- **GET /companies/:id**: Retrieves a specific company (`findOne` action)
- **POST /companies**: Creates a new company (`create` action)
- **PUT /companies/:id**: Updates an existing company (`update` action)
- **DELETE /companies/:id**: Deletes a company (`destroy` action)
- **Additional Actions**: There is a `populate` action; refer to documentation for details.

### Code Visibility
Although these actions are generated automatically, they are not explicitly defined in the code. The controller file for the company (located at `API/controllers/companyController`) appears empty.

## Visualization of API Functionality
To visualize and test the generated actions, we will make HTTP calls using a REST client. It is recommended to use **Postman**, a versatile tool for making API requests. 

### Getting Started with Postman
- Download and install Postman from [GetPostman.com](https://www.getpostman.com).
- After installation, we will explore the automatically generated API in our Sales app.

## Next Steps
In the upcoming lecture, we will perform operations such as:
- Creating new companies
- Listing all companies
- Retrieving specific companies
- Updating a company
- Deleting a company

Stay tuned for the practical application of these concepts!

For more information, check out the GitHub Gist by visiting: [gist.github.com/NVKhold](https://gist.github.com/NVKhold/salesblueprintrest.md)
```


In the last lecture, we learned how to create a model and how to set up its schema.
This lecture is going to be about the Sales Blueprint API and how it automatically generates
RESTful Routes for our resource.
So the resource in question is Company.
So we created a model for a company resource that has a name, founding date, and employee
count.
Now Sales automatically creates a controller for us, as we saw using the command SalesGenerateApi.
Now the control file didn't have anything in it, just a module that exports with an
empty object.
Now Sales behind the scenes actually creates several controller actions for us, RESTful
Controller Actions that already map to each HTTP request type.
For example, here's a list that I have that I made a GitHub Gist with this list.
If you want to access by the way, you can go to NVKhold slash salesblueprintrest.md.
It's available at gist.github.com slash NVKhold, my username, if you want to take a look.
Anyway, let's keep on going.
So for example, if you want to get all the companies, that would be a RESTfulRout like
get slash the resource.
So Sales is going to automatically create the resource controller dot find action that
already has that logic to retrieve that resource and give back a list of all the resources.
Similarly, if you want a specific resource, a get slash resource slash its ID, that is
going to be under the find one controller action that's already implemented by the blueprint
API from Sales and so on.
You can do post to create a new resource and that maps to the create action of the controller.
To update, you can do put and that maps to the update action.
For deletion, you can, it maps the destroy action.
And there's also another one called populate that if you want to know more about, check
the documentation.
So the thing is, you don't really see these guys being defined in the code.
If you go back to the code, this is company controller under API slash controllers slash
company controller.
And there's nothing here.
So that's one thing about sales is that's things for you, but you can't really see it
here.
So in order for us to be able to visualize what's going on here and to see that it's
really working behind the scenes, we are going to make all these HTTP HTTP calls and see
the resources to create the resources and so on.
For that, we're going to need a REST client.
Okay.
And sales has something that allows you to create and update and change records all using
the same using a get request.
I'm not going to use that because I don't think that's proper RESTful.
It's not using the proper way of calling an API.
So I'm going to use a REST client and make the appropriate calls with the right verbs
and so on.
So for that, we're going to need a REST client.
I recommend you use postman.
Okay.
So postman now is an app by itself used to be a Chrome.
It still is, but it's going to become obsolete because Chrome apps are going to be obsolete.
But you can get the app in a getpostman.com, www.getpostman.com.
And you can download for your platform.
And after installing it, we're going to start looking at that API that's automatically generated
in our sales app by the blueprint API.
We're going to play around and we're going to create some companies.
We're going to list all the companies, list the specific companies, update a company,
delete a company, all that stuff coming up in the next lecture.


07 Sails RESTful Controller Actions

Setting Up the Migrate Strategy in Sails

# Summary of Lecture on RESTful Routes with Postman

In this lecture, the instructor discusses the RESTful routes provided by the Sales framework using the Blueprint API, specifically focusing on using Postman as a REST client for API testing.

## Key Points Covered

- **Using Postman**:  
  The instructor demonstrates how to use Postman for testing RESTful routes, reminding users that they can skip account creation if they prefer not to sign up.

- **Setting Up Server**:  
  The application runs on `http://localhost:1337`. Before testing, it's essential to ensure that the server is running. The command `npm start` is used to start the server.

- **Migration Strategy in Models**:  
  The lecture highlights the importance of defining a migration strategy in the `config/models.js` file. Three strategies are discussed:
  1. **Save**: Never auto-migrate the database. This is recommended for production to avoid data loss.
  2. **Alter**: Auto-migrate changes to the schema while preserving existing data. This is suitable for development.
  3. **Drop**: Drops all data and rebuilds everything from scratch. This should be used with caution.

- **Setting Migration Strategy**:  
  The instructor emphasizes defining the migration strategy directly in the `models.js` file to avoid being prompted each time the server restarts. They recommend using "Alter" for development purposes, while "Save" should be the go-to for production.

- **Conclusion**:  
  After configuring the migration strategy and starting the server again, the instructor confirms everything is set up, indicating readiness to interact with the API.

This session prepares the audience for further interaction with the API by ensuring their environment is correctly configured.

Hello everybody in this lecture we're going to look at the RESTful routes
automatically provided by sales from the blueprint API. We're gonna use Postman.
You can use any RESTful REST client that you'd like. In my case I'm gonna use
Postman. So I already installed Postman and I'm gonna open up. If you're using
Postman the first time you opened up you if you don't have an account you can
just say skip it. I don't want to create an account at this time kind of thing if
you don't want to create one. Anyway here we are I'm gonna close this and
clear everything here. I don't want this and take this out. Just I hit the sidebar.
Chrome apps are being deprecated as we mentioned before so we're using the
Postman app. Let's go. So we have a resource called company remember. So the
app is gonna be running at HTTP localhost at the part 1337. So let's make
sure we have the server running. So I'm gonna go to my terminal and I already
had my server running. If you want to run a server again you can again type
npm start and the server should run. So because we added a model we are gonna
have this warning here. So let me make this bigger so you can see. So as I
mentioned before this is about the migrate strategy. We did not specify in
the models.js file remember config slash models.js had a migrate configuration
thing. So because we created a model now sales is asking hey how do you want me
to deal with the tables in the database and all that stuff. So it has three
strategies for migrate. So the first one is save. So never auto migrate my
databases. I will do it myself. Basically this is the choice you want to choose
for production. That is don't do anything with the database keep it as it is don't
matter with it. Now have source number two alter. Auto migrate. So if you change
something in schema and you know change the table schema some resource schema and
if you choose this strategy it's going to try to auto migrate and keep the
existing data and they see it's experimental or you can have a migrate
strategy number three which is drop. So it's going to drop all the data and
rebuild everything from scratch. So be careful if you use this one it's going to
drop everything. All your data is going to be gone. Alright so in summary you want
to use one. Save always for production. Don't change anything to database. If you
are in development you can try using alter if you're always changing your
stuff. Alright so let's go with alter. So we're doing development. Oh let's try
again. NPM start. And press 2. Okay so I didn't choose anything and they
automatically choose migrate safe. Okay so
let's try again. I'll try alter. There we go. But notice that every time I rerun
restart a server I have to state which migrate you want to use. So that's kind
of annoying. So that's why we have to set it up in that file models.js. So let's
go back to the text editor here and let's go to config slash models.js.
Okay so in the models.js file all the way down here we have this migrate here.
So let's uncomment this out. So we're going to say explicitly this is my
great strategy I want to use. In this case it's using alter. Remember use safe
for production. So because we're doing development I'm going to use alter. Alright
but keep that in mind. Don't forget use safe for production. Okay I'm going to
save it and next time we run sales we left the server. It's no longer going to
ask us what migration you want to use because we have explicitly stated now
that we want to use this migrate strategy. Alright so let's go with alter and go
back to the terminal let's clear this and do npm start again. Okay no prompt
good very good. So that's it we got the server running. Now we can finally start
playing around with our API.


08 Setting Up the Migrate Strategy in Sails

Using Postman to Test the Sails Blueprint API

# Postman API Request Summary

## Overview
In this session, we explored how to use Postman to interact with a RESTful API for managing a "Company" resource on a local server running at port 1337.

## Key Steps

1. **Default Resource Name**:
   - The default resource name used in this example is singular ("Company"), but it can be changed to plural if needed.

2. **GET Request**:
   - Performing a `GET /company` request returns a list of all companies. Initially, the list is empty since no records exist.

3. **Creating a Company**:
   - We switched from a `GET` request to a `POST` request to create a new company record.
   - In the request body, we selected `raw` format and set the data type to `JSON`.

4. **JSON Data Format**:
   - Constructed the JSON object for the company with the following attributes:
     - `"name"`: `"App. blah, blah"`
     - `"foundingDate"`: `"1980-04-11"` (formatted as `YYYY-MM-DD`)
     - `"employeeCount"`: `483`
   - Important to note: No comma after the last property in JSON.

5. **Sending the Request**:
   - After composing the JSON, we clicked on the "send" button. 
   - The API provided a response with a `201 Created` status, indicating successful entry in the database.

6. **Response Verification**:
   - The response JSON confirmed that the company record was created, providing:
     - An `ID` (e.g., `1`)
     - Timestamps for creation and last updated (in ISO format)

7. **Automatic Properties**:
   - Notably, we did not need to specify `ID` or timestamp properties in the model; the API handles this by default.

## Next Steps
- In the following lecture, we will explore additional routes and request types to further interact with the API. 

Feel free to reach out with any questions about the ISO format or the JSON structure used!

So let's go back to Postman.
So we got our local host at the part 1337.
So we created a resource called Company.
So by default, Sales uses a singular resource name.
All right?
It can be changed to Plural.
All right?
But let's go with the singular for now.
So if you say about get slash company, that should give you a list of all the companies.
So we got an empty list, as you can see, because we don't have any record, obviously.
Now let's create a company record.
So let's switch from get to a post request.
Now here in the post request, we want to send some data.
So let's go to the body tab, and let's choose no, not form data, but let's choose raw.
And let's switch from text to JSON.
OK?
So we're dealing with JSON, JSON RESTful API.
Let's go JSON all the way.
So for the body of the post request, raw JSON.
So let's make a JSON here, open braces, and let's write, let's create a code.
Create a company.
So a company has a name.
Let's say the name.
I don't know.
App.
App.
Blah, blah.
Note that we're using JSON, so make sure you have the double quotes for the property.
We're using JSON, so we need that.
A company also has a founding date.
So for the format for the date, sales understands the format, the double digit year followed
by a dash, double digit month followed by a dash, double digit day.
So let's say a company has found in the year of 1980.
And a certain company, the month was April, and the day was 11.
So this format is accepted.
The sales will understand this format for the date.
And now a company also has in our example employee count.
And that's just an answer.
Let's say it has, I don't know, 483 employees.
Notice that I'm using JSON, so if you are used to typing commas all the time for property
objects, don't type one here because JSON, this is not valid JSON, so no commas there
for the last property.
So with that in mind, we're going to create this company called Apple, blah, blah, founded
in 1980, April 11th, 483 employees.
So let's click send and see what happens.
So down here, I got my response.
If I scroll down, so this is the response from sales.
It gave me a status 201 created.
And if I try to zoom in here for you to see better, here's the response, JSON response.
So notice it created my record with the information I provided, as well as now it has an ID number
1, because it's now in the database, in this case, local disk database.
And notice that sales by default also adds this created ad and updated ad timestamp
properties.
So notice the format here is always a date followed by time, no matter what.
So this is the format that sales uses.
I think this is called the ISO format.
Correct me if I'm wrong.
Please live in the post, comment if you know about this format.
Anyway, so sales created a record for us, a company record.
It assigned an ID and it started in the database and also created by default these timestamp
properties.
So notice we did not have to specify in the model, if we go back to the API slash model
slash company, we did not specify ID, and we did not specify those created ad and updated
ad timestamps.
So sales does it by default.
So you automatically get those things.
All right.
So going back to postman.
So there you go.
That's the response from sales.
So this is it for this lecture.
Next lecture, we're going to learn more about the other routes and the other requests.
Let's play more around, play more with these requests and see you then.


09 Using Postman to Test the Sails Blueprint API

Create, Update, and Delete Using Sails Blueprint API

# Summary of the Transcript

In this session, we explored the functionalities of a company management API using HTTP requests. Here's a breakdown of the key actions performed:

## 1. Retrieve All Companies
- **Action**: Changed the request from `POST` to `GET` using the endpoint `/company`.
- **Outcome**: Received a JSON array containing the records of all companies, confirming the route is working correctly.

## 2. Retrieve a Specific Company
- **Action**: Used the endpoint `/company/1` to fetch information about the company with ID 1.
- **Outcome**: Successfully received the specific company object, confirming the `find one` controller action is functioning.

## 3. Create a New Company
- **Action**: Sent a `POST` request to `/companies` with JSON body to create a new company named "googly", founded in June 1997 with 700 employees.
- **Outcome**: The company record was created, and the response included the new ID (2). This mapping corresponds to the `create` controller action.

## 4. Retrieve All Companies Again
- **Action**: Executed another `GET` request to `/companies`.
- **Outcome**: Confirmed that there are now two company records in the system.

## 5. Update a Company
- **Action**: Changed the request type to `PUT` and updated the name from "Google" to "Google U", and modified the employee count to 707.
- **Outcome**: Successfully updated the record, returning the modified object.

## 6. Attempt to Use PATCH Method
- **Action**: Tested `PATCH` to update just the founding date of "Google U".
- **Outcome**: It did not work as expected because the API does not seem to support `PATCH`, resulting in a 404 error. Reverting to `PUT` worked correctly for updates.

## 7. Delete a Company
- **Action**: Sent a `DELETE` request to `/company/2` to remove "Google U".
- **Outcome**: The company was successfully deleted with a 200 OK response. A subsequent `GET` request confirmed that the record no longer exists, showing only the remaining companies.

## Conclusion
We successfully demonstrated various HTTP methods (GET, POST, PUT, DELETE) to manage company records through the API. For more information about the limitations and functionalities, referring to the API documentation is recommended.

So now that we have a company, let's try and get a list of all the companies like we did before.
Before we got an empty list, right?
So we expect now to have one record inside of this.
So let's go back here and switch from a post request to a get request, keeping the same URL, slash company.
So we expect to get a list of all the companies in the system right now.
So let's click send and see what we get.
So you can see the response right here.
It's an array of objects, JSON response that has that company that we created.
So indeed this route is working.
So this is the route that maps to the controller action called find.
All right, that finds all the records for this specific resource.
Now, if I wanted to get just information about this company here, you can say company slash the company ID.
So the company ID here is one.
So if I just want to get information about the company, whose ID is one, I can do it like so.
So we do a get slash company slash one, which is the ID.
So let's see what we get.
So as you can see, we get an object.
So this case gives you the specific object, the specific company information.
Okay, so this maps to the controller action find one.
Okay, we're doing a get slash resource slash resource ID, which maps to the controller action find one.
Okay, so how about we create another company?
Let's do a post request.
Let's change the URL back to slash companies slash company only.
And let's say let's go to the body of the post request.
If you can see here body, go back there and raw JSON again.
Let's create another company.
Let's say googly, something like that.
Let's say founded in some 1997, the month, let's say June 23 employee count, let's say has 700.
And let's create this record, let's click send.
And we're going to get scroll down to see the response.
So we create a new record.
So this post request post slash resource maps to the controller action create.
Okay, controller action is create.
And as we saw before, it's going to create the record with the data we provided, and it's going to add those time stamps, created at and updated at automatically for you.
You don't have to specify this in the schema.
And also obviously the ID, which now is number two.
So with that in mind, let's again get a listing of all the companies.
Let's go and switch to get request again.
And let's click send.
Now if you take a look at the response now we have another company there.
Now we have a list of two companies because we created another one.
As you can see now two records.
Okay.
So we learned how to create a record.
We learned how to fetch all the records and how to fetch a specific record.
Like if you want to get Google you can say slash two and you're going to get it.
Now let's learn how to update a record.
So we're going to switch from a get to a put.
Now we're going to go here and update this Google I don't like the name I'm going to change to something else.
So let's go into the body of this put request instead of Google.
Let's put Google you whatever.
If you want to change your play count to 707.
So let's see what we get.
Remember that before I had the name Google I with employee count of 700.
So let's see if we can update this resource and change its name and the employee count.
Let's click send.
Let's see the response scroll down.
Now you can see the response gives you back the object the record with the updated properties already there.
The name has been changed to Google you and the employee count to OK.
So that's how you update other record.
Now note that patch is also going to work.
So if you try to patch something for example let's remove from the body to name and the employee count.
I just want to change the founding date for company number two which is Google you.
Let's change the founding date to 2003 and let's keep the same month and day.
So it's going to work the same way.
So we can click send and let's see what we get.
Scroll down.
We expect 404 now it found what happened.
Seems like the patch actually does not work.
So the blueprint API does not provide a patch it seems.
Well that's too bad.
So we're going to stuck with the put.
So let's click send.
Let's see what we get.
So we got the Google you with the founding date 2003 and employee count as before.
So seems like that sales for the blueprint API also parts of the put and it's doing the same job as patch because we only passed one property to be updated instead of the whole original object.
All right.
So there's that detail for sales blueprint API.
If you want to learn more about that take a look at the blueprint API documentation.
All right.
Now let's keep on going.
See that's the 2003 that we changed and learn the final.
The last verb we're going to do is delete.
So say I don't like Google or anymore and I want to delete it.
You can do so delete slash company slash the ID of the company you want to delete.
So we're going to delete company to goodbye Google.
So let's do a delete and click send.
So we got 200.
Okay.
So this is the record.
Did they really get updated.
Let's take a look.
Let's go and switch to a get.
And let's click send.
So this is what we get.
No record found with the specified ID.
So it really got deleted from the list from the database.
So let's take a look at all the companies.
I changed the URL removed the ID.
Click send.
And now only Apple blah blah is there.
So indeed it deleted it.
So that's the sales blueprint API.


10 Create, Update, and Delete Using Sails Blueprint API

Review of Sails Blueprint REST Routes and Controller Actions

# Summary of Transcript

In this lecture, the speaker provides a review of the routes offered by the Blueprint API, referring to a gist hosted on GitHub for reference. Here’s a breakdown of key points discussed:

## Key Learning Points

1. **Resources Overview**:
   - The API allows access to specific lists of resources which map to the `find` controller action.
   - Access to individual resources maps to the `findOne` controller action.

2. **Creating Resources**:
   - Use `POST /resource` to create a resource, which maps to the `create` controller action.
   - The controller file will appear empty, yet actions are generated behind the scenes by the Blueprint API.

3. **Updating Resources**:
   - Use `PUT` to update a resource, corresponding to the `update` controller action.

4. **Deleting Resources**:
   - Use `DELETE /resource/:id` to remove a resource, related to the `destroy` controller action.

5. **Customizing Controller Actions**:
   - If customization is needed, you can explicitly define these actions in the controller file to override the default Blueprint API behavior.
   - An example was provided on how to redefine the `create` action in the company controller.

## Conclusion

The lecture concluded with an affirmation of the learned materials about Blueprint REST routes and controller actions, inviting viewers to continue their learning journey. 

See you next time!

Let's do a quick review about the routes it provides.
Going back to my gist here in git hub.
By the way, again, if you want to take a look at this gist, you can go to my gist profiles
nbkhope gist.github.com.nbkhope and you can click sales, blueprint, rest.
And here are the ones we learned.
We learned these guys here.
So we learned how to get a specific list of resources and that maps to the fine controller
action.
We learned how to get a specific resource and that maps to the fine one controller
action.
So we learned how to create a resource using pulse slash resource, which maps to the controller.createAction.
So these actions are all automatically generated by the blueprint API and you will not see them
written explicitly in the controller file.
The controller file is going to be empty as we can see if you go to API slash controller
slash company controller.
You can see there's nothing there, but actually there's something going on behind the scenes.
And for the to update a resource using put, you can which is mapped to the update controller
action.
Then finally we saw that you can also delete a resource at slash resource slash its ID
and it maps to the destroy controller action.
So these control actions are all provided by the blueprint API.
If you want to override them and change customize them, you can always do so just define these
actions in the controller file.
For example, just a brief example, if you would like to change the behavior of the controller
action.
So if you did a pulse slash resource and it's going to go to controller set dot create,
but you don't want it to go through the blueprint API.
So you can override that if you go to the editor and you can define here create in the
company control file, okay, and define your controller as so and that is going to automatically
override and it's going to use your definition instead of the behind the scenes definition.
Okay.
So just that.
So this is it.
That's it for this lecture.
We learned about the blueprint rest routes, the controller actions and see you next time.
Bye.
