Wednesday, July 10, 2019

MERN

Express : CRUD Application by express

$ mkdir movies-app
$ cd movies-app
$ mkdir server
$ cd server
$ yarn initor$ npm init -y
$ ls
package.json
$ yarn add express body-parser cors mongoose nodemonor$ npm install express body-parser cors mongoose nodemon
  • Body Parser: Responsible to get the body off of network request.
  • Nodemon: Restart the server when it sees changes (for a better dev experience).
  • Cors: Package for providing a Connect/Express middleware that can be used to enable CORS with various options.
  • Mongoose: It's an elegant MongoDB object modeling for node.js
$ls
node_modules package.json yarn.lock
$ node index.js
Node JS application running

1.1. Installing MongoDB

For now, we need to install MongoDB. For this, just type on your terminal:
$ brew install mongodb
$ mkdir -p /data/db
$ brew services start mongodb
$ mongo
> use cinema
$ mkdir db
$ touch index.js
Updating the main file server/index.js we have something like this.
If you take a look at your terminal, you see that nothing changed. This is because when you type node index.js that means node keeps the last set up before it started. If you’d like to restart the application you need to close and open a new one. However, at the beginning of this tutorial, I told you about nodemon, it’s going to restart the server every time when it sees changes in any file of our project. From, now let’s do this.$ nodemon index.js

1.1.1. Creating Movie’s Schema

As we’ve said, we need to create an entity called movies that should be composed of the movies of a cinema. For this, we just need to know the name of the movie and the times the movie is passing on the cinema, and to add an important, but not necessary information, the rating.
$ mkdir models
$ cd models
$ touch movie-model.js

1.2. Creating routes

Here, we’ll create all the CRUD operations and create our REST endpoints. Let’s create two more folders on the server: routes and controllers. In the route folder, let’s create the file movie-router.js and in the controller folder, movie-ctrl.js.
$ mkdir routes controllers
$ touch routes/movie-router.js
$ touch controllers/movie-ctrl.js

1.3. Testing manually our application

To test our application I’d like to introduce two more tools: Postman and Robo 3T. These tools will help us in verify our application working (I won’t explain how to install because it’s easy and you can find this in their own websites).
{
    "name": "Avengers: Endgame",
    "time": ["14:15", "16:00", "21:30", "23:00"],
    "rating": 8.8
}

Saturday, July 6, 2019

Laravel : Laravel Eloquent vs query builder - Why use eloquent to decrease performance?

Yes, In some case you are right. When we've more data and almost in every site, data is not small really. Then it is better to use DB Query than the Eloquent Query.
In a performance issue of Eloquent VS DB I've heard that,
To insert 1000 rows for a simple table Eloquent takes 1.2 seconds and in that case DB facades take only 800 mili seconds(ms).
So Why then Eloquent ? Is't any necessary of that ?
Answer is - Eloquent is also necessary. Cause-
To create a better relationship and get the results in view with so much simple syntax, when there needs to join.
Eloquent is also for who have not much knowledge of SQL query.
An MVC framework follow the rules of Code Readability, Code Maintainability and which Eloquent is, you know that. A code comparison below. Obviously, Eloquent is better to read.
// In Eloquent
$student = App\Student::find($id);

// In DB facade
$student = DB::table('student')->where('id', $id)->first();
Most important part is if we want to change other database, then raw query will be a lot much headache to us and in that case Laravel Eloquent will solve all the problems with one hand. It can handle different types Database.
So when we use Eloquent and When DB facades:
  1. When we'll work on a simple and small records site with simple CRUD and there records are not fact, then use Eloquent there.
  2. When we'll work on a lot's of records, it is better to use DB Query than Eloquent.
So, finally it is cleared that - when we'll use Database Query and When we'll use Eloquent Query.
Edit - Real Life Example
  1. I'm making an University website. Which may contain maximum 5,000 teachers and 10,000 students and some notices and files. Then it is better to do this with simple Laravel Eloquent which is very much standard and readable.
  2. Now I'm making a site like Stackoverflow. Which may contains more than 1,000,0000 (1 crore) posts and many more things. I will must choose the conventional DB facades there. It is more faster for searching the posts from so much records.
You can check your query performance using Laravel Debugbar (A popular package to check Eloquent/Database query performance/ execution times)
Now it's your choice. What you want to make...

JS : Event Bubbling and Propagation

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>Document</title>
</head>
<body>
    <div id="m">
        <div id="d">
            <div id="p">
                <div id="s"></div>
            </div>
        </div>
    </div>
</body>
</html>

<script>
// Event Bubbling and Propagation
//  element.addEventListener( type, func, useCapture);

let m = document.getElementById('m');
let d = document.getElementById('d');
let p = document.getElementById('p');
let s = document.getElementById('s');
let log = console.log;

let highlight = (ev)=>{
    //add CSS class "gold" to the clicked element
    ev.stopPropagation();
    let target = ev.currentTarget;
    target.className = 'gold';
    reset(target);
}

let reset = (_element)=>{
    setTimeout(()=>{
        _element.className = '';
    }, 2000);
}

d.addEventListener('click', (ev)=>{
    ev.stopImmediatePropagation();
    log('Hi I\'m a DIV');
});

[m,d,p,s].forEach((element)=>{
    element.addEventListener('click', highlight);
})
</script>

Wednesday, July 3, 2019

MySql : Introduction to MySQL Stored Procedures.

Summary: in this tutorial, you will learn about MySQL stored procedures, their advantages, and disadvantages.


Definition of stored procedures

A stored procedure is a segment of declarative SQL statements stored inside the database catalog. A stored procedure can be invoked by triggers, other stored procedures, and applications such as Java, Python, PHP.
mysql stored procedure
A stored procedure that calls itself is known as a recursive stored procedure. Most database management systems support recursive stored procedures. However, MySQL does not support it very well. You should check your version of MySQL database before implementing recursive stored procedures in MySQL.

Stored Procedures in MySQL

MySQL is known as the most popular open source RDBMS which is widely used by both community and enterprise. However, during the first decade of its existence, it did not support stored procedures, stored functions, triggers, and events. Since MySQL version 5.0, those features were added to the MySQL database engine to make it more flexible and powerful.

MySQL stored procedures advantages

  • Typically, stored procedures help increase the performance of the applications. Once created, stored procedures are compiled and stored in the database. However, MySQL implements the stored procedures slightly different. MySQL stored procedures are compiled on demand. After compiling a stored procedure, MySQL puts it into a cache and maintains its own stored procedure cache for every single connection. If an application uses a stored procedure multiple times in a single connection, the compiled version is used, otherwise, the stored procedure works like a query.
  • Stored procedures help reduce the traffic between application and database server because instead of sending multiple lengthy SQL statements, the application has to send only the name and parameters of the stored procedure.
  • Stored procedures are reusable and transparent to any applications. Stored procedures expose the database interface to all applications so that developers do not have to develop functions that are already supported in stored procedures.
  • Stored procedures are secure. The database administrator can grant appropriate permissions to applications that access stored procedures in the database without giving any permissions on the underlying database tables.
Besides those advantages, stored procedures have their own disadvantages, which you should be aware of before using them in your databases.

MySQL stored procedures disadvantages

  • If you use many stored procedures, the memory usage of every connection that is using those stored procedures will increase substantially. In addition, if you overuse a large number of logical operations inside stored procedures, the CPU usage will increase because the database server is not well-designed for logical operations.
  • Stored procedure’s constructs are not designed for developing complex and flexible business logic.
  • It is difficult to debug stored procedures. Only a few database management systems allow you to debug stored procedures. Unfortunately, MySQL does not provide facilities for debugging stored procedures.
  • It is not easy to develop and maintain stored procedures. Developing and maintaining stored procedures are often required a specialized skill set that not all application developers possess. This may lead to problems in both application development and maintenance phases.
MySQL stored procedures have their own advantages and disadvantages. When you develop applications, you should decide whether or not to use stored procedures based on your application’s architecture.
In the following tutorials, we will show you how to leverage MySQL stored procedures in your database programming tasks with many practical examples.