🚧 Roadmap to v1

[tmaxmax]

Here's what's planned for v1, listed by priority:

• Improve internal parsing API (Next version – various refactors and cleanups #6, 1352b29)
• Improve server-side message creation API
  • A refactor and simplification (Next version – various refactors and cleanups #6)
  • A Message.Writer, which returns an io.Writer that can be used to write data fields to the event. (Create MessageWriter #9)
    subsequently removed (Server API refactor #11), it is superfluous
  • Replace AppendData with a simple Data string field
• Improve server implementation
  • Fix memory leak in FiniteReplayProvider (use circular buffer in FiniteReplayProvider #23)
    • Refactor ValidReplayProvider as a consequence of the changes made by the other PR
  • Add benchmarks for all server components and create some end-to-end performance testing of the server for common use-cases (input from the community would help, 👋 Are you using go-sse? #24)
  • Re-evaluate the Session API, OnSession and MessageWriter – could we do without them and use standard net/http types instead?
• Improve client
  • Modify response validators so they're able to signal if an error is temporary or not
  • Experiment and try to receive feedback on a new, potentially simpler API (Alternative SSE client #25)
• Internal parser
  • Explore a way to get rid of the buffer size issue (Handle long messages in event parser #2, How to increase the 65K message limit on the receiving side? #32), which seems to leak into the entire library
• General codebase improvements:
  • Remove all panics
    • Use constructors which return errors instead of lazily initialized objects which panic later at runtime if configuration parameters are invalid
  • Improve testability of all APIs
  • Refactor tests to ensure full coverage of all use cases and edge cases and remove flakiness
  • Fix or improve documentation, add more examples where necessary
• Experiment with splitting the codebase into multiple modules and making it a monorepo using go.work (Split code into multiple modules #26)
• At least an additional provider implementation (e.g. for Redis, nats-io or other) (see also Lets add a NATS provider #13, Are there any existing providers out there besides Joe? #19)
• Add event parser to the sse module? (the code in internal/parser – is there demand for this?)
• Project process and discoverability improvements (as activity surrounding it grows)
  • Create a vulnerabilities reporting policy
  • Add known use-cases, projects which use go-sse, external provider implementations if any to README
  • Create issue templates, relevant labels for sorting etc.
• The test of time – try to grow usage of library, solve issues or requests that may pop up, and wait for things to be stable