🚧 Roadmap to v1

[tmaxmax]

Here's what's planned for v1, listed roughly 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 (v0.9.0)
  • 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 with and try to receive feedback on a new, potentially simpler API (Alternative SSE client #25)
    • Implement a utility to read sse.Events directly from an io.Reader (sse.Read, v0.10.0)
    • Implement a simplified client as described in the issue above
• Internal parser
  • Explore a way to possibly 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

[Pramodh-G]

Hey, I was searching around for only an SSE events parser - encoder/decoder. This was the only library I could find that isn't ancient - thanks for your work!

I'm using an openapi spec which generates ready to use API calls from client side - which is why I am not using the client in go-sse (it would take time to make it play well with openAPI generated code). However, I'm interested in using the code inside internal/parser. I could also help you with exposing it if you had a few ideas in mind.

I saw that the code in https://github.com/donovanhide/eventsource/blob/master/decoder.go, was much simpler and shorter than what you have written up - is there any advantage that I'm missing to your implementation? Please do let me know!

Thanks!