Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nice-to-have Current features. #972

Open
dimacurrentai opened this issue Mar 12, 2024 · 1 comment
Open

Nice-to-have Current features. #972

dimacurrentai opened this issue Mar 12, 2024 · 1 comment
Assignees

Comments

@dimacurrentai
Copy link
Contributor

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

@dimacurrentai
Copy link
Contributor Author

@mzhurovich WDYT?

@dkorolev dkorolev self-assigned this Mar 12, 2024
@dkorolev dkorolev changed the title Nice-to-have Current featres. Nice-to-have Current features. Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants