OS-245 updating CRV datafordeler endpoint

[stankut]

Link to ticket

OS2Forms/os2forms#248

Description

Replacing the existing Datafordeler endpoint with a new endpoint based on GraphQL.

Additional comments or questions

This is a new of a kind Datafordeler webservice integration that is based on API key, and not the certificate as it used to.

That is why the architecture is changed a bit. Bear in mind, I deliberately decided not do put anything if the parent class and wait until have more example of the new Datafordeler webservices. After that the pattern will be more prominent, which will allow us to move the repetitive/shared features into the parent class

[Anna-itk]

@stankut will you please add jekuaitk as reviewer on this pr?

[jekuaitk]

The before code allowed the use of a key. This is no longer the case

Other than that the GraphQL endpoint modifications looks good!

[jekuaitk]

Should we ensure/validate that this is indeed a CVR-number, i.e. 8 digits?

[stankut]

let's do that! Fixed in 7f3bc6b

[jekuaitk]

Suggested change

	## [Unreleased]
	* Datafordeler CRV service endpoint update - GraphQL.
	## [Unreleased]
	* Datafordeler CVR service endpoint update - GraphQL.

[stankut]

of course.. 😄 fixed in 7f3bc6b

[stankut]

The before code allowed the use of a key. This is no longer the case

Other than that the GraphQL endpoint modifications looks good!

@jekuaitk the old implementation of the key module usage was limited to a custom key of type os2web_key_certificate, which in fact is a reference to the certificate located either locally or remotely (Azure support only).

For the this new GraphQL endpoint implementation none of that is relevant, as it is API key based. So a simple key string.

My plan was to keep it low profile for now, and use the simple logic to make it work, meaning just providing the API key as a string in the setting. As also mentioned above i would like to wait for another Datafordeler implementation before making any architectural decision/rules regarding the implementation. We need to see the common pattern. But when that comes, i think we would need to rewrite the DatafordelerBase by completely - geting rid of the hardcoded os2web_key_certificate and/or replace it to also support API key type of keys.

[jekuaitk]

The before code allowed the use of a key. This is no longer the case
Other than that the GraphQL endpoint modifications looks good!

@jekuaitk the old implementation of the key module usage was limited to a custom key of type os2web_key_certificate, which in fact is a reference to the certificate located either locally or remotely (Azure support only).

For the this new GraphQL endpoint implementation none of that is relevant, as it is API key based. So a simple key string.

My plan was to keep it low profile for now, and use the simple logic to make it work, meaning just providing the API key as a string in the setting. As also mentioned above i would like to wait for another Datafordeler implementation before making any architectural decision/rules regarding the implementation. We need to see the common pattern. But when that comes, i think we would need to rewrite the DatafordelerBase by completely - geting rid of the hardcoded os2web_key_certificate and/or replace it to also support API key type of keys.

Makes sense. As long as we keep this is mind im good with this!

[stankut]

@jekuaitk thanks for a review, i went though the comments, please have a look again