[#3688] Phase 1 - Implement Objecttypes API client

[Viicos]

Part of #3688

[codecov]

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (745cbbe) 96.33% compared to head (8bf5568) 96.35%.
Report is 30 commits behind head on master.

Files	Patch %	Lines
...enforms/contrib/objects_api/clients/objecttypes.py	91.66%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3847      +/-   ##
==========================================
+ Coverage   96.33%   96.35%   +0.01%     
==========================================
  Files         707      711       +4     
  Lines       22172    22247      +75     
  Branches     2541     2554      +13     
==========================================
+ Hits        21359    21435      +76     
+ Misses        568      565       -3     
- Partials      245      247       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sergei-maertens]

I'd like to see this PR broken up in smaller PRs, there's too much going on all at once now 😬

The UI code could've been a separate PR limited to storybook, the additional endpoints could've been a separate PR.

[sergei-maertens]

let's pin this to the same version of postgres as our main docker-compose.yml and apply the same environment settings:

Suggested change

	db:
	image: postgres
	environment:
	- POSTGRES_USER=${DB_USER:-objecttypes}
	- POSTGRES_PASSWORD=${DB_PASSWORD:-objecttypes}
	db:
	image: postgres:${PG_VERSION:-14}
	environment:
	- POSTGRES_HOST_AUTH_METHOD=trust
	volumes:
	# update with appropriate initialize SQL to create the DB for objecttypes and objects each
	- ./docker-init-db.sql:/docker-entrypoint-initdb.d/init_db.sql
	- objects-apis-db:/var/lib/postgresql/data
	networks:
	- open-forms-dev
	volumes:
	objects-apis-db

[Viicos]

Objecttypes API doesn't have a init-db.sql script so I'm keeping it as is for now

[sergei-maertens]

I'd take the same structure/set up like in our root docker-init-db.sql - the reason for this is that you'll be created a database for objects and objecttypes each, but in the same DB cluster. You really don't want both django apps to look for the same tables in the same DB, that will cause problems.

[Viicos]

I created the init script but still got some weird errors (FATAL: role "user" does not exist)

I'm also unsure what the open-forms-dev network does and how it relates to the one in our docker compose.

I'm leaving this for now it takes too much of my time and I don't have all the knowledge so I'll come back to this later

[sergei-maertens]

okay - some information:

FATAL: role "user" does not exist - in docker-compose, I basically tend to enable TRUST mode, it's not for prod anyway. So we let all the SQL be executed by the postgres superuser. That init script then ensures a DB user exists and creates the necessary database(s) owned by that user.

So in compose you typically want to have:

    environment:
      - POSTGRES_HOST_AUTH_METHOD=trust

The open-forms-dev network is so that we can spin up multiple compose files each from their own shell but all the services are on the same network. That way, we can make the root docker-compose.yml talk to the camunda from docker/docker-compose.camunda.yml etc. That essentially allows you to spin up all the services and have them be connected to use all of OF's features at once.

[Viicos]

Ah so it's an error but doesn't block anything. PR was updated

[sergei-maertens]

I'm interested to see how this handles 404s for bogus UUIDs

[Viicos]

Objecttypes API raises a ValidationError but for some reason a 500 is returned. Should we validate on our side that it is a correct UUID?

[sergei-maertens]

no, a 500 is never an intended/deliberate outcome. Create an issue in the objecttypes API for this case, and I think a 404 is more appropriate.

[Viicos]

Opened: maykinmedia/objects-api#361