Stay away from FastCGI++ if you can

So I’m in my praxis semester at the moment, and I have to work with fastcgi++, a C++ library for fastcgi. And it is a nightmare! Here comes why…

So first, the codebase of fastcgi++ is a mess. Code snippets like

bool foo = someFunction();
if (foo) return true;
else return false;

are everywhere. You really don’t want to read that kind of code. And yes, you have to actually read this code because there is no documentation on how to use the library! There is a wonderful doxygen-generated API documentation, but that does not help you because, yeah, you know the types and the interfaces now - lucky you! How to build a fastcgi module with them - figure it out by reading through the codebase!

Secondly, you are not allowed to define your custom accept() handler. You have to inherit from a Request class template and you have to implement the virtual bool response(void) = 0; method. Okay, no problem, I can do this! But then, you want to start accepting requests. You do this by creating an instance of a class called Manager:

Fastcgipp::Manager<MyRequestInheritedClass> man();

or something like this (this is no real code, I just want to demonstrate how it looks like). The manager accepts one connection (through many layers of abstraction, actually), creates an instance of your request class and calls response() on it.

Well, that’s not a problem, is it? Well, it gets to a big problem if you want to be able to handle multiple requests at once, speaking of multithreading/concurrency here. It is a huge mess! My codebase exists of three classes, actually. A ThreadedRequest class, a BlockingQueue where requests get stored thread-safe and a RequestDispatcher which is a singleton which runs several worker threads. These worker threads take the requests out of the queue and process them if they can.

The ThreadedRequest class puts itself into the queue, which is a member of the RequestDispatcher singleton instance. The problem is not that it is unnecessarily complicated to build these 1-N multiplexing thing, but that the library provides an interface which enforces you to couple your classes realy tightly. And this is freaking bullshit.

So, finally: I’m building a wrapper lib around fastcgi++ to be able to handle requests in a concurrent way. And it sucks. But it works.

So, my conclusion is: Stay away from this bullshit library. And even from fastcgi if you can. Apache for example offers a way to write modules, so you can simply write your own module for apache if you need to - which is faster anyways!

If you have to use fastcgi, consider writing your own library!