Merge pull request #4 from ReCoded-Org/crud-and-data-models

Module 3: CRUD and data models

Author: Shrreya

module3-crud-and-data-models/README.md

@@ -1 +1 @@
-# curriculum-backend-readings
+# Module 3: CRUD and Data Models

module3-crud-and-data-models/assets/relationalDBmeme.png

@@ -0,0 +1,224 @@
+# Introduction To Database Schemas
+
+A database schema is a blueprint or architecture of how our data will look. It doesn’t hold data itself, but instead describes the shape and structure of the data and how it might be related to other data.
+
+For example, this is a `customer` schema in MongoDB using Mongoose.
+
+```js
+const mongoose = require("mongoose");
+
+const customer = new mongoose.Schema({
+  name: {
+    type: String,
+    required: true,
+  },
+  zipcode: {
+    type: Number,
+  },
+});
+
+module.exports = mongoose.model("customer", customer);
+```
+
+The same `customer` schema in PostgreSQL using [Sequelize](https://sequelize.org/).
+
+```js
+const Sequelize = require("sequelize");
+
+module.exports = (sequelize, DataTypes) => {
+  const Customer = sequelize.define("customer", {
+    name: {
+      type: DataTypes.STRING,
+      allowNull: false,
+    },
+    zipcode: {
+      type: DataTypes.INTEGER,
+    },
+  });
+  return Customer;
+};
+```
+
+We can see that the schema definition for the `customer` has a `name` that is type `string` and a `zipcode` that is of type `number`. The `name` field is mandatory and cannot be empty.
+
+Another concept that can be confused with the database schema is the "Model".
+Models are fancy constructors compiled from schema definitions. An instance of a model is called a document. Models are responsible for creating and reading documents from the underlying MongoDB database.
+
+## Introduction to CRUD operations
+
+When we are building APIs, we want our models to provide four basic types of functionality. The model must be able to Create, Read, Update, and Delete resources. Computer scientists often refer to these functions by the acronym CRUD. A model should have the ability to perform at most these four functions in order to be complete.
+
+### CRUD in REST
+
+In a REST environment, CRUD often corresponds to the [HTTP request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods) `POST`, `GET`, `PUT`, and `DELETE`, respectively. These are the fundamental elements of a persistent storage system.
+
+For example, imagine we are working with a system that is keeping track of meals and their corresponding prices for a restaurant. Let’s look at how we would implement CRUD operations.
+
+First of all, we need to define our food item schema (we will use mongoose for that), and let's call it "dish".
+
+```js
+const mongoose = require("mongoose");
+
+const dish = new mongoose.Schema({
+  title: {
+    type: String,
+    required: true,
+  },
+  image: {
+    type: String,
+    required: true,
+  },
+  tags: [String],
+});
+
+module.exports = mongoose.model("dish", dish);
+```
+
+#### Create
+
+To create resources in a REST environment, we most commonly use the HTTP POST method. POST creates a new resource of the specified resource type.
+Imagine that we are adding a new food item to the stored list of dishes for this restaurant, and the dish objects are stored in a dishes resource.
+
+Note: Use `POST` when you want to add a child resource under resources collection.
+
+Request:
+
+`POST http://www.myrestaurant.com/api/dishes/`
+
+We will need to send the dish data too as an object in the body.
+
+For example
+
+```js
+{
+  title: "Lasagna",
+  image: "www.food.com/lasagna.jpg",
+  tags: ["simple", "classic"]
+}
+
+```
+
+On the backend side, our express route will be
+
+```js
+router.post("/dishes", async (req, res) => {
+  // get the data we sent in the body
+  const dishData = req.body;
+  try {
+    // using the create() method with Mongoose will insert the data we sent in the body to our MongoDB database
+    // and return an object of that data when done
+    const newDish = await DishModel.create(dishData);
+    // then, we return the new created dish object
+    res.status(201).json(newDish);
+  } catch (err) {
+    res.status(422).json({ message: err.message });
+  }
+});
+})
+```
+
+#### Read
+
+To read resources in a REST environment, we use the GET method. In practice, reading a resource shouldn't change any information - it should only retrieve it.
+
+To read resources in a REST environment, we use the GET method. Reading a resource should never change any information - it should only retrieve it. REST itself is more like a set of guidelines. Technically, you can change data in a `GET` request, but since we are creating a RESTful API, you shouldn't do that. Having a GET request that updates data in your database would be confusing to the users of your API and violate the expected behavior of REST.
+
+Request:
+
+`GET http://www.myrestaurant.com/api/dishes/`
+
+The express route for getting all dished will be
+
+```js
+router.get("/dishes", async (_, res) => {
+  // here, we are using the find() to return all dishes from our MongoDB database
+  // find() will return an array of dish objects
+  const posts = await DishModel.find();
+  res.json(posts);
+});
+```
+
+#### Update
+
+PUT is the HTTP method used for the CRUD operation, Update.
+So if the price of Avocado Toast has gone up, we should go into the database and update that information using PUT.
+
+Note: Use `PUT` when you want to modify a singular resource which is already a part of resources collection. `PUT` replaces the resource with the data you send in its entirety.
+
+Request:
+
+`PUT http://www.myrestaurant.com/dishes/:id`
+
+We will need to send the new dish data too as an object.
+
+For example
+
+```js
+{
+  title: "New dish title",
+  image: "www.food.com/dish.jpg",
+  tags: ["simple", "classic"]
+}
+```
+
+Note that when using Mongoose you don't have to send all the object fields, you can only send the ones that got changed.
+
+For example, we can only send the title.
+
+```js
+{
+  title: "New dish title",
+}
+```
+
+Respectively, our express route for both these examples will be
+
+```js
+router.put("/dishes/:id", async (req, res) => {
+  // we need the dish id in order to tell Mongoose which dish to update in our database
+  const { id } = req.params;
+  try {
+    // the findByIdAndUpdate() will make sure the dish exist before updating it
+    const updatedDish = await DishModel.findByIdAndUpdate(id, req.body, {
+      // the { new: true } here is just to tell Mongoose we want the newely updated dish back
+      new: true,
+    });
+    // we return the updated dish as a JSON object to the user
+    res.json(updatedDish);
+  } catch (err) {
+    res.status(422).json({ message: err.message });
+  }
+});
+```
+
+#### Delete
+
+The CRUD operation Delete corresponds to the HTTP method DELETE. It is used to remove a resource from the system.
+Let’s say that the world avocado shortage has reached a critical point, and we can no longer afford to serve this modern delicacy at all. We should go into the database and delete the item that corresponds to **Avocado Toast**, which we know has an `id` of 1223.
+
+Request:
+
+`DELETE http://www.myrestaurant.com/dishes/:id`
+
+The express route for this deleting request can be
+
+```js
+router.delete("/dishes/:id", async (req, res) => {
+  const { id } = req.params;
+  try {
+    const dish = await PostModel.findByIdAndDelete(id);
+    // the status code is 204 because we are not returning data or entities
+    return res.status(204).json({ success: true });
+  } catch (err) {
+    res.status(422).json({ message: err.message });
+  }
+});
+```
+
+---
+
+## References
+
+- https://restfulapi.net/
+- https://www.educative.io/blog/crud-operations#what
+- https://www.educative.io/blog/what-are-database-schemas-examples#types

module3-crud-and-data-models/r1-schema-and-data-models/README.md

@@ -0,0 +1,67 @@
+# Principles Of Setting up Your Schema
+
+Poorly designed databases can cause many problems, including wasting resources, making maintenance difficult, and hindering performance. That's why having a great database schema design is a crucial part of effective data management.
+By defining categories of data and relationships between those categories, database schema design makes data much easier to retrieve, consume, manipulate, and interpret.
+Without a clean, efficient, consistent database schema, you’ll struggle to make the best use of your enterprise data. For example, the same data might be duplicated in multiple locations—or even worse, might be inconsistent between these locations.
+
+## Type of database
+
+Most developers don't see the difference between relational database schema and MongoDB schema, but in reality, it is not the same
+
+<img src="../assets/relationalDBmeme.png" alt="meme" width="400"/>
+
+In a nutshell, in relational databases, models are usually independent of queries, there is no duplication of data as data will _mostly_ be separated into different tables, and it is rigid, you will have to define types and fields for your schema beforehand.
+
+In the other hand, `MongoDB`, you have more flexibility, there are no rules, documents can have new data or fields at any point of time, no need to define types.
+
+### Embedding vs. Referencing
+
+One of the key points to establish a good schema design (especially, if you are using MongoDB) is whether to embed or reference your data.
+
+#### Embedding
+
+When a collection has a document, and, this document contains another document, another document contains another sub-document, and so on. This is called embedding or nesting.
+
+#### When to Embed
+
+- To retrive all data in a single query.
+- Avoid expense JOINs or $lookups.
+- Update all data with a single operation.
+- In one-to-one or one-to-many relationships between documents.
+
+#### Referencing
+
+When a value of a field in your table or collection referes to a value of another field in another table or collection.
+
+#### When to Reference
+
+- If you need smaller documents or tables, your data will be separated across multiple documents or tables.
+- No duplicate of data.
+- To reduce accessed data not accessed on every query.
+- In many-to-many relationships between tables and documents.
+
+In general, there are few **rules** you can follow to better design your schema:
+
+##### 1. Favor embedding over referencing unless there is a compelling reason not to.
+
+Embedded documents are an efficient and clean way to store related data, especially data that's regularly accessed together. The more often a given workload can retrieve a single document and have all the data it needs, the more consistently high-performance your application will be.
+
+##### 2. Needing to access an object on its own is a compelling reason not to embed.
+
+Separate data that can be referred to from multiple places into its own collection.
+This is not so much a "storage space" issue as it is a "data consistency" issue. If many records will refer to the same data it is more efficient and less error prone to update a single record and keep references to it in other places.
+
+##### 3. Avoid JOINs and $lookups if they can be avoided, but don't be afraid if they can provide a better schema design.
+
+Having a JOIN or `$lookup` means you are doing some kind of search in your database for the corresponding field and that operation takes time. So if you embed your data in a single object, you will spare this operation, and your query can be much faster and cleaner.
+
+##### 4. How you model your data depends _entirely_ on your particular application's data access patterns.
+
+This means that no matter what you read or watch, you may still need to make few changes to your schema based on your own use case and application.
+
+---
+
+## References
+
+- https://www.mongodb.com/developer/article/mongodb-schema-design-best-practices/
+- https://www.xplenty.com/blog/complete-guide-to-database-schema-design-guide/

module3-crud-and-data-models/r1.1-principles-of-setting-up-your-schema/README.md

@@ -0,0 +1,96 @@
+# Model View Controller (MVC)
+
+## Introduction to MVC projects
+
+When beginning a new project (especially, when using Express), there are several different methods that can be used to set up the overall file structure and flow. One of the most commonly used architectural patterns is called MVC. This acronym stands for "Model, View, Controller".
+This pattern is favored because of its alignment with the computer science design principle, [**separation of concerns**](https://en.wikipedia.org/wiki/Separation_of_concerns). By dividing up responsibilities within our file structure, for example, we can have our db connection work in one file and api routes in another file, ...etc.
+
+```
+app-name-here
+ |- Controllers
+ |- db
+ |- Models
+ |- node_modules
+.gitignore
+index.js
+package.json
+package-lock.json
+```
+
+### Components Of MVC
+
+**Model:** This consists of the structure of our data and handle the database.
+
+**View:** The part of our application which is shown to the user.
+
+**Controller:** Controller has all the logic to control and respond to the action, the user performs using the views.
+
+### Models
+
+In this folder, you can write the functionality & logics related to the database (if you aren't using ORM) like insert, fetch, update, delete queries. It takes the query request from the controller & sends the response back to the controller.
+The naming convention for the model files is: `name-here-model.js`.
+
+Here’s an example model using JavaScript and Mongoose.
+
+```js
+// post-model.js
+
+const mongoose = require("mongoose");
+
+const post = new mongoose.Schema({
+  title: {
+    type: String,
+    required: true,
+  },
+  body: {
+    type: String,
+    required: true,
+  },
+  createdAt: {
+    type: Date(),
+  },
+  author: {
+    type: String,
+    required: true,
+  },
+});
+
+module.exports = mongoose.model("Post", post);
+```
+
+### Views
+
+In this folder, you can write HTML code for displaying a web page on the web browser. You can send the data from the controller to view for displaying data dynamically.
+In a back-end application, views are usually not implemented and rather we create a front-end app using maybe `React` to call our `api` end-points to manipulate and dispaly the data in the back-end.
+
+### Controllers
+
+Controllers are the layer between the Model and the View. the views can use the controllers to `add`, `read`, `delete`, ...etc data.
+In controllers, you can write the functionality & logic to develop dynamic web applications. It takes the data request from the views & sends it to the model and sends the response back to the views.
+The naming convention for the model files is: `name-here-controller.js`.
+
+Here is an example:
+
+```js
+// post-controller.js
+
+const express = require('express');
+const router = express.Router();
+const Post = require('../models/post-model.js')
+
+router.get('/posts', (req, res) => {
+ Post.find({})
+  .then((posts) => {
+    res.json(posts);
+  })
+  .catch(console.error)
+})
+});
+```
+
+---
+
+## References
+
+- https://medium.com/geekculture/mvc-architecture-with-express-server-e35aedfe7889
+- https://codingstatus.com/express-mvc-structure/