General Server Roadmap

[stongo]

Wanted to start a roadmap for docpad server plugin best practices.

Feel free to add more features, and I'll probably add more later.

Plugins

Servers should be included in Docpad as a plugin. Otherwise, Docpad configuration should allow default server to be disabled

Fault Tolerance

Servers should not listen to the same folder that Docpad generates to. This leads to high risk of a site crash if regeneration fails. Files should be copied via NCP to a 'public_html' folder on the 'writeAfter' event. This ensure the folder being served always contains all files. This also solves the delay in serving files during regeneration

404s

Right now assets that return a 404 trigger a regeneration. Not sure the reasoning behind it, but this is an instant DDOS opening and an attacker could easily expend process memory. This should not be the case.

Dynamic Pages

As regeneration currently stands, regenerating the entire site for one Dynamic page is also a severe DDOS risk. File specific regeneration would need to be possible for this to be a feasible feature.

Abstraction and other plugins using Express

Non-Express servers would currently need to parse existing plugins using the Express router or method override. This may be acceptable.
This could also lead to server specific plugins, which is possible okay

Router in config

At least for a plugin I'm planning, I would include a route in the plugin config for easily adding custom routes. Would make for rapid development

---

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

[stongo]

Edited original post. Copying files to public_html folder should happen on writeAfter event

[stongo]

Plugin and helper routes

routes handled by the server outside the static site - ie. contactify plugin - should have a /api prefix

api/myPluginRoute

[RobLoach]

Sounds exciting. This could really speed up development process as it could allow the use of different server architectures. Would also allow DocPad to be used in a number of production facilities too.

[stongo]

Here is a alpha release of a server plugin. http://github.com/stongo/docpad-plugin-hapi

[stongo]

2.1.0 version released of docpad-plugin-hapi. The plugin works with "docpad run" and by running it's bin file in a cloud hosted environment.

To further the development of server plugins, I think two things are necessary.

Action API

A server plugin needs a way to create an action similar to "server" to properly integrate with docpad

Event API

A server plugin should be able to register an event that can be extended by other plugins

[stongo]

I was able to make due with the lack of these APIs by harnessing the Hapi plugin system, and assigning docpad as a server.app property in docpad-plugin-hapi v2.2.0.
Any plugin loaded by docpad-plugin-hapi will have access to docpad by calling server.app.docpad.getConfig() for example

[RobLoach]

I had a quick look over this with @balupton and it looks pretty neat. You're killing DocPad's internal Express server before creating the HAPI one.

Pushing this forwards into DocPad, we could:

1. Move the Express implementation into a docpad-plugin-express. The server then only becomes available if a server plugin is installed.
2. Check a disableExpressServer event to see if we should not start the express server
3. Use a container to pick up which server plugin we should be using (defaults to express)

A number of methods around this.

[stongo]

Sounds like a great plan for Docpad.

The current implementation of docpad-plugin-hapi was definitely a bit of a
hack to get it working with what is currently available in Docpad
On Jan 23, 2014 5:44 PM, "Rob Loach" notifications@github.com wrote:

I had a quick look over this with @balupton https://github.com/baluptonand it looks pretty neat. You're killing DocPad's internal Express server
before creating the HAPI one.

Pushing this forwards into DocPad, we could:

1. Move the Express implementation into a docpad-plugin-express. The
   server then only becomes available if a server plugin is installed.
2. Check a disableExpressServer event to see if we should not start
   the express server
3. Use a container https://en.wikipedia.org/wiki/Dependency_injectionto pick up which server plugin we should be using (defaults to express)

A number of methods around this.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/768#issuecomment-33177914
.

[stongo]

Route configuration to avoid pauses in serving files during regeneration

In production NODE_ENV, static file route should attempt to serve files in the following sequence to avoid pausing or returning 404s due to regeneration:

serve from in-memory database > serve from /public_html > serve from /out

Implemented here

Development and Production env

The 'out' folder should only be copied to 'public_html' in production NODE_ENV. The static route should serve from 'out' in development for fast regenerations

[balupton]

Closed in favour of #1081