Every so often (maybe twice a week in IRC) someone asks about a blog, 
e-commerce, or content management system for Node.js. I feel compelled to 
ask "Why Node.js", because it seems like one of those "I want to do it 
because I can" rationales. Most people have that exact reason, and not much 
else (that's not non-generic). But that's not to say no such reason exists.

I had this idea of mine long before Node.js, so I have what I believe are 
more practical reasons. A CMS is I/O heavy, not especially computationally 
heavy. ECMAScript is a natural choice because it's prototype-based, 
event-oriented, and of course, the language of the Web. A little while 
after having been introduced to Node.js, I realized what Node.js was 
perfect for, and started work somewhere around v0.4.

Node.js (or any single-process paradigm) brings some design challenges. For 
instance, in my application, I can't make the assumption that all 
legitimate requests will only use a certain amount of memory — some 
applications may require streaming an indefinite amount of data, for 
instance. However, handling multiple requests per process means the total 
resource usage of a single request can't be limited, at least by the OS. 
The only solution I know of so far is, for every attacker, to make sure 
that the non-generic attack of growing the process's memory to the point of 
crashing is more expensive than a simple, generic DOS.

I also don't want to make any assumptions how the application might be 
used, I can't assume that only Jade or MongoDB will be used, for instance 
(even if they are natively supported).

Here's my implementation: Magnode.org <https://magnode.org/>. It's designed 
as a framework, with a simple default application that tries to cover most 
use cases. It uses many other libraries, particularly ones I had to write, 
like rdf <https://github.com/Acubed/node-rdf>, 
jsonschema<https://github.com/Acubed/jsonschema>, 
and contenttype <https://github.com/Acubed/contenttype>.

It works on the notion that a user requests a resource, the resource is 
identified, then formatted into the requested Content-Type (via the Accept 
header or the request URL), usually HTML or JSON, but depending on the 
resource, you might also format e.g. a time series as an image, or a PDF 
file. It's especially designed for graphs of data, like the Web (and 
dereferencing nodes on it, hence the name Magnode).

It's pretty capable right now: You start it up, run through a quick 
web-based installer to initialize the configuration, then you can log in 
and see a front page of blog posts (reverse chronological order), create 
new posts, pages, add items to menus, create new menus, create users, and 
such. With some coding, it should be relatively simple to create a new type 
of output, maybe you want to generate an image from data for instance, this 
should be possible with a fairly short file, maybe 50 lines (it involves 
simply registering a function with a domain of whatever data type you want 
to process, and a range of Document and image/png, or whatever media types 
the output would be).

While presently it only works with MongoDB, it's not designed for a 
specific database (only about a dozen of 88 files are MongoDB-specific), 
and I intend to support a number of data storage schemes. The next storage 
scheme will be HTTP endpoints (effectively making Magnode an HTML frontend 
to an HTTP API). Additionally I would like to see relational databases, an 
IndexedDB-style database (where you query documents using specific indexes 
instead of by their data), and an RDF graph database.

Here are some features that work right now:


   - Make lists and tables of content. The front page, by default, is a 
   list of blog posts.
   - Revisioning of content - documents are only inserted into the database 
   by default.
   - Custom schemas and content types, and custom templates for formatting 
   them.
   - Resources are first-class: Most everything is an HTTP resource, 
   including blog posts, users, the content-types themselves, and even server 
   configuration if so desired. This means a single code base for doing 
   everything related to changing configuration and editing content.
   - Pluggable user authentication and authorization.
   - Content-Type negotiation can return any number of content types with a 
   Content-Location header, XHTML and JSON are supported natively. It also 
   supports most of the HTTP headers like Etag, Accept, If-Match, and similar. 
   This means the server is naively a RESTful HTTP API.


Some use cases that I've designed for, but have yet to implement, are:


   - A better UI for editing structured data and markup: Right now, many 
   operations like adjusting schema definitions requires editing raw JSON.
   - Extensive caching of rendered resources. (Nonetheless, it still 
   performs faster and serves more requests than a comparable installation of 
   Drupal.)
   - Straightforward editing of templates and themes, including compression 
   and aggregation of CSS and JS files.
   - Self-registration and support for third party accounts (log in with 
   OpenID, etc).
   - Content-Type aware formatting of error pages.
   - User comments on resources
   - OAuth (or similar) for delegating access of resources to third parties 
   (bearer tokens with sandbox permissions are already supported or easily 
   implemented).
   - Editing and updating content in-line, and in real time (perhaps 
   integrate the MediaWiki 
VisualEditor<http://www.mediawiki.org/wiki/VisualEditor>). 
   Magnode can update resources with a standard HTML POST form, or a PUT 
   request with a JSON document, but maybe also PUT raw HTML of the edited 
   page, parsing the HTML back into a database record. This would mean editing 
   pages in-line with very little client-side scripting required, and no 
   significant requirement on the server either.
   - Support more data sources as mentioned: relational (SQL), graph (RDF), 
   and resource (HTTP) databases.
   

One cool use case that I've already implemented is using Magnode as a 
gateway that adds an HTML representation of resources to an otherwise JSON 
HTTP API. With this, you can use your web browser as a console to interact 
with the API endpoint.

I'd really appreciate any help that people can offer. If you have MongoDB 
running, take five minutes and go to the "Get Started" 
page<https://magnode.org/download>, 
then let me know what you think. The source is available through the 
website or on GitHub <https://github.com/Acubed/magnode>. It is public 
domain.

Austin Wright.

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to