From a chat session…

this is a general design principle: Do as much as you can in the browser.

the only way to do that is to have a solid per-resource security model, of course.

this means now that we can build EVERYTHING in html5 and use the server for data management only — exactly how it should be!

now the “server” can be many servers, without using sessions or shared state. the cloud.

if one server dies and its hard drive collapses, no worries! your session is maintained in the browser, NOT using a cookie linked back to a PHP session id

This is called “state” — and it means that what state things are currently in (what actions are being performed, etc) are all being tracked in the application, NOT in the server.

This is a key part of Representational State Transfer (ReST) — state lives in the browser while the application is running, NOT on the server. There is no app running on the server… just data being stored and handed out. Long-running jobs, where required on the server, should be managed with scalable queues and short-running transactions should be used to communicate with them.

This is the foundation of Single Page Apps. For instance, wordpress is mostly an app that runs on the server. twitter is mostly an app that runs in the browser (in the client). This is not to say that an app like wordpress can’t be restful — but if it uses cookies to maintain a session ID that links back to state stored in a session database, then it’s not RESTful.

if you click a link in wordpress admin, it takes you to a different page, generally. In twitter, you’re always on the same page. once it’s loaded, only json is sent back and forth. Either way can be RESTful.

You’re already very familiar with this obviously — what I’m saying is that REST has very specific rules but they’re all wrapped up in a few general principles. (Side note: Single Page Apps that download content via AJAX often have poor SEO.)

For example, principle #1: state is managed on the client. If you want to store state between sessions (between application runs), either write it to the server as just another file or stick it in a cookie on the client (or other local storage like IndexedDB or HTML5 LocalStorage or whatever). State should be handled in the client and, as needed, conveyed completely in the transaction — if you need to connect multiple transactions, provide the server with links to any other resources that it needs to do its job. Why is this? Managing state on the server side does not scale: it adds latency and risks lost transactions.

principle #2: all requests should be short and sweet. No long running processes. Chat sessions should be polling the server for new updates, not just opening a long HTTP (or websockets/COMET) connection and keeping it open. (btw, Websockets/COMET is generally not RESTful.) The exception, of course, is long-running data transfers (such as file xfers)

principle #3: pass authentication credentials with each request. This seems crazy, but not if it’s delivered via SSL. Session timeouts can be handled with HMAC. This derives from principle #1 and #2: do NOT pass a session ID or something that requires you to go look up in a database to figure out what stage you are in a transaction. State should be handled in the client and completely conveyed in the transaction, if required. Always design around that. State lives in the browser, not the server.

Tabs are evil and you should never use them.

In other breaking news, researchers at CERN discovered that four spaces is the correct tab width.

Read more →

Here’s how to create IAM roles using CloudFormation.

After defining the role and creating this CloudFormation stack in your VPC or EC2 network, you can refer to EIPIAMinstanceProfile in other CloudFormation templates or simply manually choose this role from the list when launching a new instance.

If you’re not familiar with CloudFormation, using this is simple. Save the text below to a text file on your system, go to the CloudFormation tab in the AWS console, and Create a new stack. Name the stack anything you like and upload the text file. Don’t forget to check the box that says “I understand this stack may create IAM roles!”

Read more →

If you take any pseudo-random hash such as any fast hash or an insecure cryptographic hash like MD5 (built into most languages such as Python) of any key and just take the first few characters of it — between one and four — and prepend them to your S3 key, then you can achieve millions of operations per second and over a trillion unique keys in your bucket.

Read more →