#24 Handle the GET tags view by front ending and caching the OSBS registry.
Closed by bowlofeggs. Opened by bowlofeggs.
bowlofeggs/fegistry 4  into  master

Download 24.patch

This pull request contains two commits. The first commit adds support for the list tags view, and the second uses dogpile.cache to cache responses from the backend registry to help take load off of it.

1 new commit added

  • Use dogpile cache to cache responses from the backend registry.

rebased

To be honest, I'm not sure I really like this default. The problem is that if someone deploys their own, and forgets to configure, they get a real (working) registry that gives us lots of requests.
I would rather have this use http://example.com/ or the like, and have people explicitly configure it.

A different backend registry url than the first test?

And yet another different one?

Perhaps it's an idea to just do one per line, to make it easier to read at a glance?

I would appreciate it if this also gets split over multiple lines, so it gets easier to read.

I'm reasonably sure that with the current architecture, you can make the generation of these functions more automatic?
Just a @app.generate_cached_proxy('/v2//tags/list') or something?

Yeah I threw in a few different formats to exercise the urljoin a bit, just for variety.

Yeah that's a good idea. I could do something like that (but probably not a decorator, just a function generator) with my next PR since that will add another one. However, the down side would be that this way we get a nice docblock (and the docblocks automatically go into the Sphinx documentation).

I think what you've done here is fine, but if you're in a situation in the future where you want to mock out HTTP requests you might want to look at vcrpy or betamax which both record real HTTP requests and let you play them back in your tests.

You'll probably want to have a timeout set here, since by default there is no timeout by default and this will hang until the server closes the connection or finishes the response.

You might also consider using a Session to take advantage of connection pooling.

Other than the timeout comment I'm fine with this.

We are killing this project, so I am closing this PR.

Pull-Request has been closed by bowlofeggs

Metadata