🚧 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

[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!