Replies: 1 comment
-
I think the first point is a good point and I'm thinking about putting this on roadmap. In the v1.11.7 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey there,
we're planning to use a proxy built on top of this in production, and I'm kinda afraid of maintaining it. There are several places that use dynamic types that are not easy to understand (at least for me) when looking at the code. In my opinion, being more strict with typing would go a long way in alleviating that.
I've made an initial PoC port here, seems to be not too hard.
After that, I assume future refactorings/maintenance work to be safer and better understandable.
Examples I personally consider worth improving in that regard:
isFunction
at runtime. The compiler could do that for us. https://github.com/wwerner/transparent-proxy/blob/chore/typescript/src/lib/usingUpstreamToProxy.ts#L8Session.response
can beBuffer
,HttpMessage
orundefined
, which forces us to deal with all possibilities in the code. This is up to the developer and not guided by the IDE/Linter/Compiler. I think it's easy to miss handling all options when changing things and it might blow up only at runtime. In combination with using a library for parsing http messages Use http-parser-js for parseDataToObject #23, I imagine the code dealing with messages to become significantly simpler and harder to break accidentally. https://github.com/wwerner/transparent-proxy/blob/chore/typescript/src/core/Session.ts#L130I'd gladly help out making this happen, if you're interested.
WDYT?
Beta Was this translation helpful? Give feedback.
All reactions