Fake Backend must become type safe.

[richardtreier]

Feature Request

Description

The current fake backend which should help us develop once the backend models are known is not helping us very much.

We need a way to at least re-use the model definitions for the input / output objects to define a type safe fake backend.

I'd even suggest that we build it into the productive code, so we can finally stop having to launch two servers to develop locally.

Solutions I've seen before, are:

• You add a flag for local dev
• You add an interceptor if that flag is active (careful, our client library isn't using the angular http interceptors, we'd have to see if we can add a middleware)
• These interceptors intercept the URLs + Protocol and then cast the request body to the known request body
• Then we can have a type safe synchronous fake backend method for every api call that's done via one of the API wrappers.

Which Areas Would Be Affected?

• Angular HTTP Interceptor for legacy endpoints (?), also depends on 0.1.x changes
• Edc Client Middleware
• Broker Server Client Middleware

Why Is the Feature Desired?

If we upgrade to a newer version of the clients, we need to get compilation errors if our fake backend is missing something.

Structure

• Replace the current fake backend with a type safe one, that is included in the main code base. It should work by intercepting angular http calls and being a middleware for the edcClient and brokerServer client.
• The test data can be now written as TypeScript code and thus be DRY.
• Change the test data to be less company-specific. right now some test data is db-branded, this we want to change. So let's make up some believable companies and use cases / values

[SebastianOpriel]

Shall we delay this to once Broker is migrated to EDC 0.1.x?

[richardtreier]

Shall we delay this to once Broker is migrated to EDC 0.1.x?

It is actually better to start it, create the architecture for the new fake backend, so that when endpoints are migrated, they can be migrated to a type-safe fake backend.

The test data would have to be migrated anyways, and our current test data is really not DRY.

The latter would also allow better testing and isolated UI development for the migration.

[richardtreier]

implemented in #447

as the EDC 0 migration made us rewrite the fake backend either way