We are using Prodigy in our organization where we deploy it to a Google App Engine environment and have users access via a certain URL. What we noticed is that the frontend makes all calls to the backend at the root path. So if I deploy it to mydomain.com, the app will request new questions at mydomain.com/get_questions. It even does so if we deploy the app to mydomain.com/project123, which means all the AJAX requests fail in that case.
It would be great if there would be a way to modify the base path to which requests are made. So in the above example it would request new questions at mydomain.com/project123/get_questions. Our current approach is to deploy different projects to different subdomains, but it is a bit cumbersome in terms of other processes (like authentication).
It may also be the case there is an obvious solution to this problem, but it currently is not obvious to me
Yes, at the moment, this is difficult – sorry about that. Especially if we want to support the same configuration workflow via the prodigy.json. When you start up the app, Prodigy makes a request to the server to fetch the settings – but in order to do this, it obviously needs the base path (which it won’t have if it’s only provided in the settings). Recompiling the app for each base path isn’t really a good solution either, and we also want to avoid making the user run two separate processes per session (server and web app). So in order to support custom base paths, we’ll have to refactor quite a bit of the web app and REST API logic (or add a hack to inject this information via the static resources, which is less elegant).
For our own Prodigy-powered projects, we normally use subdomain-based routing, which works pretty well So if that’s an option for you, you could use this as a workaround for now.
Put the path to the backend in a query parameter when making the GET request to the prodigy Web App. Then make all the AJAX calls go to this path. If the query parameter is missing, assume it’s the same path as the Web App (current situation).
This would also separate Prodigy into one static web app and several REST backends, while the simple local developer usage is preserved. I guess it would need a flag or config setting to tell the backend server to listen on the right path.
The settings are returned by the /project handler, right? Or is there some other magic happening in the JS part?
@simon.gurcke I think with the latest version of Prodigy, it should just work out-of-the-box and the requests will be made using relative paths! Could you give it a try and see if it works?
Unfortunately I can only test with Prodigy 1.10.8 as we cannot upgrade spaCy at this point due to the missing coref resolution feature (we're currently using neuralcoref which only works with spaCy 2.x).
With 1.10.8 I cannot load Prodigy using a subpath, as it has some hardcoded absolute paths still
Any chance for a backport in case this was only addressed in 1.11.x?
Hi @simon.gurcke ! Can you provide more details in your setup? This should have already been solved since v1.10.6. Unfortunately, I can't replicate it, as running a dev environment with v1.10.8 works with subpaths:
Sorry @ljvmiranda921, it's actually not working 100% yet. It seems that fonts are still trying to be loaded from an absolute path which fails in this scenario. Should be a super quick fix
So if that’s an option for you, you could use this as a workaround for now.
