anodejs/node-docrouter

Documented Connect/Express Router

Introduction

ANODE is a PaaS (Platform as a Service) for developing and hosting node.js WEB applications on Azure.

ANODE is available as a free open source in github. You can clone all ANODE code and have full control over the platform. The steps below guide you in creating your own ANODE deployment.

Features

In a nutshell, ANODE offers the following features:

• Multitenancy - ANODE hosts multiple versions of multiple applications from git repositories and branches, side-by-side.
• Instantaneous deployment - push into git leads to immediate service update in the cloud. ANODE is integrated with github (and bitbucket), supports and leverages github development process.
• Security - ANODE wraps all security handling and exposes HTTPS endpoint. ANODE applications are HTTP servers, agnostic of security.
• Instantaneous logging - ANODE offers instant viewing and querying logs from applications.
• Management dashboard - all management is performed via ANODE's management dashboard. The dashboard is extendable and can be used for managing applications.
• Scale out - ANODE symmetrically deploys applications on Azure instances. Scaleout is opaque to applications.
• Interoperability - ANODE allows applications to collaborate with each other. ANODE itself is implemented as a number of node.js applications.
• Services - there are multiple services offered by ANODE, e.g. scheduling delayed jobs.
• Testing - ANODE supports test suites development and execution.

Terminology

• ANODE farm - Azure cloud service with one production deployment of ANODE role running on several instances.
• Instance - Azure instance (aka VM). We use "Small" sized instances.
• ANODE cluster - Set of several ANODE farms sharing common storage account.

Prerequisites

You need Git to be installed on your development computer. Follow the these steps if you don't have Git yet.

Setup ANODE farm

• The 1st phase - setup basic functional ANODE farm
• The 2nd phase - secure the farm
• The 3rd phase - start deploying applications
• The 4th phase - setup development environment
• Troubleshooting

Reference

node-docrouter's Issues

Jade is Pug

The Jade module now is Pug module.

Document/collaborate on metadata structure?

Hey Saar,

I found your project via your comment on Zac Taylors blog post, and think there's a very large overlap in the documentation data you add to routes here, and what can be added when defining resources in my Lazorse project. I'd love to start a discussion on shared schema for describing available endpoints/resources and their parameters, so I'm just going to braindump a bit here on how I've been doing it and the differences I see so far.

In Lazorse I don't (yet) handle the OPTIONS method, but GET / responds with a JSON object describing available resources in a format very similar to yours:

[
  {
    "template": "/{language}/greetings",
    "description": "Per-language greetings",
    "shortName": "localGreeting",
    "methods": ["GET", "POST"],
    "examples": "/examples/localGreeting"
  }
]

(from http://betsmartmedia.github.com/Lazorse/guide.html#routing)

I immediately prefer your "id" to my "shortName", and I like how you're including documentation for parameters inline. I make parameter documentation available as a separate resource (/parameters/{parameterName} by default) because it was a later addition. In the future I will either inline parameter documentation, or provide links in the same way I do for examples.

I also provide examples as a separate resource because I wanted to include responses with the examples as well. I found this desirable because the API I'm developing requires authentication, but I still wanted unauthenticated clients to be able to see what they responses they would receive.

I've also implemented (in an as-yet unreleased extension) support for defining and serving up JSON schemas for responses, and plan to extend that to request bodies as well.

Anyways, I'm very enthusiastic about the idea of consolidating on and documenting a single schema for this metadata, as it's something I hope to build more tooling around as time goes on. We already have clients that do auto-discovery and dynamic methods for PHP, Python, and Node, and the CLI client you mentioned in your comment sounds super cool. Let me know what you think about the differences and if this GH issues works as a venue for discussion for you.

Swagger Spec?

I use swagger to define my rest APIs.
Do you think it would be possible to include a swagger spec implementation?

Please bump and publish

Hi @saary, could you please bump and republish docrouter?