"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?

not my close vote, but the specific vote was for this: [Why was my question closed as "Off Topic - Requests for Recommendations?"](http://meta.programmers.stackexchange.com/a/6487/) Personally, I don't see any resource requests in your question. — , Mar 18 '16 at 14:23

score 2 · Answer 1 · answered Mar 18 '16 at 13:49

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.

answered Mar 18 '16 at 13:49

Lightness Races in Orbit

8,755
3
41
45

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 '16 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. – Lightness Races in Orbit Mar 18 '16 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 '16 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. – Lightness Races in Orbit Mar 18 '16 at 23:25

Basile Starynkevitch · Answer 2 · 2016-03-18T14:30:27.310

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 '16 at 14:04

"web-enabling" an existing C++ app

2 Answers2