No subject

Thu Mar 14 15:04:54 GMT 2013

running that delegate all of their work to one or more worker dynos. The 
REST server dynos must be stateless. 

I have two basic patterns to support.

   1. REST RPC. Basically, the client makes a call like GET /user/{id}. I 
   delegate this call to a worker dyno that does a database lookup in the USER 
   table for the specified ID and returns it. The REST interface then returns 
   this. This to me seems like basic RPC. 
   2. REST ASYNC. In this model the client may call my REST server with a 
   POST or a GET. Let's use the classic case of a long running task to format 
   a graphic. I will create a JOB ID, return it to the client in an URI. The 
   client calls the URI to poll the job until it is done and then eventually 
   gets redirected to a URI that has the result. In this case, when I get the 
   initial REST call I will generate a UID for it, submit it to the worker. 
   There are several ways I can do the polling and returning of the result. A 
   lot of that depends on how I decide to interact with the worker.  Is it 
   RPC? AKKA? AMQP?  Because there may be more than one REST service dyno, the 
   request to post the job may happen on one REST server and the polling 
   request may be routed to another. So it must be stateless.

So here's my question. First, should I be using RabbitMQ for this or is 
there a better solution? If I am using RabbitMQ must I implement the RPC 
and ASYNC patterns myself directly on top of RabbitMQ or are there 
libraries out there that create a layer of abstraction on top of RabbitMQ 
so I can do both of these simply? If I'm going to use RabbitMQ I'm hoping 
to use CloudAMQP on Heroku.

Thanks!

Robert

------=_Part_1973_10294539.1370977579935
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I am writing a REST server in Java and am trying to come up with the best a=
pproach for scalability. The server is deployed on Heroku. I am new to Rabb=
itMQ/AMQ so I need some advice.<div><br></div><div>From an architectural po=
int of view I want to have one or more REST dynos running that delegate all=
 of their work to one or more worker dynos. The REST server dynos must be s=
tateless.&nbsp;</div><div><br></div><div>I have two basic patterns to suppo=
rt.</div><div><br></div><div><ol><li><span style=3D"line-height: normal;">R=
EST RPC. Basically, the client makes a call like GET /user/{id}. I delegate=
 this call to a worker dyno that does a database lookup in the USER table f=
or the specified ID and returns it. The REST interface then returns this. T=
his to me seems like basic RPC.&nbsp;</span></li><li><span style=3D"line-he=
ight: normal;">REST ASYNC. In this model the client may call my REST server=
 with a POST or a GET. Let's use the classic case of a long running task to=
 format a graphic. I will create a JOB ID, return it to the client in an UR=
I. The client calls the URI to poll the job until it is done and then event=
ually gets redirected to a URI that has the result. In this case, when I ge=
t the initial REST call I will generate a UID for it, submit it to the work=
er. There are several ways I can do the polling and returning of the result=
. A lot of that depends on how I decide to interact with the worker. &nbsp;=
Is it RPC? AKKA? AMQP? &nbsp;Because there may be more than one REST servic=
e dyno, the request to post the job may happen on one REST server and the p=
olling request may be routed to another. So it must be stateless.</span></l=
i></ol><div><br>So here's my question. First, should I be using RabbitMQ fo=
r this or is there a better solution? If I am using RabbitMQ must I impleme=
nt the RPC and ASYNC patterns myself directly on top of RabbitMQ or are the=
re libraries out there that create a layer of abstraction on top of RabbitM=
Q so I can do both of these simply? If I'm going to use RabbitMQ I'm hoping=
 to use CloudAMQP on Heroku.</div></div><div><br></div><div>Thanks!</div><d=
iv><br></div><div>Robert</div>
------=_Part_1973_10294539.1370977579935--

------=_Part_1972_32952114.1370977579935--