[wishlist] Add a publish end-point...

[jonasfj]

Design:

POST /v1/namespace/<namespace>/exchange/<exchange>
scopes: [['pulse:namespace:<namespace>'], ['pulse:namespace:<namespace>/<exchange>']]
        // either:  pulse:namespace:<namespace> or pulse:namespace:<namespace>/<exchange>
{
  routingKey: '...',
  message: {...},
}

From client:

await pulse.publish(namespace, exchange, {
  routingKey: '...',
  message: {...},
});

The general idea is that this publishes a message (and creates the exchange if it doesn't exist).
taskcluster-pulse can have it's owner super-user on rabbitmq, so it doesn't need to create a user
for the namespace...

This could be useful in environments where you can't open a TCP connection, say sending a pulse message from a browser.. Perhaps that could be useful in certain applications..
It could also be useful in languages that doesn't have good rabbitmq libraries, or for developers who are super lazy and thinks it's easier to publish messages through a REST api call than an rabbitmq connection...

Obviously, this wouldn't be able to handle a high load of message publications, for that people would be much better off using a direct connection to rabbitmq... but I suspect it could be useful in places where people only send an occasional message.
In fact, I suspect a single dyno on heroku could publish a hundred messages per second or so :)

Note:
Perhaps we could simplify scope patterns a bit, by using: pulse:namespace:<namespace>/<exchange>.
The pulse.namespace(namespace) end-point would then require the namespace: pulse:namespace:<namespace>/* which implies that can publish to any exchange under the namespace.

---

Thoughts? is this doable? would it be useful later?

[Hexcles]

I'm not exactly familiar with other taskcluster components, but I'm thinking about if taskcluster-pulse is the best place to add this feature.

I saw https://github.com/taskcluster/taskcluster-events which is the backend of WebListener (the frontend is in taskcluster-client). Maybe we can add the publish functionality there and expose a HTTP API? After all, we basically need a proxy and there's already one (currently read-only though). Besides, would a HTTP->AMQP proxy be better than HTTP(tc)->HTTP(rabbit) proxy in any way (reliability, performance, etc.)?

Adding this feature to taskcluster-pulse is quite easy, too. There's a management API for publishing which we can wrap around and then create an endpoint for it, like what we've done many times recently.

[djmitche]

The advantage of doing this is tc-pulse is that the same scopes are used to limit who can publish to which exchanges. So there's no difference between * get pulse user/pass from tc-pulse * build publisher * bind exchange * send message and * make publish() call to tc-pulse with tc-events, we would have to either interpret the same scopes the same way (risky) or introduce a different set of scopes for that workflow.

[jonasfj]

that other reason is that you would need a special privileged AMQP user/pass to do this... Unless you wanted to create an AMQP connection for each publishing operation.

[Hexcles]

These are some very sensible rationales! taskcluster-pulse has just the right scopes required, and a superuser of RabbitMQ already. Implementing this feature other places would need some extra work/trade-off for these two pieces.

[djmitche]

I don't think this is something we will be adding to this service. There's always time to revisit