Thursday, April 14, 2011

Azy has competition?

I was recently informed that Azy has competition as a web service framework in C. The initial announcement for the other project seems to be here and the source on github here. For those too lazy to click, it's called "Raphters" and stands for:

  • Resources include things served up to clients like a database or API.
  • Actions provide ways to interact with a Resource.
  • Processors transform data.
  • Handlers provide the entry point for a request.
  • Templates render data.
Upon examination, it seems that RAPHT is a library which allows you to take small bits of pseudo-code and turn them into regex handlers for http requests. If a match is found for a request, it gets passed off to a handler which creates linked lists of both headers and response text which eventually get printfed to stdout and are then picked up by fastcgi for all the socket and network handling.


In a word, "neat." Assuming you have fcgi running, your web services get scaled down to a series of macros with corresponding add() calls for each one. This reduces planning/coding time considerably and allows you to easily implement a simple web/rpc server.
There do seem to be a number of features still missing:
  • No general callbacks for client connect/disconnect
  • No way to set HTTP response codes other than 200
  • Inability to support binary data transmission
Additionally, RAPHT requires synchronous execution around the fcgi loop, preventing use with any kind of main loop to handle events/jobs. As it uses CGI, it must spawn processes to handle requests even if the number of such processes is greatly reduced through the use of fcgi.
Perhaps the biggest downfall of RAPHT is its naive O(n) regex matching system. For each type of method (GET, POST, etc), it tries to regex match against every single service of that type. This means that every URL has its own regex and every RPC method has its own regex. For a server with very few services that is not a problem, but it is definitely not scalable.

Azy has none of these shortcomings, but the biggest benefit that it has over RAPHT (imo) is the ability to simultaneously generate client bindings (in C) for all of your server web services. This means that for zero additional effort, you get conversion functions for the structs that you use and functions to send those structs to your server, allowing you to save considerable time implementing a client.

I don't really have a closing to this, so instead I will post this picture:

4 comments:

  1. Hi, I'm the creator of Raphters. I'm glad you find the project interesting.

    I agree with the downfalls you point out. However, Raphters, as it is on github, is the sum effort of one day's worth of coding. I published it to the web, not because I thought that it would be useful to people, but because I wanted to show people that a nice, modern looking framework in C could work, which I think I've succeeded in doing.

    I am addressing the flaws; many people have made the comment that Raphters would be even better if it was based on libevent rather than fcgi. To this end I have written a multi-threaded, asynchronous web-server (BusyBody on github). ATM, I'm working on exposing a synchronous API based on coroutines over BusyBody's callbacks.

    Rome wasn't built in a day, but maybe it took the lead architect a day to convince the world that it was possible to build Rome.

    ReplyDelete
  2. Hi Daniel,

    With regard to the new project that you have begun (BusyBody), you may want to check out a library that Zentific has created which can be found here, http://svn.zentific.com/trunk/libzxr/ It is a multithreaded web server library similar to what you describe, and I have worked on/with it for nearly two years now.

    The primary downsides of using a threaded server approach is that you require 1) locking, 2) threads per client. As your number of clients scales, eventually you begin to bottleneck your cpu and throughput becomes a serious issue due to context switching between threads. I would personally advise against this if you have the choice, especially because managing locks becomes a serious hassle.

    Cheers to developers who continue to work with C!

    ReplyDelete
  3. Daniel, put the NIH syndrome aside and give Azy a try, it's even cute as you link it with -lazy ;-)

    Jokes aside, Mike (discomfitor) is putting lots of effort to make Azy rock, both fast and ease of use, with helpers to RPC, DB and others.

    ReplyDelete
  4. @discomfitor, It's only threaded so as to avoid unused CPU cycles. It uses a thread pool, one thread per CPU. Locking also isn't an issue as I've written a work queue so that only one callback per request is active at a time.

    @Gustavo, Mostly, this is a learning exercise.

    ReplyDelete