You can write your own component that handles whatever service you need and share it with the community. The more components that are built, the easier it'll be to write higher level components that use those.
@scarface74 We have three projects. Here's how they may be helpful to you:
1) Serverless Framework
The Serverless Framework enables you to provision serverless applications in a Function + Events pattern. Using this, you can accomplish the patterns you're describing, and hundreds of thousands of people are doing this already with the Framework.
SFE works with the Serverless Framework to give you more than development and deployment convenience. SFE focuses on other phases of the serverless application lifecycle, like monitoring, alerting, security, collaboration, secrets and much more. It's a powerful solution for teams and orgs investing more in serverless application development.
This is a new take on serverless application development. We've learned the serverless community and teams are looking for ways to deploy and share composable architectural pieces (features, use-cases), more than infra. So we're building a new type of provisioning system to enable this. The Realtime Application Component is an example of this.
Most of the lambda related things I do are backend ETL and message processing.
Is Serverless just for API use cases or does it support other event triggers like SNS and SQS or one of the patterns we use is
S3 Event -> SNS -> SQS -> lambda and all of the related permissions and subscriptions.
But then again, isn’t the whole purpose of using Serverless instead of SAM to be cloud vendor neutral? Once you add AWS specific resources doesn’t that go against the whole ideal of using Serverless?
As of today, those are the available components:
https://github.com/serverless-components