Agnostic JS framework that empowers devs to focus on quickly building apps, rather than focusing on application config, health-checks, application structure, or architecture to build a 12 factor app in Docker.

This quick demo shows that you can create a basic API in just a couple files that's defined by configuration, but is 12 factor ready, Docker ready, and much more! Check out the full demo here.

npm install spawnpoint --save

// ~/app.js
const spawnpoint = require('spawnpoint');

const app = new spawnpoint();
app.setup();

// ~/config/app.json
{
	"name": "Example App",
	"plugins": [
		"spawnpoint-express", // this creates an express server
		"spawnpoint-redis"	// this establishes a connection to a redis server via redisio
	],
	"autoload": [
		// this autoloads all js files in the ~/controllers folder
		{
			"name": "Controllers",
			"folder": "controllers"
		}
	]
}

// ~/controllers/app.js
module.exports = (app) => {
	// express is already setup and configured via JSON
	app.server.get('/user/:id', (req, res) => {
		// redis is already connected and ready
		app.redis.get(`user:${req.params.id}`, (err, results) => {
			if(err){ res.fail(err); } // automatic error handling

			// return JSON formated success with a success code
			res.success('users.list', {
				user: JSON.parse(results)
			});
		});
	});
};

Spawnpoint plugins create opinionated & re-usable components that reduce the code needed to kickstart projects. Plugins are configured via JSON config files, making them easier to share between projects with different needs.

• Express - Express: web server
• Redis - Redis: Key/value database/store
• RethinkDB - RethinkDB: - NoSQL document database
• NATS - Nats.io: Pub/Sub Message Queue

We constantly found our dev team rebuilding the same components to our micro services that make up the Multiplayer Gaming Cloud platform at Nodecraft. Most of the features had blatant copy/paste to ensure our applications could:

• Building 12 factor apps
• Auto-loading multiple folders for product folder structure
• File require() recursion management overhead ?
• Support basic --command="args" that override config files
• ENV variables that override config files
• Docker Secrets that override config files
• Dev config overrides
• Rebuilding a basic JSON REST API via express
• Database connect/reconnect management
• Healthchecks
• Application lifecycle
  • Tracks app startup
  • Graceful shutdown
• Making a Docker friendly NodeJS app

The most opinionated design choice that Spawnpoint makes is hoisting the entire framework runtime into each file. You can name this variable anything, but the best practice is to name this variable app. All system models, libraries, and config are hoisted to this variable with several namespaces:

All application config is mounted here. For example app.config.express is where all configuration is available to the spawnpoint-express plugin.

Tracks the current application lifecycle.

Detects if app is running in a container.

Returns the main folder where your application lives.

When you hoist your library on the app variable you can access it on any other autoloaded js file.

module.exports = (app) => {
	app.yourLibName = {
		add(a, b){
			return a + b;
		}
	};
}

app.server.post('/add', (req, res) => {
	// redis is already connected and ready
	let results = app.yourLibName.add(req.body.a, req.body.b);
	res.success('math.add', {
		results: results
	});
});

• ExpressJS: using spawnpoint autoloading - Using Spawnpoint autoloading and plugins to create a HTTP server.
• ExpressJS: unframework - Using Spawnpoint core methods to build a basic HTTP server, without the automatic framework.
• More coming soon

Get the full API Docs here.