I've started using C++ for the REST backend for a mobile app recently.
I'm using restinio for the REST layer (sadly deprecated a couple of months ago, but it still seemed like the best option in terms of clean interface) and sqlite for the DB layer.
I've architected it all so I have a purely insert-only and order-independent DB on the write-side, so litestream was seeming like a good fit for single-writer, multiple readers, but now that's been abandoned, I'll wait until litefs stabilises, or roll my own to do what I need.
I originally started the REST side in dart so I could share code with the flutter client app, but I soon realised that performance wasn't where I wanted it to be and that the backend queries were all very different to client side anyway, so it seemed easier just to create the REST side in C++. I should add that my normal work has been predominantly C++ for many years so it's more familiar to me than learning something else and also being able to hit the sqlite layer directly without another abstraction layer seems beneficial.
I was planning to use litestream to distribute the sqlite DB to multiple readers, but now that's deprecated, I'll probably look into doing my own in C++ later on if his new focus on litefs doesn't work out for me.
> "Don't know your use case, but C++ for a REST api seems extreme overkill"
It used to be the other way around: spinning up a VM for handling a simple HTTP request, wasting many megabytes of storage, memory and burning needless CPU cycles on bloated abstractions along the way? That used to be the very definition of "overkill".
Sure, but my dart implementation was much slower to start than I'd like for iterative development and also was consuming a chunk of memory.
My current version (admittedly still very early in development) starts in under a second and occupies 300MB after doing some unrepresentatively large transfers (200k records when the application will be doing more like 200 at once). The downside is that compile times are a bit higher.
I could have used something else, but like I said, I'm very familiar with C++ as it's what I've used day-in, day-out for the the last 15 years.
restinio is a pretty good library - the code I'm writing in C++ isn't much more verbose than the flutter code, in fact in some places it's got less boilerplate as it's heavily templated, so e.g. json_dto just requires a single definition to support JSON serialisation and deserialisation.
Unless you want to serve thousands of requests per second on the toaster you just installed NetBSD on. In that case a well written C++ socket multiplexer is a good choice.
Remember that network latency only affects, well, latency. Throughput is another matter.
> Don't know your use case, but C++ for a REST api seems extreme overkill. Any performance benefits would most likely be nullified by network latency
It seems you're mistakenly confusing the time a request takes to be fulfilled with performance.
In the server, performance means throughput. If means nothing if a task handler stays ages waiting for IO. What matters is that once a task is ready to run, the code that needs to run is as lean as you'd like.
This means you can handle more requests with less hardware.
I have no idea how we reached a time when people think it's a good idea to download over 100MB worth of dependencies just to have a service that can handle a HTTP request, and multicore computers packed to the rim with RAM just to be able to handle a few tens of HTTP requests per second.
Latency can still matter on servers, it’s just that the trade off is less obvious given that requests may spend time in a queue waiting to be serviced, and the depth of that queue will depend on throughput more than latency.
Performance wasn't the only reason for switching, but doing sqlite through dart is quite slow even using the batch API due to the copying to the isolate, and in any case I'd be limited to a single thread using dart which I expect would limit me later on.
At that time, I hadn't invested much time into the dart version, but it was looking unlikely that I'd be able to scale it as well as I wanted on the server-side, and the little I gained in development time from shared code by using dart didn't feel significant enough to warrant the performance hit.
I'm using restinio for the REST layer (sadly deprecated a couple of months ago, but it still seemed like the best option in terms of clean interface) and sqlite for the DB layer.
I've architected it all so I have a purely insert-only and order-independent DB on the write-side, so litestream was seeming like a good fit for single-writer, multiple readers, but now that's been abandoned, I'll wait until litefs stabilises, or roll my own to do what I need.
I originally started the REST side in dart so I could share code with the flutter client app, but I soon realised that performance wasn't where I wanted it to be and that the backend queries were all very different to client side anyway, so it seemed easier just to create the REST side in C++. I should add that my normal work has been predominantly C++ for many years so it's more familiar to me than learning something else and also being able to hit the sqlite layer directly without another abstraction layer seems beneficial.
I was planning to use litestream to distribute the sqlite DB to multiple readers, but now that's deprecated, I'll probably look into doing my own in C++ later on if his new focus on litefs doesn't work out for me.