Hi Haskell Beginners, I am writing a fairly simple app in haskell that will be used to support some Ruby on Rails apps at work. The gist of it is that it takes a JSON request and produces a JSON response. I've figured that strapping it to a web server will be the easiest way to allow our Rails apps to talk to it without worrying about IPC and all of that. I looked at yesod and snap and both seemed to be too much for what I'm asking. It seems to me that the best approach would be to write up an WAI interface, strap it to a Warp server and call it a day. 1) Is my reasoning about the approach to take sound or is there an alternative I haven't considered? My app will have 1 path (or rather won't care about the request path) and will take its input by just reading the request body. 2) Could anyone recommend what I need to read to take this approach? I started looking at Warp and WAI documentation and found I was well over my head as I have no knowledge of Iterators/Iteratees/Enumerators nor Builders, but I'm definitely willing to learn if that's what it takes. -- Michael Xavier http://www.michaelxavier.net
On 9 June 2011 17:45, Michael Xavier
Hi Haskell Beginners,
I am writing a fairly simple app in haskell that will be used to support some Ruby on Rails apps at work. The gist of it is that it takes a JSON request and produces a JSON response. I've figured that strapping it to a web server will be the easiest way to allow our Rails apps to talk to it without worrying about IPC and all of that. I looked at yesod and snap and both seemed to be too much for what I'm asking. It seems to me that the best approach would be to write up an WAI interface, strap it to a Warp server and call it a day.
I don't think it matters much what server you use for this type of service. We've been using FastCGI for two fairly large JSON services (11K lines) for a year with no problems. Warp and Snap are also sufficient. Is speed a big concern? Otherwise the iterators will be a bit pointless. I'm with you on forgeting about worrying about the server for this type of service and calling it a day.
I don't think it matters much what server you use for this type of service. We've been using FastCGI for two fairly large JSON services (11K lines) for a year with no problems. Warp and Snap are also sufficient. Is speed a big concern? Otherwise the iterators will be a bit pointless. I'm with you on forgeting about worrying about the server for this type of service and calling it a day.
I'm fairly ignorant of how FastCGI works and only slightly less ignorant about Warp after reading a paper on it by Michael Snoyman, but concurrent connections is a concern. I haven't been able to test the app with a large dataset but the algorithm is something along the lines of O^2 complexity so some requests may take much longer than others. One of my concerns then is that the server should be able to handle concurrent connections well and not let any long-running requests starve/block the others. If FastCGI forks off one process per connection, that would likely be a lot of overhead for the simple case. One thing I can say is that my app as it exists now must parse the entire request body JSON before it starts acting on it. I hope that clears things up. -- Michael Xavier http://www.michaelxavier.net
On 9 June 2011 20:01, Michael Xavier
I'm fairly ignorant of how FastCGI works and only slightly less ignorant
about Warp after reading a paper on it by Michael Snoyman, but concurrent connections is a concern. I haven't been able to test the app with a large dataset but the algorithm is something along the lines of O^2 complexity so some requests may take much longer than others. One of my concerns then is that the server should be able to handle concurrent connections well and not let any long-running requests starve/block the others. If FastCGI forks off one process per connection, that would likely be a lot of overhead for the simple case.
Well, FastCGI is a single process (maybe you're thinking of CGI). For the FastCGI library you specify how to handle a request, like with forkIO or forkOS or merely id. Thus one request can sit churning while others are responding and finishing. Not sure whether Warp is concurrent or asynchronous. Perhaps someone can fill us in?
Hi Michael,
Using WAI/Warp for this sounds reasonable. WAI actually works very
nicely with aeson, as they both use blaze-builder and
attoparsec-enumerator allows JSON values to be parsed directly from
the request body stream. I've put together an example of both the
server and client for the next Yesod cookbook blog post:
http://www.yesodweb.com/show/map/105
HTH,
Michael
On Thu, Jun 9, 2011 at 6:45 PM, Michael Xavier
Hi Haskell Beginners, I am writing a fairly simple app in haskell that will be used to support some Ruby on Rails apps at work. The gist of it is that it takes a JSON request and produces a JSON response. I've figured that strapping it to a web server will be the easiest way to allow our Rails apps to talk to it without worrying about IPC and all of that. I looked at yesod and snap and both seemed to be too much for what I'm asking. It seems to me that the best approach would be to write up an WAI interface, strap it to a Warp server and call it a day. 1) Is my reasoning about the approach to take sound or is there an alternative I haven't considered? My app will have 1 path (or rather won't care about the request path) and will take its input by just reading the request body. 2) Could anyone recommend what I need to read to take this approach? I started looking at Warp and WAI documentation and found I was well over my head as I have no knowledge of Iterators/Iteratees/Enumerators nor Builders, but I'm definitely willing to learn if that's what it takes. -- Michael Xavier http://www.michaelxavier.net
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
Thanks! That tutorial is perfect for what I was trying to do. I still find it kind of weird coming from my background that an Application which reads/modifies the request body would ignore the request but it makes perfect sense after having read a bit more about WAI/Warp to know that the request doesn't really have the body in it. Thanks for the help and all the great software! -- Michael Xavier http://www.michaelxavier.net
participants (3)
-
Christopher Done -
Michael Snoyman -
Michael Xavier