My team has been using Sails in production (and at a decent scale) for a while. Though things have improved with 0.10, it's still unfortunately lacking in consistency. When pushing the "limits" of basic things like validations, routing, or more-than-trivial database queries, we've run into quite a few issues that have been reported but completely unresolved - some we've had to work around and others we've learned to live with.
This isn't at all meant to discredit the Balderdashy team - I'm glad the project exists and they're doing good things. However, we've been told that their focus is on their clients and on paying enterprise customers - which is completely understandable - but that leaves groups like us in the large queue of Github issues without any solution or resolution. A lot of what seemed like "useful magic" (blueprints, responses, parameter handling, auto-loading of various components) has turned into unpredictable or broken "magic" as our codebase grows.
I hope that the team has some time to work through their backlog and revisit or replace some of the more lacking pieces. I'd love to see Sails grow into a mature and stable framework in the future.
I've used sails in production on a couple of apps and it's mostly pretty good but there are a couple of annoyances that will inevitably get ironed out as it develops. For me the most irritating thing is being unable to write good unit tests for controllers that use models as sails models are scoped globally and controllers have to be objects which makes injecting mocks difficult. It's great for getting a prototype up and running quickly, but if you're planning on building a big production app, a better longer term strategy would be building an express app from good open source components. (ie using sequelize for ORM). As has been mentioned elsewhere the documentation isn't always consistent and you sometimes find that a waterline function in the documentation has been deprecated in the current stable version, so be prepared to get to know the source well. In any case, it's a great effort and is a great time-saver on getting something live quickly.
While that is a nice separation of concerns (Angular-style), it doesn't solve the problem for unit testing the controller because you still won't be able to inject a mock service into the controller without some beforeEach global variable hackery.
Cool! Thanks for the offer to answer further questions. When I google for sails, as you're probably aware, I come across this article from more than a year ago:
It's a "good, bad, ugly" article, but it's old. Care to comment on any of the issues mentioned in the "bad and ugly" parts. Specifically, I wonder about the (alleged, possibly old) lack of Waterline ORM support for associations / relational data.
I'm hoping that's a softball question. I love seeing new approaches succeed!
Version 0.10 of Waterline now supports associations. It's not as robust as I would like it but its iterative and it's getting better all the time. As for issues piling up thats something that is tough to solve. There are only a handful of us and we try our best to get to issues in a timely manner but like any large open source project it's a battle. Our builds are also passing now :) https://travis-ci.org/balderdashy/sails/builds
Deep relational fetches would be very very helpfull though
Seconded. I'm still early on with a project where we're very close to replacing Waterline for this reason. I always thought ActiveRecord was one of the great strengths of Rails but unfortunately I'm finding Waterline to be the biggest weakness of Sails.
This isn't at all meant to discredit the Balderdashy team - I'm glad the project exists and they're doing good things. However, we've been told that their focus is on their clients and on paying enterprise customers - which is completely understandable - but that leaves groups like us in the large queue of Github issues without any solution or resolution. A lot of what seemed like "useful magic" (blueprints, responses, parameter handling, auto-loading of various components) has turned into unpredictable or broken "magic" as our codebase grows.
I hope that the team has some time to work through their backlog and revisit or replace some of the more lacking pieces. I'd love to see Sails grow into a mature and stable framework in the future.