feat(io-ts-http): add all http status codes #418
Conversation
domoneill18
changed the title
There was a problem hiding this comment.
@domoneill18, will you please expand on your motivations behind this change?
Submitting this review under 'request changes' only to flag a discussion on the direction of api-ts, another maintainer should feel free to dismiss this review to unblock merging if that is the direction we decide to go
| // 409 (conflict) | ALREADY_EXISTS | Response.conflict | ||
| // 429 (rate-limit) | RESOURCE_EXHAUSTED | Response.rateLimitExceeded | ||
| // 500 (internal server error) | INTERNAL | Response.internalError | ||
| // 503 (service unavailable) | UNAVAILABLE | Response.serviceUnavailable |
There was a problem hiding this comment.
Leaving a quick comment, this thought isn't fully formed/revived:
api-ts was originally conceived to be transport-layer agnostic, so you could use the same service handler but swap out the transport layer. For example, with no changes to business logic you could switch from HTTP to gRPC.
io-ts-http happens to be the HTTP-specific api-ts library. We haven't included any gRPC-specific code yet, but this PR proposes changes that undeniably couple the response library, and api-ts, to HTTP.
I'd love to hear @bitgopatmcl's thoughts!
There was a problem hiding this comment.
The motivation here was that we keep having needs for different HTTP status codes popping up, and each time they are added in a one-off slowing down the ticket which needs the new status code. Given that there are a finite number of supported and recognized status codes, I thought it best to add all of them.
I thought this comment seemed a little misplaced as it is the only mention of GRPc in this lib is in this comment.
There was a problem hiding this comment.
Is there any planned net-new development on these libs?
There was a problem hiding this comment.
I do feel like if it is to be transport-layer agnostic, it should have all status codes available to the lib user on HTTP, right?
There was a problem hiding this comment.
just want to support the need for having more status codes
we've defined a bunch of these ourselves but having them in is io-ts-http definitely makes sense
There was a problem hiding this comment.
I think these status codes also need to be defined here
I believe I have already modified that file as part of this PR
There was a problem hiding this comment.
The
@api-ts/responsedependency is also not actually used byio-ts-httpdespite being listed inpackage.json. If projects are just pulling inresponsefor the couple wrapper functions it exports, perhaps we can just export http-specific versions of those fromio-ts-httpleavingresponseprotocol-agnostic (although if we do go to implement, say,io-ts-grpcin the future then we probably need to do some more work around what the role of thisresponselibrary actually is).
To clarify is this a change request or simply a suggestion for the future? Want to note that this would introduce a breaking change if we were to pull this out of the response lib.
Also, it seems like there are already http statuses which don't map 1-1 with a gRPC status, for example 405 -> NOT_FOUND. Seems like response is already 'coupled' to http in some sense.
There was a problem hiding this comment.
It feels like the response lib should just be called response-http. And we can have separate response libs for other protocols. This is not a change request. Just a suggestion
There was a problem hiding this comment.
It feels like the response lib should just be called response-http. And we can have separate response libs for other protocols. This is not a change request. Just a suggestion
Yeah, either that or just merge it into io-ts-http. If we do eventually want to implement other protocols such as gRPC, then services that want to be protocol-agnostic can limit themselves to the intersection of response codes supported by all protocols.
This avoids needing to try and anticipate what the set of "generic" responses is, like this library currently does. Even then it only mentions gRPC, if we want to use something else then it could have an entirely different set of responses anyway.
With that in mind I think we can merge this with intent to deprecate the library as a follow-up.
There was a problem hiding this comment.
Makes sense, thank you Patrick! I can add a ticket for this if you haven't already done so
bitgopatmcl
dismissed
ericcrosson-bitgo’s stale review
another maintainer should feel free to dismiss this review to unblock merging if that is the direction we decide to go
|
🎉 This PR is included in version @api-ts/[email protected] 🎉 The release is available on npm package (@latest dist-tag) Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version @api-ts/[email protected] 🎉 The release is available on npm package (@latest dist-tag) Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version @api-ts/[email protected] 🎉 The release is available on npm package (@latest dist-tag) Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version @api-ts/[email protected] 🎉 The release is available on npm package (@latest dist-tag) Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version @api-ts/[email protected] 🎉 The release is available on npm package (@latest dist-tag) Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version @api-ts/[email protected] 🎉 The release is available on npm package (@latest dist-tag) Your semantic-release bot 📦🚀 |
6 participants
Changes: