Nice landing page, I'll give them credit for that. But why would I want to use this instead of Express or Restler?
Loopback is built on top of Express, it'd be sad if they had to reinvent the wheel I reckon
LoopBack, a new Node.js framework by StrongLoop
21–30 of 67 posts
Re: LoopBack, a new Node.js framework by StrongLoop
#22This is very impressive.
Re: LoopBack, a new Node.js framework by StrongLoop
#23Nice landing page, I'll give them credit for that. But why would I want to use this instead of Express or Restler?
It fills the gaps of Express so that you don't have to write so much plumbing.
Re: LoopBack, a new Node.js framework by StrongLoop
#24Cool! 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?
Edit: Whey! http://docs.strongloop.com/display/DOC/Synchronization
Re: LoopBack, a new Node.js framework by StrongLoop
#25Hehe, I owned that domain, loopback.io, a year or two ago. I didn't renew it obviously.
OTOH I still have monospace.io which is a pretty nice domain. Anyone interested?
That would be great for a personal side project of mine, can you email me? Email address on my profile page. Thanks!
Re: LoopBack, a new Node.js framework by StrongLoop
#26This 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.
Re: LoopBack, a new Node.js framework by StrongLoop
#27This 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.…
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.
Re: LoopBack, a new Node.js framework by StrongLoop
#28Nitpick, 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.
Actually the resource should typically 404 to indicate it doesn't exists (generally speaking for http apis).
Re: LoopBack, a new Node.js framework by StrongLoop
#29Nitpick, 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, this is a bit weird. For some reason I'm still surprised when I see pseudo-REST being passed off as RESTful.
Re: LoopBack, a new Node.js framework by StrongLoop
#30Nitpick, 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.
Actually the resource should typically 404 to indicate it doesn't exists (generally speaking for http apis).
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.