Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sails.js: Realtime MVC framework for Node.js

balderdashy.github.com

Post reply on HN
Print view View original

51–60 of 107 posts

Re: Sails.js: Realtime MVC framework for Node.js

#51

Post by nilliams »

sideproject wrote: post #32
bunkat wrote: post #4

This looks incredibly cool, but if there is one thing that I've learned, it's that less magic is generally better when building a real production application (vs a weekend project). While typing something like 'sails generate model User' is nice, I literally have no idea what that just did. In the video it then shows a user creating new attributes on the model via a REST API - what??(he even mistakenly adds a bad att…

Couldn't agree more. On a different topic, I've been toying with various JS MVC frameworks, but a lot of them tries to do their "magic" without actually explaining why the magic is necessary. These so called "conventions" at times hide way too many things, it actually makes it frustrating to understand. In the end, my choice came back to Backbone, which is the minimalistic framework. Having said that, I'm trying to p…

The argument (as I see it) against choosing something like Backbone in order to avoid framework "conventions" is that you inevitably end up inventing your own conventions to fill in the gaps.

Fine if you're a one-man team (although still arguably only in the short-term), but if not, all you've done is shifted the "conventions" problem onto your co-workers, only now they have to learn yours, rather than the (hopefully) well documented and worked-out conventions of the framework you tried to avoid to begin with.

(I'm currently using Backbone by the way, but very conscious that it could be a short-sighted approach - basically I'm keeping a keen eye on Ember)!

Re: Sails.js: Realtime MVC framework for Node.js

#53

Post by api »

trungonnews wrote: post #2

I wish more people would read this blog post before writing another MVC framework in Node. http://eflorenzano.com/blog/2010/09/27/why-node-disappoints-...

TFA says "You know what would be awesome? If we wrote our libraries so that they could run either on the server or on the client, and they did so in a transparent way."

Ever tried GWT? I played with it a bit. It gives you One Language -- Java -- and does a pretty good job of it. It comes the closest to accomplishing what the author is talking about.

Unfortunately it puts this huge condom between you and the web medium itself, making design nuance difficult to achieve. But if I had to write, say, an accounting app for a car rental agency I would seriously look at it. It would be a great way to create a solid, stable web thin client app.

Re: Sails.js: Realtime MVC framework for Node.js

#54

Post by apunic »

kaoD wrote: post #18

Judging from the description it does what the other 1000+ Node MVC frameworks do. What's the advantage of Sails over them? CRUD scaffolding is nothing new in Node's ecosystem. Apparently their edge is that users can manipulate the database on their own in the default scaffold? EDIT: Downvote without a comment is not constructive. This is a legitimate question. Care to explain?

Totally agree with you.

Re: Sails.js: Realtime MVC framework for Node.js

#55

Post by mikermcneil »

andypants wrote: post #36
sideproject wrote: post #32

Earlier quoted context omitted.

Couldn't agree more. On a different topic, I've been toying with various JS MVC frameworks, but a lot of them tries to do their "magic" without actually explaining why the magic is necessary. These so called "conventions" at times hide way too many things, it actually makes it frustrating to understand. In the end, my choice came back to Backbone, which is the minimalistic framework. Having said that, I'm trying to p…

Yes, express is very simple, and easy to learn and write. It's also the most popular web framework for node.js. It's less like rails/django and more like sinatra/flask.

Hey guys, I wrote Sails.js. The controllers are just sets of Express middleware. The reason I did it this way is that I wanted a conventional abstraction (MVC) without the burden of a new API.

The only real "magic" here is how Sails handles Socket.io requests using the same controllers. Sails generates req/res objects for socket requests and allows you to handle WebSocket requests in the same code base as the rest of your app. If you need to do more custom stuff, you can still directly access Socket.io through sails.io, and each request object that came from a socket request contains req.socket, which gets you access to the socket which sent the message.

Re: Sails.js: Realtime MVC framework for Node.js

#56

Post by mikermcneil »

nadaviv wrote: post #44
byroot wrote: post #42

Earlier quoted context omitted.

No. Before performing a POST/PUT/DELETE or any other method with side effect to another domain your brother will issue an OPTIONS to get authorization first and will never perform the request if the server do not authorize it. Then if your authentication is cookie based and you allow to delete resource via GET then all the attacker have to do is to insert or tag on any other domain with the proper src attribute to de…

` `s are allowed to send POST requests to wherever they want, without any restrictions. By creating a form that points to another domain, and automatically submitting it, you can send a POST request to wherever you want [1]. POST requests can be easily sent cross-domain. NO ONE SHOULD EVER think that just because he's not using GET requests he's safe from CSRF attacks. [1] See http://jsfiddle.net/8xnB3/5/ for example…

Hi nadaviv, if you don't want to expose those endpoints via GET, you don't have to. Those are set up that way in development so it's much easier to get started. You have full control over your routing table and access control policies.

Re: Sails.js: Realtime MVC framework for Node.js

#57

Post by lukifer »

api wrote: post #49

Node is excellent from an architectural point of view, but I can't get over JavaScript. I really think web developers have Stockholm syndrome with this language.

I actually like Javascript. Aside from all the little warts, the only real problem I see is garbage collection and how easy it is to leak memory. OO does take a little more work, and it'd be nice if modules/dependencies were baked in, but IMO JS passes the Larry Wall test: Easy things are easy, and hard things are possible.

Re: Sails.js: Realtime MVC framework for Node.js

#58

Post by mikermcneil »

mweibel wrote: post #11

I've looked the past week into sails.js. It brings a really cool new way to MVC Frameworks and makes it easy to do certain aspects. What I missed (and that's why I'm using express.js now) is the documentation (lacking) and testability (lacking as well). Also the ORM is really lacking. I'd recommend the authors to look into an existing ORM (sequelize or node-orm2) instead of creating an own one. Sails certainly needs…

Hi mweibel,

I originally used Sequelize, but we wanted (a) noSQL support and (b) a bundled in-memory database.

Waterline has very good test coverage, and it's professionally maintained by my Node.js studio, Balderdash. We invest heavily in its development, because it makes our client projects better and faster.

Happy to answer any other questions about why we built our own ORM.

Re: Sails.js: Realtime MVC framework for Node.js

#60

Post by mikermcneil »

gregr401 wrote: post #10

Cool, looking forward to watching the projects progress! Quick question: when demonstrating the socket.io piece, one aspect that differs with meteor is their ddp which only sends data diffs on a per client basis, not the entire subset as your demo showed. How are you planning to tackle that with any decent about of clients or data size?

Great question! I'm really pumped about more folks getting involved.

First off, you can manage pubsub as you like using Socket.io. The most important thing to realize about Sails is that we're not trying to be Meteor. This is for real, production projects, with a straightforward fallback to trusted technologies. How you manage publish and subscribe is completely up to you-- but if you're using the API blueprint, here's how it works from a pubsub perspective:

GET /user => the socket who issued this request is subscribed to the class room, and the instance rooms for all models returned (until the socket closes)

POST /user => the model created is "introduced" to the class room, subscribing all sockets connected to the class room, to IT. Then, all of the class room subscribers are notified that the new model has been created.

PUT /user/n => sockets subscribed to the instance room for the model being updated receive a message

DELETE /user/n => sockets subscribed to the instance room for the model being deleted receive a message and become unsubscribed

The "magic" here is actually just a controller- you can take a peek here (https://github.com/balderdashy/sails/blob/master/lib/scaffol...) for more about what's going on in the blueprint.

Post reply on HN