To bypass CORS, roundup could supply a reverse proxy endpoint.
A request to:

  https://tracker.example.com/demo/@proxy/<name>/path?query#anchor

would do a lookup for <name>:

  proxies = {'<name>': { 'url': 'https://example.org' }

and return the contents at https://example.org/path/?query#anchor.

This could be used to serve up a react or other web application for
accessing roundup. By serving it from the same domain/path CORS shouldn't
be an issue.

One issue with general reverse proxy is embedded URL's in the page that don't
know they have to go through a proxy. I don't think we want to get into rewriting
URL's in proxied pages on the fly.

I wonder if extending the current client.py main code to allow registering classes
to handle different endpoints might be useful. I seem to remember something along
those lines from the distant path. One issue is conflict between the new endpoint and
an existing or new class somebody wants to put on their tracker. For example there
can't be tracker classes called "rest" or "xmlrpc".