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.
Thanks,
Dima
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