LoopBack, a new Node.js framework by StrongLoop | Hacker News Reader

LoopBack, a new Node.js framework by StrongLoop

loopback.io

145 pointslinhmtran16865 comments

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.

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.

HEAD is a good fit. We'll add support for that. Please open github issues to help us track the feature requests or bug fixes at https://github.com/strongloop/loopback/issues.

Yeah, this is a bit weird. For some reason I'm still surprised when I see pseudo-REST being passed off as RESTful.

They have a resource called 'push' too. I don't know what a 'push' is.

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?)

Postgres almost warrants its own non-generic ORM. That would actually be kinda cool.

Hmm....

Especially exposing some of the things like intervals, the geographic features, and a lot of their other cool things.

Yeah, I could live with that.

If I understand your comment right, are you looking for something like this:

http://bookshelfjs.org/

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

The backbone stuff in there kind of made me raise an eyebrow... not sure I really want it.

There's also Sequelize (http://sequelizejs.com/) which is increasing its focus on Postgres specific features.

Good catch. We support Postgresql, MS SQL Server, and SOAP too.

Great!

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 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 :)

Wow, I'm building something a bit similar in the Go area: https://github.com/sergiotapia/paprika

Nice to know it's a good idea that a lot of people will find useful. :) Granted in it's current vision Paprika won't handle authentication.

It's basically an API server in-a-can. Defined your structs, set up your .toml database configuration and paprika.Start("3000") on a port.

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).

etags , hateoas,hypermedia... definetly the hard part,along with security. Getting an API right is hard work.Still search for the holy grail...

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.

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.

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

It fills the gaps of Express so that you don't have to write so much plumbing.

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).

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.

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.

1. We support custom type mappings between JS and DB, see:

http://docs.strongloop.com/display/DOC/Model+definition+refe...

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.

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.

I've been considering using Sails to redo a simple RoR project--mostly to help decrease the number of languages floating around in the project.

Any thoughts/gotchas from your experience with it?

* 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.

Thank you!

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?

Edit: Whey! http://docs.strongloop.com/display/DOC/Synchronization

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.

This framework feels kind of like Rails for REST APIs, but not in a bad way. I really like it so far.

I really like the Angular sdk. I find it really speeds up the process of spinning up a new project

Thanks! Please also check out http://strongloop.com/strongblog/full-stack-javascript-isomo.... LoopBack model APIs can be run inside the browsers too and they are backed by local storage and/or remote data sources. Isomorphic model!

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 :)

Looks really awesome. Building my REST app with Baucis right now and finding ACL built-in is really nice!

Any plans for using Express > 4.x? More and more stuff is targeting Express 4.x these days.

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.

William Riley-Land (Author of baucis)

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 :)

Oh hey, Pavel :)

What're your "killer features" that are lacking for ACL in Node in your experience?

I'm becoming severely intrigued by the idea of using specialized proxy servers for applications like this…

This looks pretty cool! I'll be sure to give it a try. It's a shame that there's no support for Ember though.

Since LoopBack exposes a REST-like API, you should be able to use Ember modules in your client:

http://emberjs.com/guides/models/the-rest-adapter/ http://emberjs.com/api/data/classes/DS.RESTAdapter.html

Gonna give this a go for my next project, I just hope they implement real-time capabilities like Sails/Deployd ASAP

This definitely appears to be the most in-depth and fleshed out Node framework yet. Fantastic docs, too!

Awesome work.

Looks great, but what about validation for the models? Didn't see that mentioned anywhere.

Love the SOAP connector and storage service. Looking for docs around the offline sync support

Hehe, 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!

Stop squatting. You're making the Internet a worse place.

This is very impressive.

What's the Omega in the terminal??

I'm guessing it's just his prompt. The Node/JS community has a bit of thing for using unicode characters everywhere.

Case in point:

https://github.com/mbostock/d3/blob/c247e1626118de41b3d40e2a...

I thought that LoopBack appeared promising until I came across their astroturf campaigns on reddit. That completely turned me off to them.

Can you please provide more information? What campaigns and how did you discover them?

hmm, new? no,good for rest rad yes.

But we still need a nodejs framework for good old html apps with a strong view layer (e.g. forms...).It definetly doesnt exist in nodejs space.

This is obviously geared more toward SPAs which act on APIs.

Seen sails.js? How's it different from what you're looking for?

Didn't we all agree that JavaScript is a bad language for development in large? So why won't we switch to e.g. TypeScript?

Reply on news.ycombinator.com