denoland / deno_registry2

The backend for the deno.land/x service
https://deno.land/x
MIT License
92 stars 14 forks source link

A webhook/ws for getting updated when modules are created/updated/deleted. #230

Open imjamesb opened 3 years ago

imjamesb commented 3 years ago

I'm working on a module registry and one thing I wanted to make on it is a deno.land/x mirror that automatically will do a similar process like deno.land/x already does and store that given module on my own registry's S3 bucket and make it available somewhere on my registry.

wperron commented 3 years ago

So from conversation on Discord I understand that the request here is to be able to register a webhook that gets triggered when any new version for any modules gets published and that that webhook could then be used by another registry to go ahead and clone the source repository of the module and go through a similar publishing process as we have in place for this repo.

I'm not necessarily against the idea of enabling mirrors for /x though I don't think this is the best way to go about it. For one I think it would make for a brittle system; information needs to be passed around between systems via webhooks with little to no feedback as to whether or not the recipient was actually able to process it correctly. I don't think it really adds anything to the ecosystem we have in place on /x. Registering a webhook at the source repository instead seems like a more robust solution for the use case.

On a more philosophical level, it further cements deno.land/x as "The One True Registry" in the ecosystem and I don't like that idea. I think instead we should focus on a rich and diverse ecosystem of registries.

It also seems like a very niche use-case with little applicability outside of the realm of registry mirrors -- most users will never see or use this feature.


I think the idea of having notifications or webhooks for new versions of modules could be an interesting features for users wishing to stay up to date with the modules that they depend on. In that case though, this would be opt-in at the module level rather than a blanket subscription to the whole of the registry. the information in the notification should also probably be limited to moduleName and version, I don't think it's necessary to have the source repo in there. If this notification takes the form of an email, it could even have a one-liner sed command to automatically upgrade that version in code!

imjamesb commented 3 years ago

I see your point, but at the same time many people do publish their modules at multiple registries, for instance, x/tinyhttp-nest.land/tinyhttp, x/tincan-nest.land/tincan, x/wocket-nest.land/wocket, these was just at the top of the list on nest.land and took me 1 minute to find. I'd be willing to bet there are many more cases like this, I just want to make that process easier for this registry.

However, I'm not opposed to using a webcrawler instead of a webhook.

MierenManz commented 3 years ago

It may be a good idea to be able to subscribe to a rss feed for the module to get new updates? Idk how good of an idea that is. but it is mostly to give another option for a implementation

wperron commented 3 years ago

Before we do anything with notifications per module, I want to hear what use cases that would enable that aren't already supported by simply subscribing for release updates on GitHub

imjamesb commented 3 years ago

AFAIK RSS feeds (for releases) are already possible through https://bandito.re/