awslabs / aws-lambda-go-api-proxy

lambda-go-api-proxy makes it easy to port APIs written with Go frameworks such as Gin (https://gin-gonic.github.io/gin/ ) to AWS Lambda and Amazon API Gateway.
Apache License 2.0
1.05k stars 197 forks source link

Add echo support #36

Closed watermelo closed 5 years ago

watermelo commented 5 years ago

Issue #35

Adding support for Echo

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

watermelo commented 5 years ago

Hi @sapessi , I have modified it. 😄

sapessi commented 5 years ago

Thanks @watermelo! Merging.

harrisonhjones commented 5 years ago

I'm not super familiar with how go modules works but does this commit add another dependency to the list of required dependencies to build this package? If so isn't this something we should actively avoid? If I don't use echo in my project but I do use this package why should I have to depend on echo?

The adapter, while cool and useful, should probably live in some example folder/project in my opinion.

sapessi commented 5 years ago

I assumed Go was not going to build/package dependencies that are not used in your application. Regardless, you make a good point @harrisonhjones, I will change this to have multiple modules so that each adapter is its own mod with dependencies.

harrisonhjones commented 5 years ago

More testing might be worth it but I just threw together a quick project:

main.go

package main

import "path/to/dummy"

func main() {
    dummy.Bar()
}

dummy/foo.go

package dummy_dep

func Bar() int {
    return 0
}

dummy/baz.go

package dummy_dep

import "corge" // Not a real package

func Qux() int {
    corge.Bark()
}

And then when I try to go run main.go I get:

cannot find package "corge" in any of:
    C:\Go\src\corge (from $GOROOT)
    C:\Users\hhjones\go\src\corge (from $GOPATH)

So, unfortunately, it looks like Go does try to find all dependencies during compilation.