Standard is used to run style checks and code linting.
Contributors are requested to work only on their own forked clones of sakshamsaxena/uzay
, and submit neat PRs after developing features or applying fixes. Here is a step by step guide on how to do that :
- Fork
sakshamsaxena/uzay
. Now you've your own clone atYOUR_USERNAME/uzay
. - Clone it locally by
git clone https://github.com/YOUR_USERNAME/uzay.git
npm install
to get all dependencies.- Import database collections as mentioned in README.
- Add an
upstream
remote in your repository bygit remote add upstream https://github.com/sakshamsaxena/uzay.git
. - Checkout a new feature branch by
git checkout -b FEATURE_NAME
. - Hack away!
- Write tests if it's a new feature! Run tests with
npm test
ormocha
. - When the feature is complete, open a PR!
To stay up to date with the main project, you can git pull upstream master
to get the latest changes. It's preferred to do it before you start working on your feature branch.
That's it!
To understand the discussion which follows, as well as to be able to smoothly contribute to the project, you must be familiar with the following concepts :
- Non-Relational Data Representation in MongoDB.
- Concept of Modules in Node and Modular Pattern.
- JavaScript Promises.
- Basic Components of a Web Server :
- Middlewares
- Routing
- Static and Dynamic Resources
- REST Architecture
- TDD/BDD
Uzay (uzz-aye) is built on Node.js with Express as the bare framework, and MogoDB as the database engine with Mongoose as it's ODM.
MongoDB was chosen over Relational Databases like MySQL due to it's natural compatibility with Node.js as well as it's trait of allwing to use a structure which the application gels with most. Even though in our current design, it is fairly normalised like Relational Databases, yet, it is performed to the extent necessary to keep the application, which is aimed to be highly configurable, flow as smooth as possible. Due to this inherent flexibility of the application, MongoDB was used to utilise advantages of both NoSQL DBs as well as that of RDBMSs practices.
Mongoose follows a convention to represent a MongoDB Collection as a Schema. Mongoose Models are then created using this Schema which creates an interface to interact with that Collection. Uzay contains it's own set of "Mappers" which defines custom operations which are performed on each Collection. These are, again, inherently amazing as Mongoose Models use ES6 Promises for these async operations.
All API endpoints are designed to be RESTful and represent resources in semantic URLs. All the endpoints use respective business logic classes to obtain the necessary data as is. This is then consumed by a "Payload Generator" which uses this raw data from database and return a presentable JSON response, which is finally sent to the client.
Security layer can be easily plugged in via "middlewares" to each endpoint, as per case.
As a simple blog engine, Uzay can still scale well horizontally, mainly due to it's inheritance from Node.js and MongoDB's scaling capabilities. Further, since security layer is a "pluggable" service, it can scale independently without affecting existing architecture. MongoDB's Collections are normalised enough to act as the source of truth for any extra new analytics services with a different set of database, which still won't affect the core application's performance.
Finally, best practices in development process ensures least TTM (Time To Market) with quality code.