tink_web icon indicating copy to clipboard operation
tink_web copied to clipboard

Export routing information

Open skial opened this issue 9 years ago • 8 comments

I've been experimenting with the tink_*, web libraries and aws lambda and have a rough tink_http container implementation that works targeting the node runtime.

To have aws lambda working via http, you have to use aws api gateway which uses, imo, an odd request/response integration "frontend" to your aws lambda function.

This requires you to specify a path segment, which http method it accepts, the expected mime type and more.

As tink_web has the ability to access the majority of the http info already from your routes, would there be interest in having tink_web export the info to json or some other format, like openapi?

skial avatar Jun 07 '16 09:06 skial

Oh, the container part is exciting news :)

I do indeed have plans for this kind of stuff. For me reverse routing is the most important bit (so you don't have to assemble URLs by hand), but exporting a full routing table should also be possible. I'll see what I can do ;)

back2dos avatar Jun 07 '16 10:06 back2dos

@skial Say, I wonder is there no way to bypass this restriction? How do other frameworks cope with that? Where might I find documentation for this?

back2dos avatar Jun 07 '16 13:06 back2dos

@skial Say, I wonder is there no way to bypass this restriction?

As far as I've been able to figure out, no.

How do other frameworks cope with that?

I haven't actually looked to see if any other frameworks actually support deploying to aws lambda, I just started hacking. :grin: I'll take a quick look.

I'm thinking of using https://www.terraform.io/ so I don't have to do too much bootstrapping by myself.

Where might I find documentation for this?

I'll post some links etc in another comment as I've got a load of tabs open, as two aws services, imo, are poorly linked together.

skial avatar Jun 07 '16 13:06 skial

More articles than documentation.

I actually forget to say that aws IAM also, ideally, needs to be automated. IAM is used to allow gateway & lambda to talk to each other and to aws cloudwatch, which is used for monitoring. But this is going beyond the scope of the original issue.

I've also included the request mapping I'm currently using.

Gateway Request Integration mapping
{
  "ip" : "$context.identity.sourceIp",
  "resourcePath" : "$context.resourcePath",
  "body" : $input.body,
  "headers": {
    #foreach($header in $input.params().header.keySet())
    "$header": "$util.escapeJavaScript($input.params().header.get($header))" #if($foreach.hasNext),#end

    #end
  },
  "method": "$context.httpMethod",
  "params": {
    #foreach($param in $input.params().path.keySet())
    "$param": "$util.escapeJavaScript($input.params().path.get($param))" #if($foreach.hasNext),#end

    #end
  },
  "query": {
    #foreach($queryParam in $input.params().querystring.keySet())
    "$queryParam": "$util.escapeJavaScript($input.params().querystring.get($queryParam))" #if($foreach.hasNext),#end

    #end
  }  
}

skial avatar Jun 07 '16 13:06 skial

Looks like the serverless framework would solve alot, at first look.

skial avatar Jun 07 '16 14:06 skial

Phew, that's quite some reading to do :)

back2dos avatar Jun 07 '16 14:06 back2dos

Maybe AWS has changed the API or something. Now it doesn't need a manual mapping template. Simply "use lambda proxy integration"

image

Quick links:

A few known limitations:

  • duplicated query params not supported (because it is represented as key-value object)
  • duplicated headers not supported (because it is represented as key-value object)
  • streaming not supported (because the whole request/response is encoded into a json)
  • need to distinguish the response type between plain-text or binary. Because if it is binary it has to be base64 encoded

kevinresol avatar Jun 20 '17 05:06 kevinresol

Thats great @kevinresol :smile:

skial avatar Jul 13 '17 09:07 skial