6 ms·

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 s

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.

pier25 4y ago
What kind of performance do you need that Dart wasn't sufficient?
- ralferoo 4y ago
  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.
quintussss 4y ago
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
- rch 4y ago
  Have a look at https://okws.org https://okws.org
- csmpltn 4y ago
  > "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".
- User23 4y ago
  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.
- arinlen 4y ago
  > 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.
  - MobiusHorizons 4y ago
davydog187 4y ago
Are you saying litestream is deprecated or some specific feature? I see its very active https://github.com/benbjohnson/litestream https://github.com/benbjohnson/litestream
- ralferoo 4y ago
  Sorry, I wasn't clear. The live-replication work has been abandoned and the author is working on this instead: https://github.com/superfly/litefs https://github.com/superfly/litefs

pier25 4y ago

What kind of performance do you need that Dart wasn't sufficient?

ralferoo 4y ago
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.

quintussss 4y ago

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

rch 4y ago
Have a look at https://okws.org https://okws.org
csmpltn 4y ago
> "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".
User23 4y ago
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.
arinlen 4y ago
> 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.
- MobiusHorizons 4y ago

davydog187 4y ago

Are you saying litestream is deprecated or some specific feature? I see its very active https://github.com/benbjohnson/litestream https://github.com/benbjohnson/litestream

ralferoo 4y ago
Sorry, I wasn't clear. The live-replication work has been abandoned and the author is working on this instead: https://github.com/superfly/litefs https://github.com/superfly/litefs