Thema / Theme

Objecten API

Omschrijving / Description

From #550

The idea is to add the ObjectTypes API into the Objects API, making use of the same database. This to avoid requests between the two (improves performance) and simplify the architecture and deployments. Discussed with Utrecht and Den Haag

Initial estimation:

For OpenObjecten: the migration path from Objects API+ObjectTypes API will be quite complicated, as we don't see a workable path to convert the Objects API to OpenObjecten (this would require calling the OT API during datamigrations which feels hacky). So the best alternative would be to create a new OpenObjecten component and add a management command to migrate the data from an existing ObjectsAPI+ObjectTypes API to the new OpenObjecten component: 2-3 months of work.

DH mentions that a migration would be workable if the API paths remain intact, then the objecttypes-api domainname would simply point to the objects-api domainname.

TODO:

• Move the fields on objecttypes.ObjectType model to objects.ObjectType (nullable/blank for now?)
  • also merge the admins for this model (perhaps move the new fields to a separate fieldset?)
• move the v2 API endpoints to Objects
• Add a management command that:
  • takes as input base URL for objecttypes api, token for objecttypes API
  • retrieve all objecttypes (with pagination) and create local objecttype instances from them
    • if a local ObjectType with that UUID exists already: update it, otherwise create a new one
  • Document how to use this management command
• in check_objecttype_cached add an extra code path to use the local ObjectType schema if it exists, if not it should keep the current behavior (retrieving and caching the objecttype info from objecttypes API). This way it's still backwards compatible
• make a minor release that includes the above changes
• use django_upgrade_check to ensure objecttypes are migrated before upgrading to 4.0?
  • not sure if this is possible with django_upgrade_check, but it would be nice if we could check if all local ObjectTypes have been correctly migrated
• in version 4.0, remove the old code path and make fields required (where necessary, should be the same as it was before in the objecttypes.ObjectType model)
• Remove any references to Objecttypes API as a separate component in the documentation
• Remove the external Objecttypes API from the docker-compose setup
• Modify the dashboard to also include information about the Objecttypes API
• Rename Objecttypes API to Open Objecten
• Make sure there is a changelog warning for 4.0 to clearly describe what changes and what must be done before upgrading
• Nice to have: make the import_objecttypes command executable from the admin interface. It would be nice if we have some sort of generic interface for this to make sure that we can apply this for other commands as well

To be discussed:

• I'm assuming both the API endpoints will be under /api/v2/? E.g. /api/v2/objects/ and /api/v2/objecttypes/

Toegevoegde waarde / Added value

Improved performance
Simplification of architecture
Simplification of deployments