feat: MERN Stack,12 factor app (#39513)

.editorconfig

@@ -0,0 +1,14 @@
+root = true
+
+[*]
+indent_style = space
+indent_size = 2
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+end_of_line = lf
+# editorconfig-tools is unable to ignore longs strings or urls
+max_line_length = off
+
+[CHANGELOG.md]
+indent_size = false

12FACTOR-APP.md

@@ -0,0 +1,66 @@
+The Twelve Factors
+===
+# 1. Codebase
+**There should be exactly one codebase for a deployed service with the codebase being used for many deployments.**
+
+There is always a one-to-one correlation between the codebase and the app:
+* If there are multiple codebases, it’s not an app – it’s a distributed system. Each component in a distributed system is an app, and each can individually comply with twelve-factor.
+* Multiple apps sharing the same code is a violation of twelve-factor. The solution here is to factor shared code into libraries which can be included through the dependency manager.
+
+# 2.	Dependencies
+**All dependencies should be declared, with no implicit reliance on system tools or libraries.**
+A twelve-factor app never relies on implicit existence of system-wide packages. It declares all dependencies, completely and exactly, via a dependency declaration manifest. Furthermore, it uses a dependency isolation tool during execution to ensure that no implicit dependencies “leak in” from the surrounding system. The full and explicit dependency specification is applied uniformly to both production and development.
+
+# 3. Config
+**Configuration that varies between deployments should be stored in the environment.**
+An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc). This includes:
+* Resource handles to the database, Memcached, and other backing services
+* Credentials to external services such as Amazon S3 or Twitter
+* Per-deploy values such as the canonical hostname for the deploy
+
+# 4.	Backing services
+**All backing services are treated as attached resources and attached and detached by the execution environment.**
+A backing service is any service the app consumes over the network as part of its normal operation. Examples include datastores (such as MySQL or CouchDB), messaging/queueing systems (such as RabbitMQ or Beanstalkd), SMTP services for outbound email (such as Postfix), and caching systems (such as Memcached).
+
+# 5.	Build, release, run	
+**The delivery pipeline should strictly consist of build, release, run.**
+
+A codebase is transformed into a (non-development) deploy through three stages:
+
+* The build stage is a transform which converts a code repo into an executable bundle known as a build. Using a version of the code at a commit specified by the deployment process, the build stage fetches vendors dependencies and compiles binaries and assets.
+* The release stage takes the build produced by the build stage and combines it with the deploy’s current config. The resulting release contains both the build and the config and is ready for immediate execution in the execution environment.
+* The run stage (also known as “runtime”) runs the app in the execution environment, by launching some set of the app’s processes against a selected release.
+
+# 6.	Processes
+**Applications should be deployed as one or more stateless processes with persisted data stored on a backing service.**
+
+In the simplest case, the code is a stand-alone script, the execution environment is a developer’s local laptop with an installed language runtime, and the process is launched via the command line (for example, python my_script.py). On the other end of the spectrum, a production deploy of a sophisticated app may use many process types, instantiated into zero or more running processes.
+
+# 7.	Port binding	
+**Self-contained services should make themselves available to other services by specified ports.**
+The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.
+
+# 8.	Concurrency
+**Concurrency is advocated by scaling individual processes.**
+Any computer program, once run, is represented by one or more processes. Web apps have taken a variety of process-execution forms. For example, PHP processes run as child processes of Apache, started on demand as needed by request volume. Java processes take the opposite approach, with the JVM providing one massive uberprocess that reserves a large block of system resources (CPU and memory) on startup, with concurrency managed internally via threads. In both cases, the running process(es) are only minimally visible to the developers of the app.
+
+# 9.	Disposability	
+**Fast startup and shutdown are advocated for a more robust and resilient system.**
+Processes should strive to minimize startup time. Ideally, a process takes a few seconds from the time the launch command is executed until the process is up and ready to receive requests or jobs. Short startup time provides more agility for the release process and scaling up; and it aids robustness, because the process manager can more easily move processes to new physical machines when warranted.
+
+# 10.	Dev/Prod parity
+**All environments should be as similar as possible.**
+
+Historically, there have been substantial gaps between development (a developer making live edits to a local deploy of the app) and production (a running deploy of the app accessed by end users). These gaps manifest in three areas:
+
+* **The time gap:** A developer may work on code that takes days, weeks, or even months to go into production.
+* **The personnel gap:** Developers write code, ops engineers deploy it.
+* **The tools gap:** Developers may be using a stack like Nginx, SQLite, and OS X, while the production deploy uses Apache, MySQL, and Linux.
+
+# 11.	Logs
+**Applications should produce logs as event streams and leave the execution environment to aggregate.**
+Logs provide visibility into the behavior of a running app. In server-based environments they are commonly written to a file on disk (a “logfile”); but this is only an output format.
+
+# 12. 	Admin Processes
+**Any needed admin tasks should be kept in source control and packaged with the application.**
+One-off admin processes should be run in an identical environment as the regular long-running processes of the app. They run against a release, using the same codebase and config as any process run against that release. Admin code must ship with application code to avoid synchronization issues.

CLIENT-SERVER.md

@@ -0,0 +1,18 @@
+How a request get served?
+==
+---
+
+Web Server accepts request and responds to Hypertext Transfer Protocol (HTTP) requests. Browsers such as Netscape™ Communicator communicate using several protocols including HTTP and FTP. 
+
+The transfer of resources happens using TCP (Transmission Control Protocol). In viewing this webpage, TCP manages the channels between your browser and the server. TCP is used to manage many types of internet connections in which one computer or device wants to send something to another. HTTP is the command language that the devices on both sides of the connection must follow in order to communicate.
+
+Once the TCP connection is established, the client sends a HTTP GET request to the server to retrieve the webpage it should display. After the server has sent the response, it closes the TCP connection. If you open the website in your browser again, or if your browser automatically requests something from the server, a new connection is opened which follows the same process described above. 
+
+# _HTTP Basics_
+---
+As a quick summary, the HTTP/1.1 protocol works as follows:
+
+* The client (usually a browser) opens a connection to the server and sends a request.
+* The server processes the request, generates a response, and closes the connection if it finds a Connection: Close header.
+* The request consists of a line indicating a method such as GET or POST, a Uniform Resource Identifier (URI) indicating which resource is being requested, and an HTTP protocol version separated by spaces.
+* This is normally followed by a number of headers, a blank line indicating the end of the headers, and sometimes body data. Headers may provide various information about the request or the client body data. Headers are typically only sent for POST and PUT methods.

MERN-STACK.md

@@ -0,0 +1,66 @@
+MERN Stack: 
+==
+MERN Stack is a Javascript Stack that is used for easier and faster deployment of full-stack web applications. MERN Stack comprises of 4 technologies namely: MongoDB, Express, React and Node.js. It is designed to make the development process smoother and easier.
+
+Each of these 4 powerful technologies provides an end-to-end framework for the developers to work in and each of these technologies play a big part in the development of web applications.
+
+# 1. MongoDB: Cross-platform Document-Oriented Database 
+---
+
+MongoDB is a NoSQL database where each record is a document comprising of key-value pairs that are similar to JSON (JavaScript Object Notation) objects. MongoDB is flexible and allows its users to create schema, databases, tables, etc. Documents that are identifiable by a primary key make up the basic unit of MongoDB. Once MongoDB is installed, users can make use of Mongo shell as well. Mongo shell provides a JavaScript interface through which the users can interact and carry out operations (eg: querying, updating records, deleting records).
+
+**Why use MongoDB?**
+--
+
+* Fast – Being a document-oriented database, easy to index documents. Therefore a faster response.
+* Scalability – Large data can be handled by dividing it into several machines.
+* Use of JavaScript – MongoDB uses JavaScript which is the biggest advantage.
+* Schema Less – Any type of data in a separate document.
+* Data stored in the form of JSON –
+Objects, Object Members, Arrays, Values and Strings
+* JSON syntax is very easy to use.
+* JSON has a wide range of browser compatibility.
+
+# 2. Express: Back-End Framework:
+---
+Express is a Node.js framework. Rather than writing the code using Node.js and creating loads of Node modules, Express makes it simpler and easier to write the back-end code. Express helps in designing great web applications and APIs. Express supports many middlewares which makes the code shorter and easier to write.
+
+**Why use Express?**
+--
+
+* Asynchronous and Single-threaded.
+* Effecient, fast & scalable
+* Has the biggest community for Node.js
+* Express promotes code reusability with its built-in router.
+* Robust API
+
+# 3. React: Front-End Framework
+---
+React is a JavaScript library that is used for building user interfaces. React is used for the development of single-page applications and mobile applications because of its ability to handle rapidly changing data. React allows users to code in JavasScript and create UI components.
+
+**Why use React?**
+---
+* **Virtual DOM** – A virtual DOM object is a representation of a DOM object. Virtual DOM is actually a copy of the original DOM. Any modification in the web application causes the entire UI to re-render the virtual DOM. Then the difference between the original DOM and this virtual DOM is compared and the changes are made accordingly to the original DOM.
+
+* **JSX** – Stands for JavaScript XML. It is an HTML/XML JavaScript Extension which is used in React. Makes it easier and simpler to write React components.
+
+* **Components** – ReactJS supports Components. Components are the building blocks of UI wherein each component has a logic and contributes to the overall UI. These components also promote code reusability and make the overall web application easier to understand.
+
+* **High Performance** – Features like Virtual DOM, JSX and Components makes it much faster than the rest of the frameworks out there.
+
+* **Developing Android/Ios Apps** – With React Native you can easily code Android-based or IOS-Based apps with just the knowledge of JavaScript and ReactJS.
+
+# 4. Node.js: JS Runtime Environment
+---
+Node.js provides a JavaScript Environment which allows the user to run their code on the server (outside the browser). Node pack manager i.e. npm allows the user to choose from thousands of free packages (node modules) to download.
+
+**Why use Node.JS?**
+--
+
+* Open source JavaScript Runtime Environemnt
+* Single threading – Follows a single threaded model.
+* Data Streaming
+* Fast – Built on Google Chrome’s JavaScript Engine, Node.js has a fast code execution.
+* Highly Scalable
+
+