@grav Yeah, once we worked out an API gateway definition (inc custom authorisor & cors protection) that worked for us defined in cloud formation (SAM) - it has been copy and paste since then, when we wanted to reuse it. That said - we use the proxy integration and try not to do very much in mapping in API gateway.

@richiardiandrea Oh dear, another framework to understand 🙂 I just wanna code Clojure 😉 @lloydshark Yes, using proxy integration is also what I’m considering. I did see that there’s a serverless plugin for cljs-lambda, which handles much of the API gw config and lambda deployment. It also supports Lumo as an alternative to cljs-build, so maybe it would be possible to plug in shadow-cljs as well.

https://groups.google.com/forum/#!topic/clojurescript/ag7qSnfWj5c

👍 for serverless-cljs plugin. Maybe the best thing in Serverless is that it configures the gateway for you.

@grav i was using Serverless and still am with lumo. So I actually agree with you. The one thing serverless does not do is to configure all-the-other-things. As our AWS resources started to grow it became obvious that serverless was not enough.

@richiardiandrea what do you mean by all-the-other-things? Serverless supports arbitrary CloudFormation which covers >95% of AWS infra.

Yeah I don't consider CloudFormation very friendly, I tried working with it, Terraform has better composability

I moved all our infrastructure as code two weeks ago to Terraform following this https://libraries.io/github/robert-stuttaford/terraform-example

I agree that CloudFormation syntax is not the nicest to work with. 🙂 I’m looking forward to see how this turns out https://github.com/tatut/edn-to-cfn

Another way to think about API Gateway, that might not be desirable but is I think possible: there’s no reason you can’t set up your gateway to handle a single /* endpoint which dispatches to a lambda that is comprised of essentially your existing routes, modified slightly to have each handler dispatch to a second lambda where the application logic lives. That way you can keep your existing routing model and only have to write the one API Gateway config.

Yes we actually do exactly that @chris_johnson cause we have a CQRS/event sourcing approach