Working with File Storage and LoopBack

Update for March, 2017: One of the things I mention at the very end of this article is how file uploads will overwrite each other if they use the same name. I fixed this with a pull request that was accepted a few days ago. By using a new configuration option, nameConflict:makeUnique, files will automatically be renamed with a UUID and their original extension. I recommend *always* using this option!

I’ve got a confession to make: I absolutely love LoopBack. How much do I love it? Before I even joined the StrongLoop team at IBM I was blogging on LoopBack and giving presentations on it as well. I basically told the person interviewing me that it didn’t really matter if they hired me or not; I was going to evangelize LoopBack because I thought it was the coolest thing since sliced bread and beer. In general, I love LoopBack and every aspect of it. However, it doesn’t mean that it is perfect. Today I’m going to discuss a feature that is—in my opinion—somewhat “rough”. I’m not saying to avoid it, not at all, just be prepared for a somewhat bumpy ride. Ready?

So, one of the things that LoopBack makes incredibly easy is handling data in a persistence system. You define a model, let’s say Cat, various properties and types, and then LoopBack can handle persisting that in a variety of different storage mechanisms, from Oracle to MySQL to MongoDB. It just plain works, which is cool. However, the data we’re typically dealing with are simple strings represented in JSON. What about binary data?
Read more

Tell us about your LoopBack Node.js Project at Node Interactive North America

If you’re a Node.js developer or engineer using LoopBack, we’d love to talk to you at Node Interactive North America!

Node Interactive NA

Our StrongLoop Video team will be chatting with engineers for about 10-15 minutes to discuss their project and why they are using LoopBack to make it happen. We’d love to share your story too, and we’d like to reward you for your time with a cool IBM backpack stuffed with swag!

Interested? Visit this page, provide your contact information below and we will get in touch!

Using LoopBack to Build APIs For APIs

“Building APIs for APIs” sounds a bit like infinite recursion, but actually I’m talking about one of the cooler aspects of LoopBack: the ability to define a server API that maps to another server. Essentially your API acts as a proxy for another API. There are a lot of reasons you may want to do this, including:

  • Supplementing the set of APIs you already provide. Perhaps you’re a sports company that can provide APIs for every sport but golf. If you can find a third-party provider for golf data, you can then add it to your own library and offer a more complete solution to your users.
  • Modifying API results to fit your needs.  Maybe you want to use an API that is a bit inflexible in the data it returns. By creating your own proxy, you can modify the result sets to return only what you need.
  • To improve performance you can add your own caching layer.
  • Perhaps you want to use an API in your mobile app but don’t want to embed sensitive information, like an API key, in your source code. You can use your own server, and this LoopBack feature, to keep the key hidden in your Node.js code.

Read more

New Life for LoopBack Documentation

There’s an old saying: “Give someone a fish, and they eat for a day; but teach them to fish, and they eat for a lifetime.”  Metaphorically, that’s the value proposition of open-source development: It enables you to take control of your own destiny, to “fish for” (collaborate on) features and changes, instead of merely taking what’s handed to you.

LoopBack has always been an open-source project; the bulk of the documentation, however, has not been.  Now, I’m happy to announce that we’re making the LoopBack documentation open source. We’re in the final stages of moving the LoopBack documentation from – where it was hosted in a commercial wiki and wasn’t generally available for public editing – to, where it will be hosted in GitHub and thus will be open for direct contributions.  Anyone will be able to edit the documentation via pull requests, as they already can do with the software. Read more