Nitpick, but the "GET /people/{id}/exists" in the example to check if the instance exists is a bit weird, would suggest "HEAD /people/{id}" for this type of operation.
Yeah, the HEAD or GET should return a 404 on not existence; however, the HEAD also won't return data which is the point. GET implies that you have need of the returned data (presumably all the properties of that person). GET is for "it exists AND I want to know about it". HEAD really is more appropriate here.
As someone that is in the middle of writing a nodejs thin API layer, working with express-resource, this looks really amazing to me. It looks like I can stop worrying about writing middle thin-API code, and focus on front-end manipulation of a stable middle/backend
However, the scale of this really worries me. I really like small tools (flask over django, knockoutjs over angular sometimes,etc) -- and this seems like a LOT to take in to a project, sort of hoping it all just works...
Also, why is Postgres support not more prominently stated? It's there, but I had to search for it. And on that note, why is JSON stored in postgres as a varchar? why not use the postgres JSON type (compatibility reasons, maybe?)
I'm actually considering using this in a new project right now - it is very very tempting to think that I could just use this, and have a middle-layer that I don't have to muck with... this would greatly speed up development, I do applaud the team for trying something so ambitious, could be huge
I haven't done much work with a relational DB from nodejs (I've just used nosql databases that offered relational functionality -- i.e. rethinkdb), but this seems like as good a thing as any for ORM-y stuff with Postgres
I feel like you should give a little shout out to the folks over at Wordnik https://github.com/wordnik/swagger-ui for putting together such an awesome API browser.
This looks amazing, and the StrongLoop team is chalked full of some great Node.js developers.
But for some reason I'm still worried about using it as the backbone for an enterprise scale application; it almost does too much. Perhaps I'm just too averse to this amount of "magic" in any piece of infrastructure due to my Django days.
The code is open, but you're not just buying into a single module with a single purpose -- this is an entire architecture. I guess in such cases, worry is warranted before accepted it as the backbone of your company/application.
Off-topic note on "chalked full" - you probably mean chock-full, an old phrase probably derived from the word "choke". I was entertained trying to imagine what a chalk filled team might be though :)
I've seen ton of "expose DB as REST-like API" libraries in various languages, and even tried (unsuccessfully) to write one myself. I'd say just exposing model is trivial, even when coupled with content-type negotiation. Subjectively, the hardest part is permissions (operation, row and field-level ones) and making them play nice with REST and HTTP concepts (like ETags).
I've found that with a stack based around middleware (Express) , that it's now very easy to add open source modules to handle these features for you.
What interests me a lot at the moment are HTTP proxies that provide features like these. I like the encapsulation and scalability that true REST makes easy.
I would say writing the "expose DB as REST-API" can be easy for small projects, but a lot of work can go into making something that is RESTful, scalable, and a joy to build with.
Agree. We try to solve the problems progressively. The connected model support is a foundation to those features. See http://strongloop.com/strongblog/defining-and-mapping-data-r.... Basically, we build models that relate to each other, partition the data graph with links, and expose them as REST APIs that can be used to navigate and aggregate the information from various data sources.
LoopBack is built on top of express. You can use express routing and middleware with LoopBack as is.
Express allows you to expose HTTP endpoints as APIs but it doesn't facilitate the quest to build/aggregate/protect/document APIs that interacts with various backend systems, such as DBs, Cloud services, and internal REST/SOAP APIs. LoopBack is positioned to be a fully-fledged API server with SDKs for JS, iOS, and Android.
This is slick, especially the API explorer, but my biggest gripe about these orm's is that once you get past the very basic CRUD, you need to execute custom sql.
Does it support custom DB types?
For example, I want my primary keys to be bigint on Mysql, and not have to override the underlying dbdriver to do the mapping. I'd prefer to set the appropriate dbtype in the model, and have the driver pass it along directly.
Also does it support dbdriver level SQL query execution?
I have custom aggregation query across a self join, and that's not easily represented with static methods on a model.
Today I use node-orm2, with a custom SQL script that updates the identity columns to be bigints, and it supports executing raw sql queries (with some basic parameter sanitizing).
Has the same problem using Bookshelf (which built on Knex). The query language breaks down almost immediarely. Need to use PostGIS primitives? Awkward. Need to perform aggregate functions with group by, or add dynamically computed columns to the select? Impossible. Subqueries in the select? Nope. Need to order by a function? Impossible, too.
These libraries fail because they are not designed around a logical expression language (unlike Ruby's ARel, a very nice SQL building library that forms the underpinnings of ActiveRecord). You need to be able to programmatically build expressions as an AST which still preserving SQL language rules and avoid exposing yourself to injection.
> The query language breaks down almost immediarely.
Agreed. We dropped an ORM completely and use SQL in functions (aka stored procedures). For models we use plain JS objects and for validation we use Joi (https://github.com/spumko/joi) from Walmart Labs.
Eliminating an ORM has been freeing. We did have to invest in upgrading our team's SQL skills, but we no longer run into limitations of an abstraction layer. Our queries are faster as there are fewer layers. Now that we're up to speed on SQL we find it to be expressive for our data access needs.
2. We allow you to execute native query using
dataSource.connector.query(query, params, cb). We're considering to promote it to dataSource level and fully document it.
Hooks would be nice for this. It's what Kinvey does and I think it's the best option. Want to run a special query or a special function? Have a hook that listens on the related queries, alter anything you like. You should also have direct access to raw database connection there, which is again, what Kinvey does.
For node-based API backends, I've been using Sails.js or Deployd. In addition to providing automatic RESTful CRUD APIs for your data models, both Sails and Deployd also provide WebSocket interfaces that make it really easy to support real-time capabilities without doing any extra work. It doesn't look like LoopBack does that.
I've been particularly happy with Sails.js as the backend framework for my single-page web apps. I get rid of the Sails view system and use it solely as an API backend. The current 0.10 beta, which adds support for associations in data models, is really nice.
* The Sails ORM (which is called Waterline) is very light and simple, but it doesn't have the maturity or the same degree of expressive power that you get with ActiveRecord. Associations were recently added and the query system doesn't really let you take advantage of them quite yet.
* There are also subtle differences in behavior that emerge when you use Waterline with different database adapters, so you really need to develop against the same DB adapter that you intend to use in production.
* When you need to customize the behavior of the CRUD methods that Sails gives you by default (like if you need to transform some parameters passed in by the user in the create method), it is often cleaner and easier to do it by applying custom policy methods rather than overriding the actual CRUD method in the controller.
* For a new Sails project, you probably want to start with the new version 0.10 even though it hasn't been officially released yet.
Those are the points that first come to mind. Despite the limitations, I've found it to be a pretty compelling framework. And it's very actively developed, so a lot of the deficiencies are being corrected.
both are great frameworks, Ritchie was one of the originators of Deployd, LB incorporates lessons learned from Deployd. We have the same WebSocket interface for LoopBack through strong-remoting to support real time. We haven't had time full bake it in, but will soon, especially now finishing up sync and needing server to device push.
Cool! Handling CRUD APIs and authentication desperately needs a flexible library! I can't seem to find any kind of versioning, changelist, etc to facilitate reactive clients tho. Is it lacking or am I not seeing it?
Can you explain about Mongodb support? Does it use mongoose behind? What about if I have my own mongoose model, can I still continue with same?
I did look at loopback a while ago, it was appeared like a parse.com kind of API you host on your own infrastructures. I will reread the documentation again to see if any more clarity on mongodb side.
Spent a minute in confusion of the name: LoopBack. Before I have seen another dev tool/service with exact same domain but it was about recording the interactions history for your iOS app.
Then it occurred to me the iOS rewind service is looKback.io, so close :)
Baucis takes the approach that monolithic frameworks are more costly in time and resources to build software with in all but the short term, and only then sometimes. Long live small libraries!
Putting that conversation aside, I'd be very interested to know what advantages there are for you in having ACL built-in vs. using one of the ACL middleware modules that are available through npm.
Requirements for ACL for json fetching/saving and regular rest endpoints are a bit different, so I couldn't find exact fit so far. In most cases you have to define a function, which become too verbose with very little re-usability.
That been said, there are a lot of node.js modules out there and I could simply miss right one. If you could point to a couple you think might play very well with baucis - I would really love it.
In general most of rest/mvc frameworks our there miss this part entirely. I am ok with acl being not part of particular framework as long as there is at least one 'blessed' combination to use.
= pavel karoukin - author of baucis-access plugin :)
