- Predictable data binding for raw SQL queries (and just a more verbose DSL for the ORM in general - recently used Laravel and I was in awe of how much better it was -- I mean I can't even ask a database how many cats with blue eyes Suzie has without loading the rows into memory)
- Better support for database migrations, and better support for individual databases (generally improved adapters for each database -- composite indexes, and proper data types are two examples here)
- Support for deep relational data fetching
- Support for a LINQ-like IQueryable style of queries (perhaps using promises) -- for those unfamiliar with using LINQ (and specifically do DB operations), LINQ allows you to write and operate on queries with deferred execution until such point that the data is made available. What this roughly translates to is writing code and having it be turned into SQL by the ORM and only querying the database once the entire query has been built.
- Better sockets integration
- Integrated cache
I think this should speak volumes about Sails' readiness for production. I don't mean to harp on Balderdashy, they've done great work - but there's so much more to do. Right now if I wanted to start a new project I'd have a hard time choosing Sails over Laravel. They may be different languages but for many use cases I've seen the same or better performance from Laravel on HHVM. I honestly don't know how anyone can say they're loving it in production while these problems have remained unsolved. Every time I need to do something in my Sails application that strays from the most basic of operations, I end up having to write raw SQL or write a module in order to use sockets in any meaningful way. Personally, I'll be sticking to smaller Node.js libraries for a while yet. Not because I think Sails is bad, but because it's simply not ready.
Sails is very modular, if you wanted to replace the ORM with something else you could just replace the Waterline hook. Waterline is still pretty young and all of these features would be great to get added! We are always looking to add new contributors if anyone would like to help move some of these features along.
1. The site and the courses look great but, why can't I sign up without a Facebook or Twitter account? This one issue was enough for me to leave the site. I compartmentalize my web affairs for many reasons and keeping my online accounts separate is very important for me. I'm writing this to encourage you (and others) to reconsider this practice.
2. I can see the icon that says "Beginner," but that doesn't tell me much. In your FAQ, I would recommend expounding on this. Beginner is too ambiguous.
I'm really glad to see this. I've build a few apps with Sails.js and I LOVE it, but the documentation isn't great, and there hasn't been too many solid learning resources. This is good news.
I'm tuned in and loving the interactive experience so far. Congrats to Team Platzi on creating something that will truly change the future of online learning.
Christian from Platzi. We're creating livestreamed classes with great companies doing stuff for devs, designers and makers. We've had Sam Altman talking about Startups and the guys from Gitlab. Today we have Mike McNeil teaching Sails.js. What else would you like to learn?
The 3 courses that are available in English seem to be freely accessible, but in their FAQ it is mentioned that you require a monthly/yearly subscription [1].
It's free. It is free. We have a subscription plan for long courses on big topics, but haven't launched that yet. This class is free and it'll be free forever. The recorded version too.
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.
We had a live class with Sam Altman two weeks ago. And Gitlab and Sails.js this week. We're almost there for classes with Docker, RethinkDB and Stripe.
And then, we hope to do a full course on either React.js and JS app dev or Social Media Marketing and Community Management. Still debating that. What do you guys think?
Email / password please, before anything else. As a rule I don't signup any service unless it makes me create an account separate from any other one I have. My password manager remembers them for me (keepassx).
- Support for transactions
- Predictable data binding for raw SQL queries (and just a more verbose DSL for the ORM in general - recently used Laravel and I was in awe of how much better it was -- I mean I can't even ask a database how many cats with blue eyes Suzie has without loading the rows into memory)
- Better support for database migrations, and better support for individual databases (generally improved adapters for each database -- composite indexes, and proper data types are two examples here)
- Support for deep relational data fetching
- Support for a LINQ-like IQueryable style of queries (perhaps using promises) -- for those unfamiliar with using LINQ (and specifically do DB operations), LINQ allows you to write and operate on queries with deferred execution until such point that the data is made available. What this roughly translates to is writing code and having it be turned into SQL by the ORM and only querying the database once the entire query has been built.
- Better sockets integration
- Integrated cache
I think this should speak volumes about Sails' readiness for production. I don't mean to harp on Balderdashy, they've done great work - but there's so much more to do. Right now if I wanted to start a new project I'd have a hard time choosing Sails over Laravel. They may be different languages but for many use cases I've seen the same or better performance from Laravel on HHVM. I honestly don't know how anyone can say they're loving it in production while these problems have remained unsolved. Every time I need to do something in my Sails application that strays from the most basic of operations, I end up having to write raw SQL or write a module in order to use sockets in any meaningful way. Personally, I'll be sticking to smaller Node.js libraries for a while yet. Not because I think Sails is bad, but because it's simply not ready.