This issue is mostly to track some brave ideas of early 2024 that might be worth investing into.
Nothing even remotely resembling planning. I just want to have several things laid out, in case we do revisit Current development.
I have quite a few things in mind.
Logging.
We need some basic logger.
Singleton.
A factory, for custom log types / files.
With build-in rotation.
Better CORS support for HTTP APIs.
Some HTTP headers are custom-ish.
Probably best to configure per HTTP port.
Also, we need some RespondWithJSON into Request, so that the argument is a std::string, but all the return headers are set as if it is a value JSON, expected to be parsed as such.
"Current as a Service".
Once logging is in place, this is effectively about the "graceful restart".
Unified health checks and telemetry, of course.
cron-friendly.
First that the currently running binary on the port the "new" one is expected to take.
If "self" is up and running, do nothing.
If not, signal it to shut down gracefully, then replace it.
Quite a common pattern, we've built this before.
May even leverage our nginx integration.
Dynamically loaded .so-s.
A nice addition to the "Current Service".
If new code was added, and the new .so-s were successfully built, have the currently-up-and-running service pick them up.
In-code support, via smart pointers or Owned/Borrowed, so that some pieces of code get updated "on the fly", while the "main logic" is intact.
Protobuf <=> CURRENT_STRUCT integration, as well we gRPC <=> Current integration. Ideal end state:
Build with Current.
Everything is exposed via HTTP.
With just a few macros here and there, those HTTP endpoints are also high-throughput low-latency gRPC endpoints.
That's for the server. For the client ... well, we'll need a client too, Current-friendly, as well as tests and benchmarks.
Last but not least: if we have HTTP and gRPC, might as well have binary TCP sockets, and compare all three!
Not sure how much time I will have in the coming months, but I'd like to have this written down somewhere, and a GitHub issue sounds good. We'll close/resolve it as soon as any real work begins, and/or if we choose to re-prioritize. Also, nothing prevents us from editing this message, although I'd prefer to keep it as is due to my personal preference of tracking things fairly.
Last but not least: the Educational Designs section of the SysDesign Meetup README page outlines a few principles which Current may well follow, since, who knows, some of those designs I keep planning to materialize could be Current-first.
dimacurrentai
commented
7 months ago
This issue is mostly to track some brave ideas of early 2024 that might be worth investing into.
Nothing even remotely resembling planning. I just want to have several things laid out, in case we do revisit Current development.
I have quite a few things in mind.
RespondWithJSONintoRequest, so that the argument is astd::string, but all the return headers are set as if it is a value JSON, expected to be parsed as such.cron-friendly.nginxintegration..so-s..so-s were successfully built, have the currently-up-and-running service pick them up.Owned/Borrowed, so that some pieces of code get updated "on the fly", while the "main logic" is intact.CURRENT_STRUCTintegration, as well wegRPC<=> Current integration. Ideal end state:Not sure how much time I will have in the coming months, but I'd like to have this written down somewhere, and a GitHub issue sounds good. We'll close/resolve it as soon as any real work begins, and/or if we choose to re-prioritize. Also, nothing prevents us from editing this message, although I'd prefer to keep it as is due to my personal preference of tracking things fairly.
Last but not least: the Educational Designs section of the SysDesign Meetup README page outlines a few principles which Current may well follow, since, who knows, some of those designs I keep planning to materialize could be Current-first.
Thanks, Dima