Integration with other FaaS solutions about middy

[lmammino]

I am still not fully sold on this, I fear that there's too much overread in trying to uniform everything.

Anyway, I totally admit my opinion is just based on feeling, so I suppose what @dkatavic is proposing here is the most reasonable approach to take: let's start with a list of platform we could aim to support; let's list what are the different signatures and other important technical details to keep in mind.

Once this is done, it will probably become much easier to have an informed conversation and come up with a better plan.

Anyone here wants to own this research? @coryodaniel are you still interested? If you would like to contribute to this that would be awesome!

[lmammino]

Hello @coryodaniel and thanks for the appreciation on the project.

Supporting other FaaS solutions is definitely an idea worth exploring. The current implementation is bound to the FaaS API exposed by AWS, where a lambda (a function) is essentially a function with the following signature:

const mylambda = (event, context, callback) => {
  // ... do stuff with `event` and `context`
  // ... invoke `callback(null, result)` or `callback(error)` when done
}

I have other FaaS have slightly different signatures. I think it's doable to create a slightly more sophisticated middy runtime that can be configured to respect the signature of different FaaS services, but this is not a priority for me at the moment. I would prefer to have something more stable and complete for AWS and release version 1.0.0, from there I would probably start to explore something like this.

This is not to say that possible PR that experiments with this idea will be rejected, it's definitely something worth exploring, so feel free to propose your solution if you have already something in mind.

[dkatavic]

That is a great idea @coryodaniel . It would be valuable to document the behaviors of more popular FaaS providers so that we know how are they providing their equivalent of context and eventand how are they handling errors so that it is easier to abstract the behavior. I will keep an eye on this thread

[willfarrell]

I think this will really grow our userbase, I think we should flag this for v2.

We'll need to do:

• either add in logic for how each cloud wraps their handlers or have core-aws, core-google, core-azure
• rename ssm, secretManger, dbManager, s3KeyNormailzer, http-event-normalizer middlewares to indicate aws only
• Find someone that would interested owning all or part of this. Thumbs up this issue if you'd like to be considered for this.

[Rapol]

There's an obscure/abandoned(?) project under the serverless umbrella that provides an express like API, including middleware support, that is compatible with azure and aws. With one handler you can deploy to both clouds without any modifications. I found it months ago and there hasnt been any activity recently but wanted to share.

https://github.com/serverless/multicloud
https://github.com/wbreza/multicloud-demo

[willfarrell]

Thanks for sharing.

[Rapol]

We wire up a quick prototype for azure since we are in dire need of a middleware library at work. It is heavily inspired by the middy API and others. I didn't fork middy since we didnt have time to completely revamp everything to work in Azure but I did stole some snippet from the readme (it is really good y'all). We just spent one day working on it and havent deployed it yet so it is not ready for production at all but it is a start.

https://github.com/Rapol/middizure

[willfarrell]

As amazing as it would be to offer a multi-cloud serverless middleware, I don't see middy offering support outside of AWS anytime soon.