7 ms·

Strata Web Framework

66 points by telemachos 15y ago

Roboprog 15y ago
I'm still pretty new to the idea of node.js, but a couple things stand out to me. This framework uses a session cookie as a way to store some data, not just as a user/session id/authentication. Thus, they seem to be strongly pushing you towards an external session store such as memcached or a database. (I suppose that is an inherit limitation of node.js, at least as commonly used) From what I understand, a Node/V8 instance really only utilizes a single CPU, yes? As a request does I/O, some other piece of code is executed until (some time after) the async I/O completes. A CPU can be effectively timesharing over several pseudo-threads, but to use a SMP chip/server, you have to run multiple instances, with a front-end load balancer. I guess this would drive one towards an external session data solution, barring some kind of sticky session and a reason to be sticky.
- bretthoerner 15y ago
  Isn't an external session store practically mandatory regardless of your backend? I'm no fan of Node, but even if you have $100k machine running the JVM with a thousand threads you will (if successful) eventually need a second machine, and a third, etc. Not to mention persistence (what if you need to restart the app server?). Sessions belong in a database of some kind unless you can get away with signed cookies.
  - mahmud 15y ago
    no it's not mandatory. We use Play and it's super stateless. nothing more than client side cookies. forced us into scalable, share nothing design. love it! http://playframework.org/ http://playframework.org/ for java and scala
    - SkyMarshal 15y ago
      The Lift web framework does this too, as does Apple's Web Objects. David Pollack, creator of Lift, wrote a good explanation of the benefits on Quora, will post it shortly.
      - bronson 15y ago
        EDIT: Strata ships with cookie-based sessions but it's pretty easy to write your own storage middleware: var app = strata.redisSession(app, options); After seeing how awesome the default cookie-based sessions are in Rails, I'm not sure I'd ever care to go back. Maybe for a high security banking app where breaking the cookie encryption could have catastrophic, permanent repercussions? Short of that, load balancing shared-nothing cookie-based sessions is a joy. Gotta agree with the Lift guys there.
      - SkyMarshal 15y ago
        Can't edit my post, so here's David's case (in comments under Jackson Davis's answer): http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-app-in-Scala-using-Lift http://www.quora.com/What-are-the-advantages-and-disadvantag... "In practice, scaling a Lift site is much much easier than scaling a LAMP site. Why? Well, state exists someplace. If it exists in the JVM, you get a lot of performance benefits and stability as well as, in Lift's case, lots of security. Contrast that with sessions in memcached. "Whoop, memcached went down, there go a pile of sessions." "Whoops, we've got a new memcached hashing algorithm, there go all the session." "Whoops, Google just crawled us creating 200,000 new sessions pushing all the but the active sessions out of cache." "Whoops, the Ruby runtime just went wild, ate all the VM on one of our boxes, memcached went down..." So, you try storing sessions in some wacky shared version of MySQL. This solution requires tons of hardware and a team of make sure that the sharing code is correct, etc. Contrast that to using Nginx, Jetty and session affinity. It's about 4 hours of setup time and it just works. See http://blog.harryh.org/post/7550.. http://blog.harryh.org/post/7550... So, talk to a Facebook engineer about the challenges they go through to manage state between the front end, memcached, MySQL, etc. Compare that to Twitter with the famous fail whale. Compare that to Apple's store and the iTunes store which are written on WebObject (which is highly stateful.) Lift apps running at scale typically require 7% of the front end resources of LAMP app. The Lift apps that are running at scale (Foursquare and Novell pulse are two) do not have the kind of scaling issues associated with LAMP sites that have similar traffic patterns. Scaling with Lift is neither tricky, nor risky. It's simple. It's known. It's proven. Scaling with LAMP is playing whack-a-mole with state and that only becomes a problem at scale."
    - hello_moto 15y ago
      I assume play does not use DB pooling if it is a pure 100% share-nothing design?
  - olegp 15y ago
    Java web app containers support distributed session stores.
- judofyr 15y ago
  All the session data is stored (and signed) in a cookie on the client side. Why would you need an external session store then? Isn't it more like the opposite; with this solution you never need an external session store, no matter how many instance you run?
  - joeyespo 15y ago
    I think he means that by using cookies, you're constrained to their limits. So if you have a large amount of data to pass around, you'll be forced into something external.
- mjijackson 15y ago
  The fact that Strata uses cookies for sessions is just a personal preference, and certainly isn't something that is forced upon you. It would not be very difficult to add support for file or database-backed sessions into the core distribution.
moomin 15y ago
I guess the obvious question is: what does this offer that you don't get from connect/express?
- bfm 15y ago
  From the official announcement https://groups.google.com/forum/m/#!topic/nodejs/fqBTNLwhEAI https://groups.google.com/forum/m/#!topic/nodejs/fqBTNLwhEAI The main advantages/differences over Connect/Express at this point are: - Patterned after WSGI/Rack. This implies some significant differences in the API. - Built on node 0.4; takes full advantage of streams. - Built-in support for streaming multipart parsing/file uploading (uses node-formidable's parser). - Built-in support for gzip encoding, URL rewriting, and URL mapping. - RFC-compliant support for content negotiation using the Accept, Accept-Language, Accept-Encoding, and Accept-Charset HTTP headers. - A specification with middleware to enforce it.
  - dreamdu5t 15y ago
    So nothing? Streams, multiparts, gzip, that is all in Connect/Express. I'm sorry but adhering to some spec that few people use or care about is hardly an advantage over Connect. Wouldn't it be trivial for Connect to adhere to the spec anyways? tjholowaychuk has done extensive testing/benchmarking of Connect/Express. I'd really like to see some benchmarks and code coverage.
- theyCallMeSwift 15y ago
  +1 for wanting a solid answer to this question
  - mjijackson 15y ago
    Connect/Express do little more than set up a callback chain for you that passes along the request and response objects it received from node's request listener. Strata gives you a sane environment modeled after the WSGI/Rack/CGI model, which has been the backbone of web servers for years. Also, Strata's API matches the WSGI/Rack model. This may seem small, but in practice it's a significant benefit. Add to that the list of features cited in the release email, including native support for streams in node 0.4.
kainosnoema 15y ago
To be honest, this doesn't look like much of a web framework. The examples show views being built up using string concatenation... reminds of my pre-templating days building snippets for jQuery. Really though, everything shown can be easily replicated with a bit of Connect middleware, and it'd be cleaner. I don't see the point?
- hello_moto 15y ago
  Node.js is the new hotness, you've gotta write a framework (as opposed to tools that analyze JS code and point out potential pitfalls and bugs, or tools to build and deploy complex JS solutions, or tools/framework that support better unit-testing for JS both server and cliend-side) to get street-creds these days.
- skeptical 15y ago
  I would go as far as saying that it does not offer much more than what you can do with the http module. But if you take away built-in template engines, orm, active reccord and an CRUD generators (both for web forms and APIs), the same applies to 90% of the frameworks out there. I work with pretty messy code bases and every other week find myself wondering if using a framework did really helped more than it introduced unnecessary code.
  - mjijackson 15y ago
    That's like saying that WSGI/Rack don't do anything more for Python/Ruby than their respective HTTP libraries. When you understand the rationale behind those libraries you'll understand Strata.
    - skeptical 15y ago
      No. Node.js itself is an event machine, node's http module is nothing but a particular plug-able even handler framework. That is not the same writting an application in python that uses the http library. The latest requires considerably more work, the prior is much simpler.
  - 15y ago
joeyespo 15y ago
At first glance, looks like it's a Flask for JavaScript.
- mjijackson 15y ago
  At this point I'd actually compare it more closely with Werkzeug (http://werkzeug.pocoo.org/ http://werkzeug.pocoo.org/).
  - joeyespo 15y ago
    Yeah, you're right, there's no built-in templating in this.
wavephorm 15y ago
Server nginx/0.7.67 I can't tell if it's the case here, but I get a little unnerved when a web framework doesn't even use it for their website.
- RyanMcGreal 15y ago
  They're two different use cases. If I invented a new kind of rocket, I probably wouldn't use it to go to the store and pick up milk.
  - thirteenpixels 15y ago
    Unless you really needed milk...
  - deleted 15y ago
    [deleted]
- mjijackson 15y ago
  Strata definitely does eat its own lunch. :) You can view the source of the website here: https://github.com/mjijackson/stratajs.org https://github.com/mjijackson/stratajs.org The Server header reports nginx because it's sitting behind a reverse proxy on Heroku.
  - wavephorm 15y ago
    Cool, yeah I'd link this from the website because it's good to see how a real site would be built with it.
- deleted 15y ago
  [deleted]
tlrobinson 15y ago
It's unfortunate this doesn't just use JSGI, which is much closer to Rack/WSGI than Connect, and has a fair amount of usage in Node (https://github.com/joyent/node/wiki/modules#wiki-middleware-jsgi https://github.com/joyent/node/wiki/modules#wiki-middleware-...), as well as other server-side JavaScript platforms (Ringo, Akshell, Pintura, Narwhal) I'd love to hear the reasoning for the differences between the two. (Disclaimer: I started JSGI)
- mjijackson 15y ago
  JSGI is not able to take advantage of node's ability to serve responses asynchronously because the spec doesn't allow for it. JSGI specifies that the return value of an app must be the [status, headers, body], whereas Strata specifies that the return value of an app is not important and that the app's callback should be used to serve the response instead. This is an API incompatibility that cannot be ignored. The most developed lib I've seen up to this point to get JSGI working on node (https://github.com/kriszyp/jsgi-node https://github.com/kriszyp/jsgi-node) isn't able to get asynchronous responses working properly. Instead, it just does a body.forEach (see https://github.com/kriszyp/jsgi-node/blob/master/lib/jsgi-node.js#L167 https://github.com/kriszyp/jsgi-node/blob/master/lib/jsgi-no...) to write each piece out to the response synchronously. Copied and pasted from https://github.com/mjijackson/strata/issues/2 https://github.com/mjijackson/strata/issues/2.
  - olegp 15y ago
    My JSGI implementation in Common Node (https://github.com/olegp/common-node https://github.com/olegp/common-node) uses node-fibers allowing it to stream out responses without blocking the event loop. In fact, by connecting an input stream to an output stream (forEachable objects), the underlying code automatically enables Node's pipe like behavior. Check out this example: https://github.com/olegp/common-node/blob/master/examples/http.js https://github.com/olegp/common-node/blob/master/examples/ht...
    - mjijackson 15y ago
      Even so, this breaks down with JSGI middleware that depends on running in a Java environment. For example, JSGI's gzip middleware uses Java's byte buffers.
clyfe 15y ago
I find it similar to connect/express http://expressjs.com/guide.html http://expressjs.com/guide.html but a less tasty DSL and nothing new, or am I missing something? I'm sure one inspired the other since the API is strikingly similar (app.use app.get etc), strange that no comparison is given. Anyway, kudos to the devs for free software!
- wavephorm 15y ago
  Having worked with Node for a while now, I can conclusively say it's difficult to say you know it well without building your own framework. Even if you end up with something similar to another framework it's still worthwhile doing just for the educational aspect.
- mjijackson 15y ago
  Thanks! I think if you dig in and actually write something with if you'll soon see that the differences are subtle, but significant.
pkulak 15y ago
A callback just to get the request parameters out of the environment? What could they possibly be doing in there that blocks?
- mjijackson 15y ago
  Parsing multipart requests and saving uploaded files to temporary files on disk. Large request bodies emit data multiple times.
foobarbazetc 15y ago
performant is not a word.
frenchfries 15y ago
looks pretty cool to me, nice job

66 points by telemachos 15y ago

I'm still pretty new to the idea of node.js, but a couple things stand out to me. This framework uses a session cookie as a way to store some data, not just as a user/session id/authentication. Thus, they seem to be strongly pushing you towards an external session store such as memcached or a database. (I suppose that is an inherit limitation of node.js, at least as commonly used) From what I understand, a Node/V8 instance really only utilizes a single CPU, yes? As a request does I/O, some other piece of code is executed until (some time after) the async I/O completes. A CPU can be effectively timesharing over several pseudo-threads, but to use a SMP chip/server, you have to run multiple instances, with a front-end load balancer. I guess this would drive one towards an external session data solution, barring some kind of sticky session and a reason to be sticky.

bretthoerner 15y ago
Isn't an external session store practically mandatory regardless of your backend? I'm no fan of Node, but even if you have $100k machine running the JVM with a thousand threads you will (if successful) eventually need a second machine, and a third, etc. Not to mention persistence (what if you need to restart the app server?). Sessions belong in a database of some kind unless you can get away with signed cookies.
- mahmud 15y ago
  no it's not mandatory. We use Play and it's super stateless. nothing more than client side cookies. forced us into scalable, share nothing design. love it! http://playframework.org/ http://playframework.org/ for java and scala
  - SkyMarshal 15y ago
    The Lift web framework does this too, as does Apple's Web Objects. David Pollack, creator of Lift, wrote a good explanation of the benefits on Quora, will post it shortly.
    - bronson 15y ago
      EDIT: Strata ships with cookie-based sessions but it's pretty easy to write your own storage middleware: var app = strata.redisSession(app, options); After seeing how awesome the default cookie-based sessions are in Rails, I'm not sure I'd ever care to go back. Maybe for a high security banking app where breaking the cookie encryption could have catastrophic, permanent repercussions? Short of that, load balancing shared-nothing cookie-based sessions is a joy. Gotta agree with the Lift guys there.
    - SkyMarshal 15y ago
      Can't edit my post, so here's David's case (in comments under Jackson Davis's answer): http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-app-in-Scala-using-Lift http://www.quora.com/What-are-the-advantages-and-disadvantag... "In practice, scaling a Lift site is much much easier than scaling a LAMP site. Why? Well, state exists someplace. If it exists in the JVM, you get a lot of performance benefits and stability as well as, in Lift's case, lots of security. Contrast that with sessions in memcached. "Whoop, memcached went down, there go a pile of sessions." "Whoops, we've got a new memcached hashing algorithm, there go all the session." "Whoops, Google just crawled us creating 200,000 new sessions pushing all the but the active sessions out of cache." "Whoops, the Ruby runtime just went wild, ate all the VM on one of our boxes, memcached went down..." So, you try storing sessions in some wacky shared version of MySQL. This solution requires tons of hardware and a team of make sure that the sharing code is correct, etc. Contrast that to using Nginx, Jetty and session affinity. It's about 4 hours of setup time and it just works. See http://blog.harryh.org/post/7550.. http://blog.harryh.org/post/7550... So, talk to a Facebook engineer about the challenges they go through to manage state between the front end, memcached, MySQL, etc. Compare that to Twitter with the famous fail whale. Compare that to Apple's store and the iTunes store which are written on WebObject (which is highly stateful.) Lift apps running at scale typically require 7% of the front end resources of LAMP app. The Lift apps that are running at scale (Foursquare and Novell pulse are two) do not have the kind of scaling issues associated with LAMP sites that have similar traffic patterns. Scaling with Lift is neither tricky, nor risky. It's simple. It's known. It's proven. Scaling with LAMP is playing whack-a-mole with state and that only becomes a problem at scale."
  - hello_moto 15y ago
    I assume play does not use DB pooling if it is a pure 100% share-nothing design?
- olegp 15y ago
  Java web app containers support distributed session stores.
judofyr 15y ago
All the session data is stored (and signed) in a cookie on the client side. Why would you need an external session store then? Isn't it more like the opposite; with this solution you never need an external session store, no matter how many instance you run?
- joeyespo 15y ago
  I think he means that by using cookies, you're constrained to their limits. So if you have a large amount of data to pass around, you'll be forced into something external.
mjijackson 15y ago
The fact that Strata uses cookies for sessions is just a personal preference, and certainly isn't something that is forced upon you. It would not be very difficult to add support for file or database-backed sessions into the core distribution.

moomin 15y ago

I guess the obvious question is: what does this offer that you don't get from connect/express?

bfm 15y ago
From the official announcement https://groups.google.com/forum/m/#!topic/nodejs/fqBTNLwhEAI https://groups.google.com/forum/m/#!topic/nodejs/fqBTNLwhEAI The main advantages/differences over Connect/Express at this point are: - Patterned after WSGI/Rack. This implies some significant differences in the API. - Built on node 0.4; takes full advantage of streams. - Built-in support for streaming multipart parsing/file uploading (uses node-formidable's parser). - Built-in support for gzip encoding, URL rewriting, and URL mapping. - RFC-compliant support for content negotiation using the Accept, Accept-Language, Accept-Encoding, and Accept-Charset HTTP headers. - A specification with middleware to enforce it.
- dreamdu5t 15y ago
  So nothing? Streams, multiparts, gzip, that is all in Connect/Express. I'm sorry but adhering to some spec that few people use or care about is hardly an advantage over Connect. Wouldn't it be trivial for Connect to adhere to the spec anyways? tjholowaychuk has done extensive testing/benchmarking of Connect/Express. I'd really like to see some benchmarks and code coverage.
theyCallMeSwift 15y ago
+1 for wanting a solid answer to this question
- mjijackson 15y ago
  Connect/Express do little more than set up a callback chain for you that passes along the request and response objects it received from node's request listener. Strata gives you a sane environment modeled after the WSGI/Rack/CGI model, which has been the backbone of web servers for years. Also, Strata's API matches the WSGI/Rack model. This may seem small, but in practice it's a significant benefit. Add to that the list of features cited in the release email, including native support for streams in node 0.4.

kainosnoema 15y ago

To be honest, this doesn't look like much of a web framework. The examples show views being built up using string concatenation... reminds of my pre-templating days building snippets for jQuery. Really though, everything shown can be easily replicated with a bit of Connect middleware, and it'd be cleaner. I don't see the point?

hello_moto 15y ago
Node.js is the new hotness, you've gotta write a framework (as opposed to tools that analyze JS code and point out potential pitfalls and bugs, or tools to build and deploy complex JS solutions, or tools/framework that support better unit-testing for JS both server and cliend-side) to get street-creds these days.
skeptical 15y ago
I would go as far as saying that it does not offer much more than what you can do with the http module. But if you take away built-in template engines, orm, active reccord and an CRUD generators (both for web forms and APIs), the same applies to 90% of the frameworks out there. I work with pretty messy code bases and every other week find myself wondering if using a framework did really helped more than it introduced unnecessary code.
- mjijackson 15y ago
  That's like saying that WSGI/Rack don't do anything more for Python/Ruby than their respective HTTP libraries. When you understand the rationale behind those libraries you'll understand Strata.
  - skeptical 15y ago
    No. Node.js itself is an event machine, node's http module is nothing but a particular plug-able even handler framework. That is not the same writting an application in python that uses the http library. The latest requires considerably more work, the prior is much simpler.
- 15y ago

joeyespo 15y ago

At first glance, looks like it's a Flask for JavaScript.

mjijackson 15y ago
At this point I'd actually compare it more closely with Werkzeug (http://werkzeug.pocoo.org/ http://werkzeug.pocoo.org/).
- joeyespo 15y ago
  Yeah, you're right, there's no built-in templating in this.

wavephorm 15y ago

Server nginx/0.7.67 I can't tell if it's the case here, but I get a little unnerved when a web framework doesn't even use it for their website.

RyanMcGreal 15y ago
They're two different use cases. If I invented a new kind of rocket, I probably wouldn't use it to go to the store and pick up milk.
- thirteenpixels 15y ago
  Unless you really needed milk...
- deleted 15y ago
  [deleted]
mjijackson 15y ago
Strata definitely does eat its own lunch. :) You can view the source of the website here: https://github.com/mjijackson/stratajs.org https://github.com/mjijackson/stratajs.org The Server header reports nginx because it's sitting behind a reverse proxy on Heroku.
- wavephorm 15y ago
  Cool, yeah I'd link this from the website because it's good to see how a real site would be built with it.
deleted 15y ago
[deleted]

tlrobinson 15y ago

It's unfortunate this doesn't just use JSGI, which is much closer to Rack/WSGI than Connect, and has a fair amount of usage in Node (https://github.com/joyent/node/wiki/modules#wiki-middleware-jsgi https://github.com/joyent/node/wiki/modules#wiki-middleware-...), as well as other server-side JavaScript platforms (Ringo, Akshell, Pintura, Narwhal) I'd love to hear the reasoning for the differences between the two. (Disclaimer: I started JSGI)

mjijackson 15y ago
JSGI is not able to take advantage of node's ability to serve responses asynchronously because the spec doesn't allow for it. JSGI specifies that the return value of an app must be the [status, headers, body], whereas Strata specifies that the return value of an app is not important and that the app's callback should be used to serve the response instead. This is an API incompatibility that cannot be ignored. The most developed lib I've seen up to this point to get JSGI working on node (https://github.com/kriszyp/jsgi-node https://github.com/kriszyp/jsgi-node) isn't able to get asynchronous responses working properly. Instead, it just does a body.forEach (see https://github.com/kriszyp/jsgi-node/blob/master/lib/jsgi-node.js#L167 https://github.com/kriszyp/jsgi-node/blob/master/lib/jsgi-no...) to write each piece out to the response synchronously. Copied and pasted from https://github.com/mjijackson/strata/issues/2 https://github.com/mjijackson/strata/issues/2.
- olegp 15y ago
  My JSGI implementation in Common Node (https://github.com/olegp/common-node https://github.com/olegp/common-node) uses node-fibers allowing it to stream out responses without blocking the event loop. In fact, by connecting an input stream to an output stream (forEachable objects), the underlying code automatically enables Node's pipe like behavior. Check out this example: https://github.com/olegp/common-node/blob/master/examples/http.js https://github.com/olegp/common-node/blob/master/examples/ht...
  - mjijackson 15y ago
    Even so, this breaks down with JSGI middleware that depends on running in a Java environment. For example, JSGI's gzip middleware uses Java's byte buffers.

clyfe 15y ago

I find it similar to connect/express http://expressjs.com/guide.html http://expressjs.com/guide.html but a less tasty DSL and nothing new, or am I missing something? I'm sure one inspired the other since the API is strikingly similar (app.use app.get etc), strange that no comparison is given. Anyway, kudos to the devs for free software!

wavephorm 15y ago
Having worked with Node for a while now, I can conclusively say it's difficult to say you know it well without building your own framework. Even if you end up with something similar to another framework it's still worthwhile doing just for the educational aspect.
mjijackson 15y ago
Thanks! I think if you dig in and actually write something with if you'll soon see that the differences are subtle, but significant.

pkulak 15y ago

A callback just to get the request parameters out of the environment? What could they possibly be doing in there that blocks?

mjijackson 15y ago
Parsing multipart requests and saving uploaded files to temporary files on disk. Large request bodies emit data multiple times.

foobarbazetc 15y ago

performant is not a word.

frenchfries 15y ago

looks pretty cool to me, nice job