Add new endpoint to return all known extensions

holly-cummins commented 1 year ago

It is sometimes useful to get a list of all of the known extensions, both platform and platform. At the moment, it is only easily possible to get the non-platform-extensions, and then only for a given Quarkus release.

This PR adds a new endpoint, /extensions/all, which returns all of the extensions in the registry.

There's some overlap in intention with #91 and #92, although the implementation here is much simpler and doesn't involve any schema changes. I don't totally know how the changes here relate to #92 (I only discovered it when submitting this PR).

Because I didn't want to change the schema, there are a few aspects of the behaviour that are maybe not-perfect:

Where multiple releases of an extension exist, each release gets its own entry in the json, without grouping. I decided consumer code could group if it cared.
I eventually want to be able to to look at an extension and find out what platforms its part of. We have that information in the database, but what’s in the OpenAPI schema is a bit more limited. What I did was take the information I had and populate a logical-seeming place in the Extension schema, origins.

It would be useful to know if

What I put in the origins field is sufficient to work backwards to a platform. If it's not, I will need to change the schema after all or find another approach. All that's in the json right now is the id of the ExtensionOrigin, not any of the other information. (I can see consuming code will have to do some heavy lift to figure out what the platform is from just the id.)
What I put in the origins field is actually correct. :) I had to guess how to go from a PlatformRelease to an ExtensionOrigin, and what the contents of the id field should be.

If we think these changes are ok, it might eventually make sense to add some other endpoints, such as /extensions/non-platform/all or /extensions/non-platform?v=2.7.0, just so that extensions/all isn't the only, lonely, extensions endpoint. But we can maybe YAGNI that.

@gastaldi and/or @aloubyansky , what do you think?

gastaldi commented 1 year ago

This endpoint will return a huge JSON (about 850K), I wonder if it shouldn't group by extension with their respective versions? I am not sure how useful that would be without this grouping 🤔

holly-cummins commented 1 year ago

This endpoint will return a huge JSON (about 850K), I wonder if it shouldn't group by extension with their respective versions? I am not sure how useful that would be without this grouping 🤔

Yes, I was going to have do that group on the client side anyway. The reason I didn't do it here was to avoid changing the data model, but maybe I let my reluctance to do that get in the way of doing the better design.

holly-cummins commented 1 year ago

I've made some changes to only return the most recent version of each extension. This should reduce the volume of information passed back from the endpoint, while still supporting the most common use cases. @gastaldi or @aloubyansky, do you mind having another peek?

gastaldi commented 1 year ago

And it's alive in https://registry.quarkus.io/client/extensions/all.

Enjoy! ;)

holly-cummins commented 1 year ago

Hurray! Thanks @aloubyansky and @gastaldi! I'm off to start using it now :)

quarkusio / registry.quarkus.io

Add new endpoint to return all known extensions #143