Dispatch rules in riak

Kevin Smith ksmith at basho.com
Thu Feb 4 14:55:48 EST 2010


That would work as long as "foward all REST calls through riak_client" means making the appropriate riak_client calls (put, get, delete, etc) inside your resource and not forwarding the actual HTTP processing.

--Kevin
On Feb 3, 2010, at 12:41 PM, Alan McKean wrote:

> I thought I might just put the riak code in my webmachine load path and then forward all REST calls through riak_client and handle all other routes on my own. Any problems with that?
> 
> On Feb 3, 2010, at 8:42 AM, Kevin Smith wrote:
> 
>> Alan - 
>> 
>> It depends on the shape of your application, I think. If your URLs are going to strongly resemble Riak's REST API then, yes, you would wind up with some duplication. One way to avoid the duplication would be to write a resource which serves as a proxy to Riak. Bryan Fink wrote a webmachine resource to proxy to the Jiak interface which is available here:
>> 
>> http://hg.basho.com/riak/src/9030e5932b15/demo/stickynotes/src/jiak_proxy_ibrowse.erl
>> 
>> While the raw interface is rapidly becoming the preferred way to interact with Riak, this code should give you an idea of what's involved.
>> 
>> --Kevin
>> On Feb 3, 2010, at 11:10 AM, Alan McKean wrote:
>> 
>>> Kevin --
>>> 
>>> Thanks for the quick response ... I still have a question about this strategy.
>>> 
>>> If I implement the application in webmachine and call to the riak cluster with riak_client, won't I have to replicate the code that is in raw_http_resource.erl in my webmachine app when I want to hit it with requests that put data into riak? That was what made me wonder if I shouldn't simply add routes to Riak that could handle other types of requests other than 'raw'; e.g., requests for static files or data generated algorithmically.
>>> 
>>> --Alan
>>> 
>>> On Feb 2, 2010, at 8:27 PM, Kevin Smith wrote:
>>> 
>>>> Alan -
>>>> 
>>>> My preference in the situation you describe would be to write the application using webmachine and deploy it separately from the Riak cluster. Separating the application from the Riak cluster permits both components to be upgraded separately and at different times.
>>>> 
>>>> As for interacting with Riak from your application, the riak_client module is a better choice. It provides access to all of Riak's features with the low overhead since the client and server are both implemented in Erlang.
>>>> 
>>>> Does this answer your questions?
>>>> 
>>>> --Kevin
>>>> On Feb 2, 2010, at 8:35 PM, Alan McKean wrote:
>>>> 
>>>>> I have been trying to set up my own routing rules to allow for serving up static files alongside the dynamic data that I server up from Riak, and any help will be greatly appreciated.
>>>>> 
>>>>> While there was a demo in previous versions of Riak taht showed how the dispatch map was set up (stickynotes), the latest version seems to not have a similar example. There is an example ('demo') in the apps/webmachine directory, and it shows how to set up dispatch rules in the webmachine_demo_sup:init/1, but it seems to have no relationship to riak. Can someone inform me about how to set up my own routes in Riak?
>>>>> 
>>>>> A related question regards architecture: is it preferable to have separate webmachine instances that are calling and load-balancing across a tier of Riak servers (via http or riak_client calls) or to embed your application in the Riak instances themselves and hitting them directly from the browsers? The question that I posed above relates to putting app logic in the Riak instances and controlling the routing to that logic. The other approach (fronting the Riak instances with Webmachine instances would either using http REST or duplicating code that exists in Riak for converting the incoming request data (e.g., json) to the raw_resource format that riak_client calls use.
>>>>> 
>>>>> Thanks
>>>>> Alan
>>>>> 
>>>>> _______________________________________________
>>>>> riak-users mailing list
>>>>> riak-users at lists.basho.com
>>>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>>> 
>>> 
>> 
> 




More information about the riak-users mailing list