add WebSocketProxy and remove WebSocketServer #802
Conversation
Codecov ReportBase: 78.83% // Head: 79.12% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #802 +/- ##
==========================================
+ Coverage 78.83% 79.12% +0.29%
==========================================
Files 101 101
Lines 11170 11144 -26
==========================================
+ Hits 8806 8818 +12
+ Misses 1859 1830 -29
+ Partials 505 496 -9
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
| // WebSocketProxyKind is the kind of WebSocketProxy. | ||
| const WebSocketProxyKind = "WebSocketProxy" | ||
|
|
||
| var kindWebSocketProxy = &filters.Kind{ |
There was a problem hiding this comment.
IMO, it's better to split every filter into different directories even they have the same infrastructure, which makes the layout clean and has no particular case.
There was a problem hiding this comment.
because the two filters share a lot of code, and the limit time for implement this feature, we have to balance between:
- put them in the same folder
- duplicate the code
and I think the 2nd is worse.
we can do a refactor to put them into different folders later, this only require code level changes, and won't impact the external interface, so we can do it at any time.
As I mentioned before, because we are now using Go 1.18, it is possible for us to extract the load balance and request matching stuff into seperate packages, and I think it will be easier for us to do the refactor after that.
There was a problem hiding this comment.
Your argument makes sense to me. The only thing I was curious about is why different folders mean duplicating code with exporting infrastructure.
There was a problem hiding this comment.
the shared code including:
- load balance
- request matching
- service discovery
if I put the filters into different folders, and avoid code duplication at the same time, I need to extract them into seperate packages, but, I don't have enough time to make a good design for the interfaces of the new packages (in fact, I already did some refactor towards this, e.g. extract service discovery to the BaseServerPool struct).
There was a problem hiding this comment.
If we compromise this for time cost, I think we should add some TODO comments in the implementation to remind us to refactor it in the future.
There was a problem hiding this comment.
I see, the real problem is no time to design interfaces instead of inevitable duplicate code.
No description provided.