[Feature Request] Actors as Rack Apps and Middlewares

[pekhee]

A hypothetical example.

CouchDB gets an HTTP request for creating a new resource. CouchDB as a Rack server queues request in a message queue and waits for a response message.

A Rack compatible worker, say Ruby on Rails, reads message queue and applies some logic. Returns new resource as response.

CouchDB gets the response, stores and returns it as HTTP response.

Possible Approach

Rack can define a message structure and let Rack implementation choose protocol and other details.

{
  "env": {
  },
  "headers": [
    { "name": "X-Request-Id", "value": "8fdbaa13-9e21-42d3-82fc-1cd3298c13e7"}
  ],
  "body": ""
}

Benefits

• This provides greater concurrency, assists building distributed applications and highly increases flexibility of a Rack compatible application.
• Multiple applications and middlewares in different codebases and languages can work together to build a response.
• Applications like CouchDB can be extended to apply logic rather than just storing JSON data.

  Notable Mentions

• Spray
• Jackalope
• rack-amqp

[krainboltgreene]

For what it's worth I really like the message structure here.

[Wardrop]

Interesting. I wonder if this imposes any restrictions though, such as the ability to stream or use protocols like WebSockets that don't necessarily conform to a structure like this. I don't think you've given enough detail here. I'm not familiar with CouchDB. I need more technical details as I'm still not sure what problem this is solving exactly.