3

i m creating application, using nodejs (0.8.15), express (>3.0) framework, socket.io and mongodb for register users.

1) Everyone knows that it is easy to create simple chat using only socket.io, without mongodb (or other). So, in this case where stores the messages? in session?

2) this second question is VERY IMPORTANT for me

i don't understand: why are MongoStore there for sessions? i read that it is "SessionStorage for connect's session middleware/Connect". As i know session destroys when user go away from site. So why do people store it and use require('connect-mongo') ??

var config = require('../config'),
    express = require('express'),
    MongoStore = require('connect-mongo'),
    server = express.createServer();

server.configure(function() {
    server.use(express.logger());
    server.use(express.methodOverride());
    server.use(express.static(config.staticPath));
    server.use(express.bodyParser());
    server.use(express.cookieParser());
    server.use(express.session({
        store: new MongoStore({
            db: config.db
        }),
        secret: config.salt
    }));
});

code i have just found. it seems it is for express 2.x

3) what is the difference between connect-mongo and connect-mongodb libs? https://github.com/masylum/connect-mongodb

https://github.com/kcbanner/connect-mongo

4) do i have to make MongoStore for cookies and sockets?

thank you!

sirjay
  • 1,767
  • 3
  • 32
  • 52

2 Answers2

8

1) Nowhere? Server receives message, broadcasts it and forgets about it. Who sais anything about storing? Server can be just a proxy.

2) Because sessions don't have to be destroyed once a user leaves the site. For example consider a shop. You go to a shop, you put some things in your basket and then you close the browser. After 3 days you go back and you still see your items in the basket. This can only be done with sessions stored in DB ( at least in a reliable way ).

It really depends on your needs. In my case I hardly ever use DB based sessions. I use in-memory storages like Redis.

3) Who knows? Might be some subtle differences, I can't see any obvious.

4) No. As I said: it depends on your needs. If you want sessions to be active only when user is actually viewing the page, then you can stick with any in-memory storage. Or you might not need sessions at all, in which case you don't have to use it at all.

freakish
  • 54,167
  • 9
  • 132
  • 169
  • With 2, session cookies are typically destroyed when the user closes the browser. There are other valid reasons. A. the default memory-store isn't performant when the number of sessions becomes large, and B. app-independent session storage facilitates multi app server deployments. – numbers1311407 Nov 28 '12 at 22:48
  • thank you for answer. for 2): how to know when session will be destroyed? in how many hours/days? but WHERE stores this session? in my nodejs server? or in users browser? by the way, i thought an example with basket can be implemented with simple cookies and that's all. – sirjay Nov 28 '12 at 23:41
  • @numbers1311407 I agree that they are typically destroyed when the user closes the browser. As for performance: when the activity is huge, then one database server is obviously not performant as well. You have to scale anyway. As for app-independent session storage, well, database is app-independent, isn't it? – freakish Nov 29 '12 at 09:18
  • @NikitaSushko A) Sessions are destroyed when they are destroyed. :) It's a matter of design. B) You can store sessions wherever you want: in database, in cookies, in Redis or even in NodeJS server, it's a matter of design as well. C) Using cookies for storing data is not secure and not efficient. Read this article for more info: http://wonko.com/post/why-you-probably-shouldnt-use-cookies-to-store-session-data – freakish Nov 29 '12 at 09:21
  • @freakish Yeah you may have to scale up from one session database, but my point was that you can't do that with MemoryStore sessions without adding more app servers, which *is* the second point: a database is app-independent allowing you to scale it independently, and for it to be shared between apps. I was agreeing with you, just saying there are more reasons :-) – numbers1311407 Nov 29 '12 at 16:07
  • @numbers1311407 Oh, sorry, for some reason I thought you are talking about Redis. I stand corrected. :) – freakish Nov 29 '12 at 16:16
4

1) If you don't want to use a database for your chat, you should store the messages into a simple hash. But keep in mind, if you restart your node application, they will be lost.

2) MongoStore (or RedisStore) allows you to store the Express sessions into MongoDB/Redis instead of using the MemoryStore, which is not designed for a production environment.

(by the way the code you've found is for Express 2.x)

3) The two looks similar. Personnally I use connect-mongo.

4) No. Express handles the session cookies for you, and Socket.IO the sockets. If you want to work with MongoDB, you should try Mongoose http://mongoosejs.com/

Maxence De Rous
  • 158
  • 1
  • 2
  • 5
  • thank you for answer. for 2): you wrote "..instead of using the MemoryStore". what is MemoryStore? is it memory of my nodejs application? or my browser cache? – sirjay Nov 28 '12 at 23:45
  • You're welcome. MemoryStore is a store for development use only, bundled with Express. You don't need to have a database to use it. – Maxence De Rous Nov 29 '12 at 00:00
  • Your sessions will be stored in a database such as Redis or MongoDB if you use connect-mongo or connect-redis. So you need to set up a database on your server ;) With connect-mongodb you can pass a reapInterval. Also with Express, you can pass a maxAge attribute to express.session() – Maxence De Rous Nov 29 '12 at 00:04