[rankam]

What is the use case for a C++ web framework? Would higher level languages/frameworks make use of this to do some of the heavy lifting? Would a company migrate to something like this once at scale? Or, are there just some people/companies who prefer to use C++?

[0xffff2]

I currently have an architecture where I have a whole bunch of C++ code doing computational stuff. Later (years after writing the core computational library in C++) I was asked to expose the library via a REST API. At the time I was pretty young (didn't and still don't have the necessary experience to write a web framework myself) and none of the existing C++ web frameworks seemed to work very well. So, I now have a complex architecture with a Java Spring front end that communicates to a C++ backend. Would have been a whole lot simpler all around if I could have easily used C++ for the whole thing.

[mywittyname]

Writing wrappers to interface c++ libraries with most common scripting languages is (usually) pretty easy. Probably much more so than trying to roll an entire HTTP server in C++.

[fer]

At a previous company most of the business is run on C++ applications that expose web APIs (SOAP/REST), is that web enough for you?

C++ is used because there's a lot of heavy lifting in message handling, transformation, and latency has a big impact on business. Any "glue" layer between a computing backend and a presentation backend adds expensive milliseconds to provide a response. If you just want to handle concurrency without care for much else, your usual dynamically typed language will do, and you solve your problems scaling horizontally.

But latency is something that can't be solved scaling horizontally.

Java or Python are used for less critical stuff (admin/management panels and such), but anything transactional is 99% of the time C++.

That said, the framework had terrible interfaces and it implied linking to a multi-GiB .so library, but in the end relatively few servers could handle 50k (relatively complex) tps with less than 20ms latency. I can barely get 20ms with a hello world django app on my laptop.

[MrBuddyCasino]

> Java or Python are used for less critical stuff (admin/management panels and such), but anything transactional is 99% of the time C++

No.

[echelon]

This is going to become more and more common for media intensive applications.

https://vo.codes uses a Rust HTTP web framework. It's not C++, but it's the exact same use case. High performance compute.

It's not unheard of for ordinary CRUD websites, either. IIRC, the first version of OkCupid was written in C++.

[melling]

How much more performant is C++ or Rust?

Didn’t Instagram manage to scale Python?

For small teams, wouldn’t the performance of Rust be offset by the productivity lost by not using Python, for example?

Assuming expert programmers in each language.

[rhodysurf]

I work in a domain where we do tons of computational work in C++. With everyhting being webified now, a C++ backend for a web app would actually be exactly what I need to expose data via rest for a modern frontend.

[VikingCoder]

If you're writing a C++ application, it can be quite useful. I've shared this before:

I worked at a company once that had a really decent HTTP server library... That they put in every program.

You'd launch an app, and to debug it, you'd access http://localhost:9001. From there, you could go to URLs for different libraries in the app. Like, if you had a compression library, you could go http://localhost:9001/compression. It would show stats about the recent work it had done, how long it took, how much CPU, RAM, disk it used. The state of variables now, etc. You could click a button to get it to dump its cache, etc.

If you were running a service on a remote machine, accessing it over HTTP to control it was just awesome. http://r2d2:9001/restart. http://r2d2:9001/quit. http://r2d2:9001/logfile.

Oh, and the services running on that remote machine would register with a system-level monitor. So, if you went to http://r2d2/services, you could see a list of links to connect to all of the running services.

...and every service registered with a global monitor for that service. So, if you knew a Potato process was running somewhere, but you weren't sure which machine it was on, you could find it by going to http://globalmonitor/Potato, and you'd see a list of machines it was running on.

Just all kinds of awesomeness were possible. Can not recommend enough.

And, I mean like, programs with a GUI. Like, picture a game. Except on my second monitor, I had Chrome open, talking to the game's engine. I could use things like WebSockets to stream data to the browser. Like, every time the game engine rendered a shot, I could update it (VNC-style) in the browser window. Except annotated with stats, etc. It was just the most useful way to organize different debug information.

And what was great was that writing a library, and wanting to output information, you wouldn't write it to std out... You'd make HTML content, and write to it. Want to update it? Clear the buffer and write to it again. As a user, if you ever want to read the buffer, you just browse it. Want to update it? Refresh the window. Or better yet, stream it over a websocket. Like Std Out on steroids. If you need to combine the output from a few libraries in a new window, you just write a bit more HTML in your code, and you're doin' it.

It's just another example, in my mind, of the power of libraries. We all get used to thinking of frameworks (IIS, Apache) as the only way to solve a problem, that we forget to even think about putting things together in new and unexpected ways. HTTP as a library - HELL YES.

Using HTML to debug programs, live, is highly under-utilized.

[CyberDildonics]

I would say that debugging a program live is highly underrated. There is no inherent reason why building a webserver into everything and using html for visualization is the best way to go. Shared memory can be used and be 100-1000 times faster, which can make a huge difference if you want to visualize large amounts of data like point clouds, pixels, etc. as they change.

In your scenario it sounds like an easy way to make a big step forward, though I don't think that takes it far enough.

[rramadass]

Very neat! So every "public" API had a corresponding URL which could be publicly accessed over HTTP ?. Sounds like a HTTP-based overlay network within the domain of your application(s).

[FpUser]

I use C++ to write business servers that along with managing data do some heavy calculations and reporting. I see no problems at all using C++ (in combination with some libraries) for this purpose. They're blindingly fast and memory efficient. Using modern C++ they're not any more difficult to develop then using "traditional" means.

[DrBazza]

Pretty much the same as every other language - if you're working in X, and you have a team of X developers, you'll want to use a framework that's also in X so that your toolset doesn't spiral out of control.

In C++ you could link-in a golang webserver, with cgo, or use Spring/Vertx using JNI, but you probably won't.

[Q6T46nT668w6i3m]

provide a web api for existing C++ applications and libraries

[saberience]

I'm not sure there is much of a use-case. Most enterprises want to focus on developer productivity. Most modern web frameworks are more than fast enough, whether you use Spring, Kestrel, or ASP.net, it doesn't really matter anymore, even Flask is more than good enough for 99% of use-cases.

Given how capable even cheap cloud hardware is now, optimizing for developer productivity is better than choosing the "very fast" C or Rust framework which no one understands how to program for. Also, C/Rust etc, being harder languages to learn and lower level, tend to be both harder to hire for and also end up with more bugs than the higher level languages.

[tonyarkles]

> Most enterprises want to focus on developer productivity

And that is something that I generally am OK with, to a point. If your application isn’t performance sensitive, have at ‘er and use whatever you feel is going to be the most productive, even if it potentially has higher opex.

Bugs is an interesting thing. There’s two flavours of bugs, basically: requirement errors and implementation errors. High vs low level languages don’t do much to alleviate the first category of bugs at all (e.g. not thinking through how “random shuffle” should work in a music player). High level languages can help reduce the number of coding errors compared too lower level languages, but they do have their own quirks (eg using an empty list as a default argument in Python)

Ultimately, though, it’s all about working within the constraints you’re given, whether time-to-market, development costs, opex costs, system performance, etc. I’m intrigued by this framework because I have a high performance image processing system written in C++17 and there’s been some discussion recently about an HTTP API for it. Why is it in C++ to begin with? It’s on a somewhat resource constrained board (Jetson Nano) and has to run at at least 70fps for what it’s doing. 14 milliseconds to grab the image from the camera, run it through TensorRT, and do something useful with the output. I would have considered Rust as well, but a good chunk of this is leveraging existing C++ libraries (OpenCV, FLIR Spinnaker, TensorRT, etc) and fighting with wrappers and weird impedance mismatches is not my idea of a good time.

[mr__y]

>Most enterprises want to focus on developer productivity

While I absolutely agree, it all depends on a scale. If you're using for example 10 cloud instances, x2 performance improvement will not justify extra person-months spent on developing more performant solution. On the other hand if you run 1000000 servers even 1% performance boost might be worth that effort.