So kind of an IFTT or Zapier piped directly into your AWS backend?

Yeah, I also thought of IFTT when I saw this: https://ifttt.com/services

Reminds me a bit of Apache Camel then - let's you easily route end points from all kinds of different protocols as if they are messages.

Maybe I never looked at it hard enough, but I couls never figure out what Camel was for.

It's one of those things that you don't know you need ... until you get half way to re-inventing it yourself and then you realise you needed it. Wrt this, probably the more relevant part is all the end point integrations:

https://camel.apache.org/components.html

So it makes it super easy to, say, connect an inbound email to an ftp server so that all the messages get saved as files.

Camel was libraries that codified the the Enterprise Integration Patterns (https://www.enterpriseintegrationpatterns.com/ - channels, messages, service activators, etc...) that allowed you to code against the abstractions rather than the underlying implementations (JMS w/ topics & queues, AMQP w/ exchanges, etc..)

Spring offered a competing set of libs with Spring Integration.

Those we mostly just libraries, though, so you have something running under them for distribution (like a message broker or service bus or, these days, a cloud managed service).

> so you have something running under them for distribution (like a message broker or service bus or, these days, a cloud managed service).

Actually Apache Camel doesn't really care if you have a message broker or not. You can set it up without one and still use half its functionality. (eg: connect a file arriving in a dropbox account to an outbound SMTP etc).

Eek! Missing Salesforce!!!