mikermcneil

14 ms·

121.
by mikermcneil 14y ago
Totally agree. I created Sails to provide us a clean way of solving the problem of building large projects for our clients.
122.
by mikermcneil 14y ago
Not you though, sounds like!
123.
by mikermcneil 14y ago
lol for anyone else like me who didn't remember the reference, it was back in '08: http://blog.jquery.com/2008/08/29/death-to-javascript-rock-s...
124.
by mikermcneil 14y ago
Hey Peter-- RESTful endpoints are supported. The other options are just there for convenience while testing. You can disable those routes later if you like in your routing table. Policy mapping happens at a controller level to solve this
125.
by mikermcneil 14y ago
Absolutely agree-- Backbone is a great step in the right direction, but it leaves tons of things to chance. We use Mast internally ( https://github.com/balderdashy/mast ) but I'm keeping a close eye on Ember and Angular. Also, if you're a
126.
by mikermcneil 14y ago
eh?
127.
by mikermcneil 14y ago
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, p
128.
by mikermcneil 14y ago
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
129.
by mikermcneil 14y ago
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.
130.
by mikermcneil 14y ago
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 handl