Fork me on GitHub
#aws
<
2018-05-06
>
lloydshark00:05:52

@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.

grav09:05:47

@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.

valtteri12:05:19

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

richiardiandrea15:05:43

@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.

valtteri16:05:53

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

richiardiandrea17:05:14

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

richiardiandrea17:05:11

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

valtteri17:05:05

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

chris_johnson18:05:10

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.

richiardiandrea18:05:04

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