(Re-)move client API route

[subotic]

I would like to suggest to move the generation of the client library files to a separate sub-project (like the upgrade tool).

There is no reason to have a live API route active, which will never be called when deployed into production since the client library needs to be already published at that point.

Also, this would make using the generator for the client code simpler, because only a command-line tool would need to be called, and not a full knora-stack started.

related: #1499
related: #1501

[benjamingeer]

As I've explained before, it can't be a command-line tool separate from Knora, because it relies on OntologyResponderV2 and on the triplestore.

[benjamingeer]

In fact, it relies on:

• OntologyResponderV2, which has loaded ontologies from the triplestore and done its own reasoning about them in Scala.
• The whole mechanism for converting internal ontology schemas to external ones, which is in OntologyMessagesV2.
• The routes where the client functions are defined, which require KnoraRouteData, which requires an ActorSystem.

The fact that all this functionality existed already in Knora is what made it possible to add the client code generation so easily.

It would be possible to refactor all this code to separate it from the triplestore, load the ontologies from files, and separate it from Akka, but it would be a huge amount of work.

If you don't want to have the client code API active on the live system, I suggest we just add a config option to disable it.

[subotic]

Can it be an in-memory triplestore? Then only the necessary responders could be started without the need for an external graphdb, sipi, and redis.

[benjamingeer]

OntologyResponderV2 uses whatever triplestore connector is running in the store module, so yes, you could implement a replacement for HttpTriplestoreConnector using an in-memory triplestore, have some configuration option to disable the responders you don't need, and then start Knora like that.

[benjamingeer]

The SPARQL queries used by OntologyResponderV2 are very simple and don't use any GraphDB-specific features.

[subotic]

Great, having an in-memory triplestore, could also simplify testing.

[subotic]

This doesn‘t look to bad: http://graphdb.ontotext.com/documentation/free/devhub/embeddedgraphdb.html

[benjamingeer]

Sure, if you want to use it for testing, too. If you only want to use it for client code generation, the basic RDF4J SailRepository would probably be fine. You can see how it works here: load the data into an RDF4J Model, put the model in a SailRepository, then do a SPARQL query:

https://github.com/dasch-swiss/knora-api/blob/fa9fb0e67ba1d46aa22d96cb37bb5a7f7fc46541/upgrade/src/test/scala/org.knora.upgrade/plugins/UpgradePluginSpec.scala

https://github.com/dasch-swiss/knora-api/blob/fa9fb0e67ba1d46aa22d96cb37bb5a7f7fc46541/upgrade/src/test/scala/org.knora.upgrade/plugins/UpgradePluginPR1322Spec.scala