Recently I started to use the web server functionality of Poco. Today I’ll describe my first experiences with the library.

Where I use Poco

Last week I have written about the initial design and architecture decisions I made for Fix. I use Poco for the thin I/O layers at both ends: Receiving and responding to web requests at one end, and file storage at the other.

The server part is completely governed by Poco. In fact, the libraries contain application management facilities and I just instantiate and run a class that is derived from Poco::Util::ServerApplication and inject the implementation for the REST API with the storage layer it depends on. Poco handles the rest.

For the file storage layer I use Poco for some basic stuff like the OS independent handling of paths, checking whether files exist, traversing directories etc. The actual writing to and reading from files is covered by C++’s standard IOStreams.

But first things first.

Installing Poco with Conan

If you haven’t heard about Conan yet, you should definitely check it out. Installing Poco with Conan is fairly easy, since the maintainers of Conan also maintain a Conan recipe for Poco. I simply had to add the line Poco/1.7.3@lasote/stable to my conanfile.txt, and voilá.

Almost. There is a little oddity when it comes to Poco. Usually it does not matter much whether you link against the debug or release build of a library. It especially does not matter whether you build a library with the compiler set to C++11 or C++14, given that the library can actually be compiled with C++11.

And if any of these things matter, you usually get compiler or linker errors. Not so with Poco: the library compiled fine (Release and Debug mode), and my application compiled just fine in both modes as well.

But it turns out, if you build your application in Debug mode with C++14 flag activated an link against a Poco compiled without C++14, everything compiles and links, but Poco’s sockets will throw an error at runtime. Luckily the maintainers of the Conan recipe were really quick to react to my issue report, found the problem and fixed it by providing an option to have Conan compile Poco with the C++14 flag.

Adding Conan as prebuild step in CLion

Now that was done, I found myself needing to call conan install whenever I wanted to switch my build between Debug and Release mode. I probably could use two different build directories and let CMake switch depending on the build type. This is still something I have to look into.

The solution I use for now is a simple shell script which I call with the build type whenever I build the complete application. In CLion you can add such scripts to be executed before your build, which is exactly what I have done.

With that, I could continue to develop a simple HTTP server with Poco which runs Fix.

The Poco HTTP server

On the Poco documentation you find a little example of a simple web server. That is where I started from, and it currently is not much more than that. It contains four classes: The server itself, a RequestHandlerFactory and two request handlers for the HTML page and the REST requests.

As of today, the HTMLRequestHandler does only serve a static HTML page without any meaningful content. The handler itself won’t get any more complicated. The beef of the web app will be in the HTML and Javascript, not in the handler serving it.

The RESTRequestHandler dismantles the requests coming in and forwards them to the REST API implementation which is completely independent of Poco. I doubt there will be much more functionality in the server at all in the future. After all, the design decision was to make that layer of Fix as small as possible.

Conclusion

Except for the C++14 compilation issues,  I got a running HTTP server in only a hour or two. The use of Poco for the HTTP server and for the file system functionality is straight forward. Thanks to a good documentation I did not run into any surprises.