Federated Integreat Platform

[svenseeberg]

If there are multiple CMS installations, we want them to be able to exchange available regions. The Integreat App should be able to show the content of all connected CMS servers.

Challenges:

• Latency in the GUI has to be kept as low as possible to not negatively impact search engine rankings.
• App updates should not be required to add or remove 3rd party CMS installations.
• Namespace collisions have to be avoided, especially duplicate region names.
• The API versions of different Integreat CMS versions have to be compatible.
• Diverging CMS-wide settings, for example offers, languages and Location Categories have to be considered

The following information has to be exchanged, cached, and kept up to date:

Available CMSes:

• Domain
• Name
• ID (maybe public key fingerprint)

Available regions: (site/city)

• parent CMS
• path (acts as an identifier, city name in URL, i.e. /augsburg/)
• aliases
• coordinates
• plz / zip
• prefix (Stadt, Landkreis)
• name_without_prefix "Augsburg"

[svenseeberg]

I think there are (categorically) 2 approaches:

• The app fetches all content from the main Integreat CMS server (usually operated by the Digitalfabrik)
• The app itself chooses to which server to connect and fetches the content from the 3rd party directly.

The simplest solution would be to set up the region locally in the Integreat CMS with all required settings and then configure reverse proxy rules to the external CMS for all API endpoints that actually return content. However, there would be a huge performance penalty here. The latency would at least double. This could be somewhat mitigated by aggressive caching, which in turn would not be nice for the content editing team due to delayed visibility of content.

I think a good approach would be to set up the region locally on the main CMS (admin.integreat-app.de) and add a 3rd_party_cms_url. This URL would then be returned to the Integreat App when fetching regions. The app could then directly connect to the other CMS to fetch content. There is one larger legal caveat here: we would directly load content from a (legal) third party. That means we need to either ask the user for permissions to continue to that provider or, alternatively, sign a data processing agreement with the third party. That would make the owner of the original CMS responsible for compliance with GDPR regulation. Therefore, I think, the better approach would be to ask the user in the front end when changing to a third party server.

I would skip over the original idea of CMS servers exchanging data/content etc.