"web-enabling" an existing C++ app

Question

I've got a Windows application coded in C++. I want to provide a web-based interface to them, with a view to porting them to embedded Linux systems. The web pages are a series of dynamic 'status pages' into the system, with possibly some simple interaction controls

Modern HTML/CSS/Web technologies are all comparatively new to me, and I'm trying to work out a sane approach to structure this.

The first approach was using a simple webserver integrated straight into the Windows application, with some C++ code writing the HTML dynamically, and serving some static css/javascript/images. Pitfalls were pretty obvious: No HTTPS, content and presentation all muddled together :(

Now, I have 'static' pages which use JQuery to retrieve JSON data from my app. The server now is nginx, and it uses FastCGI to pull data from my app.

So the process is a bit like this:

• Browser requests page
• Nginx serves page with Javascript
• Browser executes javascript and uses JQuery/getJSON to fetch status data
• Nginx forwards JSON GET via fastcgi to my app
• My app generates JSON and sends to nginx
• Nginx forwards JSON to browser
• Browser javascript uses JSON data to render page

This seems a little cumbersome. Is there something smarter I should be doing, maybe using server-side includes with fastcgi to include the JSON data in the original request? Am I doing something horribly unconventional?

Answer 1

You could use FastCGI techniques and libraries.

You could also make your C++ application a specialized Web server by using some HTTP server library like libonion or Wt (both are HTTPS capable, and can easily serve static content -from files or from embedded byte data- like Javascript, CSS, fonts, images, static text...; and both have some kind of template machinery mixing fixed HTML with dynamic HTML parts).

Then (with FastCGI, or some HTTP server library) you'll avoid the burden (that old CGI approach has) of starting a new process for every HTTP request.

BTW, some people think that FastCGI is obsolete: they claim that we should always code specialized HTTP server in C++, and perhaps use and configure ngnix (or some other common HTTP server like apache or lighttpd) to redirect some HTTP requests to the specialized web server (so use HTTP protocol in place of FastCGI for the communication between your C++ program and ngnix).

With an HTTP server library, you won't need some extra HTTP server like ngnix (but your application should be careful to avoid crashing). With FastCGI, your ngnix (or other) Web server can be configured to start or restart your C++ FastCGI application when needed. And FastCGI is somehow designed to interact quickly with the Web server.

Unless the appliance has lots of simultanous HTTP clients (i.e. many people are browsing it at the same time), or unless you don't trust your C++ application, I would recommend an HTTP server library approach (precisely to avoid the cost of the FastCGI exchanges -which don't cost much in practice- and more importantly to avoid the need of an extra full blown HTTP server like ngnix...)

Answer 2

You're almost there, but unless your page is to periodically refresh itself, the JavaScript/AJAX layer is, indeed, superfluous.

If you structure your back-end correctly, you can have it generate both the content and the presentation and send both in HTML form to the browser, without making a mess. This is what presentation templates are for!

Perhaps consider organising your back-end code in some form of the MVC pattern.