storage Wed, 29 Jul 2015 13:29:00 GMT Wed, 29 Jul 2015 13:29:00 GMT en-us Fargo v1.71 davewiner dave.winer.12 New way to configure nodeStorage <p>New in <a href="">nodeStorage</a> v0.73.</p> <p>I had to switch from <a href="">Heroku</a> to an AWS-hosted Ubuntu server that's hosting a bunch of other apps. Without the isolation that Heroku provides, the <a href="">environment variables</a> 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 <a href="">River4</a> and <a href="">nodeStorage</a>, using a config.json file in the same directory as river4.js.</p> <h4>What's in config.json</h4> <ol> <li><p>enabled</p></li> <li><p>myDomain</p></li> <li><p>s3Path</p></li> <li><p>s3PrivatePath</p></li> <li><p>twitterConsumerKey </p></li> <li><p>twitterConsumerSecret</p></li> <li><p>myPort </p></li> <li><p>urlUserWhitelist </p></li> <li><p>longPollTimeoutSecs</p></li> <li><p>bitlyApiKey</p></li> <li><p>bitlyApiUsername</p></li> </ol> <h4>Three exceptions</h4> <p>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. </p> <ol> <li><p>AWS_ACCESS_KEY_ID</p></li> <li><p>AWS_SECRET_ACCESS_KEY</p></li> <li><p>AWS_REGION</p></li> </ol> <h4>Example</h4> <p>Here's an example, the contents of config.json on my server (with values changed).</p> <p><img src="" width="600" height="189" border="0" style="border: 1px solid silver" alt="A picture named nodeStorageConfig.png"></p> <h4>Update</h4> <p><a href="">nodeStorage v0.77</a> adds two new elements to config.json. </p> Sun, 10 May 2015 13:16:18 GMT How it flows <p>Here's the basic flow for connecting with the Storage server.</p> <ol> <li><p>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. </p></li> <li><p>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).</p></li> <li><p>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. </p></li> <li><p>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. </p></li> </ol> <h4>twUploadFile</h4> <p>Call this API routine to upload a file to the server. </p> <p><code>twUploadFile ("hello.txt", "hello world", "text/plain", false)</code></p> <p>The last param, false, says that the file is not private. </p> <p>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.</p> <p>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.</p> Wed, 10 Dec 2014 16:33:52 GMT What is Storage? <p>Storage is a node.js compatible application that builds on Twitter-based identity to provide per-user storage for web applications.</p> <p>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. </p> <h4>All web apps need storage</h4> <p>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. </p> <p>Good for simple apps, but in order to get real utility, you need more.</p> <h4>Why not use Dropbox?</h4> <p>With <a href="">Fargo</a>, we use Dropbox for storage. It comes with its own identity system. </p> <p>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.</p> <h4>How mature is it?</h4> <p>It's actually pretty mature. It's the storage system behind <a href="">Radio3</a>, <a href="">Little Card Editor</a>, <a href="">Happy Friends</a>. Those products give Storage real-world testing every day.</p> <p>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.</p> <h4>Public and private data</h4> <p>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. </p> Tue, 09 Dec 2014 17:49:22 GMT