Closed colehaus closed 6 years ago
Yes, it's the intent to use types compatible with wai, etc. to put applications already using another framework - servant, etc. - behind an API Gateway. Just haven't got around to it yet, pull requests welcome.
This would also alleviate #32 for API Gateways, since you could use a warp server for local development and deploy to serverless without needing to maintain two separate APIs.
@colehaus Your draft looks nearly complete, unless your usages of error
indicate information that can't be extracted from APIGatewayProxyRequest
. In either case, I'm going to try to get this working over the next few days, because yeah, this would be great.
I actually have some time today. I can try to get polish this a bit and actually send out a couple PRs. I'm thinking that the switch to standard types should be a PR to this package and the WAI stuff can be a small standalone package to keep dependencies slim. Sound reasonable?
There's a fairly standard set of types for these defined https://hackage.haskell.org/package/http-types.
wai
(Web Application Interface) depends on them directly. Beyond the general benefits of standardization, using the standards here would make it slightly easier to package upWAI
applications for use with API Gateway.Here's a rough draft of that:
As you can see,
toWaiRequest
andfromWaiResponse
would benefit a bit from better harmony with the standard.