Nodeíí is not a framework. Inspired by concepts used in SailsJS and Uncle Bob (Robert C. Martin), it is a loose coupling of high-level services that will assist you in building applications. Nodeíí includes some well-supported libraries to get you started but you can easily swap-out anything, anytime. Nodeíí gives you the power to make your own decisions while helping lead the way.

Key points:

• Don't let your dependencies control your project! Sensei says, KISS
• Be sensible, setup your NodeJS Web Projects as a builder, not an integrator

Why not MVC? MVC is an archaic design pattern. Built around 20 year-old concepts. Certain aspects might be viable, just not practical. Controllers become so bloated and developers get lazy. MVC lacks the appropriate separation of real-world concerns. MVC requires knowledge and discipline to follow the paradigm; Nodeii is not a framework and doesn't require a regimented architecture. You control your dependencies and we are just here for guidance (unless you think we are completely insane).

Why not EcmaScript 6? Rewriting everything just because there are new decorators and neat/new ways to do things really doesn't solve any problems.

We aim to produce a clean separation of concerns by providing a concept that breaks the MVC mold and gives you the flexibility to control dependencies.

Nodeíí is configured to use simple but well supported libraries:

• Router: ExpressJS
• Logging: Morgan
• ORM: Waterline
• Templates: EJS
• Utility: Lodash
• Async Operations: Async

Nodeíí separates concerns into a new type of structure that is explained further below.

Infrastructure are the backend components. In a traditional MVC structure, this would be limited to the models. In this implementation, they are called entities. Infrastructure encapsulates:

• Entities
• Managers
• Components

Managers are backend service containers that manage business logic. Imagine you want to expose a single service to manage Registrations. This service may touch many entities. This is the perfect place for placing complex business logic functions.

Components are libraries that don't quite fit the mold of an Entity or Manager. Most likely, some sort of wrapper for a third-party integration or general library that may be used through the application. An example of this would be a Cryptography library or a wrapper for AWS functions.

Interface is all of the view logic to send to the client. In a traditional MVC structure, this would be controllers and views. Nodeíí turns interface into an encapsulated environment that contains:

• Routing
• Assets
• Views (EJS is installed, *you can swap for whatever you want; Jade, Mustache, Nunjucks)
• Services
• Policies

It is our belief that infrastructure should have minimal coupling and have no effect on how an interface is built. The only connection from interface to infrastructure is the fact that interface can invoke entities in the processing files (formerly known as controllers for MVC folks).

You should be able to remove interface and keep all of your business logic intact. Even better, you should be able to create multiple interfaces without having to mess with the infrastructure. You could actually create an interfaces folder and have any of the following as sub-interfaces:

• Web
• CLI
• API
• Mobile

Use Services to extract functions for route processing. You may also think of these as interface helpers.

If you need to interface with the infrastructure layer, best case scenario is that you create infrastructure managers to move data between entities and only use the manager references in the interface layer - but we don't judge :-)

The processing files (controllers) for Nodeíí merely resolve routes to JS files that can also invoke *EJS templates to display their layout. Key point is that there is no convention for doing so, you can output your data with any templating engine that you want (EJS, Jade, Mustache, Handlebars, DIY) we just include EJS for ease of integration with web apps.

If Nodeíí is too abstract or questionable for you, perhaps SailsJS is your better choice. We just want you to use the right tool for the job.

We don't care about your frontend frameworks. Add any framework (VanillaJS, jQuery, Bootstrap, Prototype, Scala.js, Nuclear, React, Backbone, GWT, Ember, Knockout, Angular, Vue). It is up to you, there are so many choices and we won't make them for you.

To reiterate, we don't care to touch any of your browser-based code. That part is up to you. Use Bower, Grunt or whatever you want. Use Less, SCSS, Coffeescript or anything of your liking (if you want strange dependent Ruby Gems).

We believe that you should be already writing clean, concise code and don't need those libraries but everyone has a flavor.

We don't want your experience to be terrible. Therefore we included a basic internationalization Service in the Interface and a Policy to inject the locale for those who don't expect all web applications to be in the English language. You can add locale configuration into the config/interface/langs folder. Policies are configured as string representations of an Object.method or a lambda function.

There is a basic example of usage already included in the Git Checkout. Once you start the app, you will be using Nodeii. Simple Git clone the project and run:

node app.js

We get you started with basic testing using mocha. We created a folder called tests in the infrastructure folder. You can add tests and run:

make test

• Use Web Sockets for real-time updates
• Use Redis for memory cache in clustered environments
• Use iNotify to watch files as they arrive (like AWS SNS)
• Use Mongo to store non-relational data (Waterline supports this already though)
• Use PM2 to scale web HTTP/HTTPS NodeJS Web Applications (NO WebSockets through HTTPS)
• Use nGinx to scale ALL NodeJS Applications w/ Static Content (HTTP/HTTPS)
• Use HAProxy to scale your HTTP/HTTPS APIs (YES WebSockets through HTTPS)

We have built this concept around the most-recent versions of the libraries as mentioned above. You can always swap whatever you want but we want to instill the concept of managing dependencies at a project level. You don't have to use NPM shrinkwrap, we just want your checkout and basic usage of this concept to be smooth and simple.

Clone this project and run:

npm install

Configure Environment:

ln -s config/env/local.js config.js

Then:

node app.js

In your browser:

http://localhost:1337

(The MIT License)

Copyright (c) 2015,2016,2017,2018 Craig R. Hoover

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.