Maybe move UI to a separate project?

[kinow]

Creating a simple Vue app with webpack, babel, etc, to get all the libraries available, and produce a few number of optimized files is fairly simple using the vue-cli (same for angularjs, with their cli).

The issue in the case of Annif, is the way that the application is loaded. It is a flask-first application, that renders a Jinja template, where the Vue app resides now.

I think there are two different ways to change this. We could try to move everything to JavaScript, and simplify the Jinja template to simply include the generated JS.

But fiven Zalando Connexion is an excellent tool for writing API's, perhaps Annif could be split into 2 projects? An Annif backend, and another frontend. That way there would be less "contamination" from flask/jinja to JavaScript (and possibly vice-versa, as adding internationalization, authentication, etc, brings a few more dependencies & issues).

Zalando has another good example for exactly this case, their pipeline tool Nakadi. This is their UI: https://github.com/zalando-nakadi/nakadi-ui

But in theory anybody could create another UI or Nakadi, following their API spec.

What do you think @osma ?

[osma]

Interesting idea. I'm a bit torn on this. I've never thought of the Annif web UI as a separate project, more of an administrative interface for testing models. Very similar to the Fuseki2 UI, which is also bundled with the project itself. From a user/administrator perspective, I think the UI should come along when you install the tool, so at a simple annif run (or similar) command is enough to bring up a web form for testing. Whether it makes sense for the UI code to reside in another repository, I'm not sure. The technical arguments for that seem sound.

Also, if some day the Annif REST API (or something similar which Annif decides to adopt) becomes more like a standard API for similar tools - already MauiService implements the analyze method - then it would make sense to have an independent UI that can talk to any compatible API regardless of the implementation.

Let's put this on hold for now. Right now I don't think it makes sense to split, but the situation may change over time.