Opinions

Turnpike aims to be "politely opinionated". This does not, by any measure, mean it is unopinionated. The framework is built on strong opinions, but aims to explain them; while it does not support, it won't actively subvert your efforts to work in a different way.

Object Oriented

Turnpike aims for classical inheritance patterns. We define object prototypes in a hierarchy, and expect you to extend and use them. The "new" keyword is your friend. Node's util.inherits() is also your friend.

Generators are nice, code is better

You won't find a lot of options in the code generators. Instead of outputting scaffoldings with your structure already built, it's better to provide a syntax that makes writing the structure out by hand fast and simple.

Static Models

A model represents the whole of a data set, and acts as a factory for Item objects. You generally work with the Item objects. This is different from other frameworks, where the model is an individual item.

One application per project

We don't support mounting more than one application in a single instance of the Turnpike server. If you want to shoot yourself in the foot this way, you're on your own. Otherwise, if you need to run more than one service on a single host, run multiple servers and put them behind nginx.

Follow HTTP standards (Up to point where it hurts)

We use standard HTTP mechanisms everywhere possible. I.e. correct response codes, content negotiation by the "Accept" header, etc. We don't, however, try to force this in places where the client end insists on being stupid (We mean you, web browser). For example, HTTP CRUD methods are implemented faithfully for all endpoints by default, but we allow POST requests against the save (update) and remove (delete) actions so web browsers can still interact with our services.

Configure through environment variables, and provide fallback defaults where appropriate.

Every property of the turnpike.config object can be overridden twice: once in your project's settings.json file, and then by setting an environment variable of the same name. The project-level settings should contain the expected settings of a local development environment, and environment variables should be used to handle production environment settings. API keys and other secrets should NEVER be in any file in your project.