Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LoopBack, a new Node.js framework by StrongLoop

loopback.io

Post reply on HN
Print view View original

51–60 of 67 posts

Re: LoopBack, a new Node.js framework by StrongLoop

#51

Post by segphault »

angersock wrote: post #45
segphault wrote: post #42

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 a…

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.

Re: LoopBack, a new Node.js framework by StrongLoop

#53

Post by angersock »

segphault wrote: post #51
angersock wrote: post #45

Earlier quoted context omitted.

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…

Thank you!

Re: LoopBack, a new Node.js framework by StrongLoop

#54

Post by kristream »

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.

Re: LoopBack, a new Node.js framework by StrongLoop

#55

Post by woah »

hardwaresofton wrote: post #47
rmgraham wrote: post #35

Earlier quoted context omitted.

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

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.

Re: LoopBack, a new Node.js framework by StrongLoop

#56

Post by nailer »

s_kilk wrote: post #29
Rezo wrote: post #8

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

Re: LoopBack, a new Node.js framework by StrongLoop

#57

Post by whatthemick »

hardwaresofton wrote: post #47
rmgraham wrote: post #35

Earlier quoted context omitted.

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

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

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

Re: LoopBack, a new Node.js framework by StrongLoop

#59

Post by akbar501 »

lobster_johnson wrote: post #27
balls187 wrote: post #18

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

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 expressi…

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

Post reply on HN