🚧 Roadmap to v1

[tmaxmax]

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

• [x] Improve internal parsing API (#6, 1352b29)
• [ ] Improve server-side message creation API
  • [x] A refactor and simplification (#6)
  • [x] ~A Message.Writer, which returns an io.Writer that can be used to write data fields to the event. (#9)~ subsequently removed (#11), it is superfluous
  • [ ] Replace AppendData with a simple Data string field
• [ ] Improve server implementation
  • [x] Fix memory leak 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, #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 (#25)
• [ ] Internal parser
  • [ ] Explore a way to get rid of the buffer size issue (#2, #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 (#26)
• [ ] At least an additional provider implementation (e.g. for Redis, nats-io or other) (see also #13, #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