Single page applications, http or websockets, is connect/express done for?

Question

This is a question involving single page web apps and my question is in bold.

WARNING: I'm hardly an expert on this subject and please correct me if I'm wrong in part of my understanding of how I think HTTP and WebSockets work.

My understanding of how HTTP restful APIs work is that they are stateless. We use tools like connect.session() to interject some type of state into our apps at a higher level. Since every single request is new, we need a way to re-identify ourself to the server, so we create a unique token that gets sent back and forth.

Connect's session middleware solves this for us in a pretty cool way. Drop it into your middleware stack and you have awesome-sauce sessions attached to each request for your entire application. Sprinkle in some handshaking and you can pass that session info to socket.io fairly easily, even more awesome. Use a RedisStore to hold the info to decouple it from your connect/express app and it's even more awesome. We're talking double rainbow awesome here.

So right now you could in theory have a single page application that doesn't depend on connect/sessions because you don't need more than 1 session (initial handshake) when it comes to dealing with websockets. socket.io already gives you easy access to this sessionId, problem solved.

---

Instead of this authentication work flow:

1. Get the email and password from a post request.
2. Query your DB of choice by email to get their password hash.
3. Compare the hashes.
4. Redirect to "OK!" or "NOPE!".
5. If OK, store the session info and let connect.session() handle the rest for the most part.

It now becomes:

1. Listen for a login event.
2. Get the email and password from the event callback.
3. Query your DB of choice by email and get their password hash.
4. Compare the hashes.
5. Emit an "OK!" or "NOPE!" event.
6. If OK, do some stuff I'm not going to think of right now but the same effect should be possible?

---

What else do we benefit from by using connect? Here's a list of what I commonly use:

• logger for dev mode
• favicon
• bodyparser
• static server
• passport (an authentication library that depends on connect/express, similar to what everyauth offers)

The code that loads the initial single page app would handle setting up a static server and favicon. Something like passport might be more tricky to implement but certainly not impossible. Everything else that I listed doesn't matter, you could easily implement your own debug logger for websockets.

Right now is there really anything stopping us from having a single http based index.html file that encapsulates a websocket connection and doesn't depend on connect at all? Would socket.io really be able to make that type of application architecture work without setting up your own HTTP restful API if you wanted a single page app while offering cross brower support through its auto-magical fallbacks?

The only real downside at this point is caching results on the client right? Couldn't you incorporate local storage for that? I think creating indexable/crawlable content pages for search engines wouldn't be THAT big of a deal -- you would basically create a tool that creates static html files from your persistent database right?

Answer 1

Check out Derby and SocketStream.