New in nodeStorage v0.73.

I had to switch from Heroku to an AWS-hosted Ubuntu server that's hosting a bunch of other apps. Without the isolation that Heroku provides, the environment variables of all these apps were getting in each others' way. Rather than hack my way through all the arcane rules of environment variables, I decided to create a simpler more reliable (imho) way to configure River4 and nodeStorage, using a config.json file in the same directory as river4.js.

What's in config.json

1. enabled

2. myDomain

3. s3Path

4. s3PrivatePath

5. twitterConsumerKey

6. twitterConsumerSecret

7. myPort

8. urlUserWhitelist

9. longPollTimeoutSecs

10. bitlyApiKey

11. bitlyApiUsername

Three exceptions

If you're using S3 storage, you need to provide the three values for your AWS account. Since the Amazon library is looking for these in environment variables, you must provide them that way.

1. AWS_ACCESS_KEY_ID

2. AWS_SECRET_ACCESS_KEY

3. AWS_REGION

Example

Here's an example, the contents of config.json on my server (with values changed).

Update

nodeStorage v0.77 adds two new elements to config.json.

Here's the basic flow for connecting with the Storage server.

1. When your app starts up, call twGetOauthParams. You'll see how this is connected to the flow in step 4 below. That's the nature of OAuth, you have to understand how it flows before getting started.

2. Call twIsTwitterConnected to see if the user is currently logged into Twitter in your app. If it isn't put up a message saying they have to be logged into Twitter to use your app and provide a way for them to connect (see step 4).

3. If the user is logged into Twitter, get your prefs, open a document, do whatever you want with the storage. You can now make requests that get both public and private info for the user.

4. Suppose you have a button that says Log In To Twitter. When clicked, that button would call twConnectToTwitter, which calls the server which then begins the dance with Twitter. It sends the address of your app to the server, so it can relaunch it after the user authorizes. When that happens your app will pick up the OAuth credentials in step 1 above. Those credentials are kept in localStorage on the user's machine and are parameters to all the API calls.

twUploadFile

Call this API routine to upload a file to the server.

twUploadFile ("hello.txt", "hello world", "text/plain", false)

The last param, false, says that the file is not private.

There's a fifth, optional param, that's a callback that gets a bunch of info about the file, including its URL, if it's public.

BTW, I'm just including this here to give you an idea of how this works. There's a simple example app that illustrates it with working JS code.

Storage is a node.js compatible application that builds on Twitter-based identity to provide per-user storage for web applications.

For example, you could use Storage to build a system like Medium. It would be able to do most of what you need on the back-end for storage.

All web apps need storage

All web apps need to be able to store information on behalf of the user. We've had a couple of different approaches to work with that don't require an identity system -- cookies and local storage. These are good but the data is bound to a machine, not to a person. So if you went to a different machine, you'd have to start over.

Good for simple apps, but in order to get real utility, you need more.

Why not use Dropbox?

With Fargo, we use Dropbox for storage. It comes with its own identity system.

However, when I tried to connect Fargo up to Twitter, all of a sudden there were two OAuth-based identity systems. I had so much trouble keeping track of it, I couldn't imagine most users being willing to go there. One identity system is enough.

How mature is it?

It's actually pretty mature. It's the storage system behind Radio3, Little Card Editor, Happy Friends. Those products give Storage real-world testing every day.

The storage system we use is Amazon S3. The types of storage are the usual types you can store there. Graphics, movies, all kinds of text, JSON, XML, HTML.

Public and private data

Things like your preference settings are private, and HTML rendered from your writing is public. Storage supports both kinds, and the difference is just a boolean on an API call.