UI API Layer Modularization

[pkosiec]

Created on 2018-11-29 by Paweł Kosiec (@pkosiec).

Decision log

Name	Description
Title	UI API Layer Modularization
Ultimate decision maker(s)	Kyma Council
Due date	2018-11-30
Input provider(s)	UI API Layer main contributors, Product Owners
Group(s) affected by the decision	Kyma Developers
Decision type	Choice
Earliest date to revisit the decision	2019-02-28
Affected decisions

Context

UI API Layer exposes GraphQL API for the Kyma Console. It consists of resolver logic for different domains, like Kubernetes, Service Catalog, Remote Environments, Kubeless, etc. As Kyma needs to be modularized, users should be able to install only the components they need.

The current approach we use in UI API Layer makes it impossible. During the GraphQL server start, we try to synchronize Stores of all Informers. As a result, if a resource of a specific type doesn't exist, UI API Layer won't start properly because its Informer will return an error.

Decision

The decision is to implement UI API Layer module pluggability according to the proposal merged in #141, which bases on replacing UI API Layer resolver logic implementation depending on Back-end Module Custom Resource existence.

Status

Proposed on 2018-11-29.
Accepted on 2018-12-03.

Consequences

This decision have the following consequences:

• UI API Layer modularization will be implemented according to the task UI API Layer module pluggability kyma#1883, which describes steps required for production-grade implementation suggested in the proposal.
• All Front-end Developers should adjust their UIs to make them resilient. Some UI API Layer modules can be turned off, which could not result in crashing UI.

[pkosiec]

Due to my misunderstanding of decision making process, the decision log have been created with a delay.

The decision have been already made by Product Owners @derberg and @PK85. Also, the concept have been shown and discussed with @michal-hudy, @mszostok and @aszecowka.