NFIBrokerage / slipstream

A slick WebSocket client for Phoenix Channels
https://hex.pm/packages/slipstream
Apache License 2.0
155 stars 18 forks source link

Exclude `:phoenix` as a dependency in releases? #26

Closed jjcarstens closed 3 years ago

jjcarstens commented 3 years ago

So far, this lib is proving very intriguing and promising. Thanks! ❤️

One of the pitfalls we're running into, however, is the requirement for :phoenix as a dependency which seems to only be for the %Phoenix.Socket.Message{} struct used in a few places

In some cases, like mine, where dependencies are tightly controlled, this can be a deal breaker.

I see that there are some local and testing cases that require it, so it could be scoped to dev and test:

{:phoenix, "~> 1.0", only: [:dev, :test]}

As for the struct, my current idea is just to reimplement and change as needed when phoenix changes. Or some clever meta programming could be done to pull definition from the dev dependency, but might be getting too clever there 😉.

Though I might actually suggest supporting the concept of a :serializer that can also be configured by the user. That would make this match functionality with phoenix and support those either using the V1 serializer, or those who have abandoned JSON as the primary serialization and made their own for the server instead of forcing the V2 serialization structure thats default in phoenix now.

Thoughts?

the-mikedavis commented 3 years ago

Loving the feedback @jjcarstens, glad to have you trying out slipstream! :heart:

Seems pretty reasonable to me to remove that phoenix dependency. It's a pretty steep price to pay just for a struct with a handful of fields!

I think it'd be an awesome improvement just to get rid of that dependency on the struct and limit phoenix to dev test & docs.

The serializer idea is pretty attractive. We only use some of the basic/vanilla features of Phoenix so the standard JSON serializer gets us as far as we need to go, but if you're using sockets for something super-performant you'll probably need that fine-grained control. I imagine we could work out a simple behaviour for a serializer and provide default JSON v1 and v2 implementations that look very similar to Phoenix's.

I'll make another issue to stub that serializer idea out and get to work on :hocho:ing out phoenix right now