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?


2 Answers 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.

  • I'm not familiar with th term "presentation template"? I'm trying to keep all HTML out of my C++ application, so it only provides JSON. Does that make sense?
    – Roddy
    Mar 18, 2016 at 14:06
  • 1
    @Roddy: It's not a magic term - just an English description. You can have part of your C++ application provide JSON to another part of the application that inserts it into the HTML (the two being relatively isolated in terms of logic so as to separate content and form). So, exactly what you're doing now, except without requiring the browser to do the work for you and without requiring extra an HTTP request. This is the conventional way to do it, and it's how MVC works. Mar 18, 2016 at 14:07
  • Yes, MVC is what I'm aiming for. The JSON is basically 'model'. So I could have server-side C++ code that interprets the JSON to dynamically construct HTML, rather than have client-side JS that modifies the DOM. Working in the DOM domain seems cleaner?
    – Roddy
    Mar 18, 2016 at 15:20
  • @Roddy: Your view component on the server side can build/manipulate DOM if you like but I don't think that's very common. Honestly, if it's static at the front-end I'd avoid extra HTTP calls. That seeks like an abstraction leak - you've got the engineering of your system happening at the client's computer. It's not terribly accessible, it's not optimally fast, it uses excess bandwidth, and bugs in the resulting HTML become next to impossible analyse on the wire when something goes wrong. Mar 18, 2016 at 23:25

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...)

  • Thanks. I'm already using FastCgi. libonion does look interesting, but the external server (nginx) approach seems to make sense because I may eventually have several apps providing status via a single URL.
    – Roddy
    Mar 18, 2016 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.