add CloudFormation Custom Resource

[bpholt]

I updated one of our CloudFormation custom resources to use this draft implementation: Dwolla/postgresql-init-custom-resource#6

[armanbilge]

Thanks!! Really excited about this. Still need to take a closer look but just added some quick thoughts.

[armanbilge]

Can some of this stuff be moved to the events module maybe? Perhaps a bit over-modulization, but I think its valuable to offer our case class encodings of the basic AWS event types so people can use them with their own custom IOLambdas without buying into our implementations.

[bpholt]

I went back and forth on using the events module. I see where you're coming from by allowing others to use the models, but it also means as a user of just the CloudFormation Custom Resource class, I have a lot of models in scope that actually aren't relevant to that task. Tradeoffs either way, I think.

[armanbilge]

I agree, certainly tradeoffs either way, definitely open to ideas for how to best tackle this. FWIW the events module is akin to aws-lambda-java-events and aws-lambda/trigger. Maybe we could scope this a bit better with additional packages?

Also, to explain my thinking a bit, I tend to determine modules by their dependencies. Taking the JS implementations as an example:

• core: CE3
• lambda: core + circe
• lambda-events: circe-generic (i.e. shapeless :)
• lambdaApiGatewayProxyHttp4s: lambda + events + http4s-core
• lambdaCloudFormationCustomResource: lambda + events + http4s-ember-client

So, the events module essentially lets users write lambdas without having http4s (or even CE3!) in scope if that's not relevant to what they want to do either.

I think it ultimately comes down to priorities, if we pretty much assume people will be doing things our way then I totally agree with you, no need for an events module and we can keep things scoped.

[bpholt]

My preference is to leave these things in the CloudFormation module, so I left this alone for now. I think if people aren't doing things our way they're more likely to just use aws-lambda-java-events or whatever, and if they are using our core then having a more focused set of model classes makes sense. But either way is fine, so if there's consensus to move them into events, I can do that too.

[armanbilge]

@bpholt Apologies I wasn't so clear in my comments above, I think I'm imagining an API like this without CfnSetup, hopefully this makes a bit more sense?

abstract class CloudFormationCustomResourceHandler[Input: Decoder, Output: Encoder]
  extends IOLambda[CloudFormationCustomResourceRequest[Input], Unit] {
  
  // Users can override if they wish
  def client: Resource[IO, Client[IO]] = EmberClientBuilder.default[IO].build
  
  // client is the only shared setup, users can setup anything else they want in this resource
  def handler(client: Client[IO]): Resource[CloudFormationCustomResource[IO, Input, Output]
  
  // Now we combine the above to get everything we need in Setup
  type Setup = (Client[IO], CloudFormationCustomResource[IO, Input, Output])
  override final def setup: Resource[IO, Setup] = for {
    c <- client
    h <- handler(c)
  } yield (c, h)
  // Ninja-ed the above to fix stupidity (:

  // ...
}

[armanbilge]

Thanks for finishing this up! Just some nits, but nothing to block on :)

[armanbilge]

@bpholt would it be helpful to publish a snapshot with this?

[bpholt]

Yes please, a snapshot would be great

[armanbilge]

Sorry, just saw this. Do you have keys you can install that can publish under org.typelevel? Otherwise I can publish under my own group.