[ADR] metadata driven architecture on front end side

[RafalCypcer]

Context

BCC IT department develop multiple web projects using different technology stack. Most popular at time of writing are Vue.js and React.js ecosystems.
They share similar or even the same concepts with with different syntax ad tools. The goal of architecture analysis is to find out solution where
we could share as much UI/front-end code as possible and reducing repeating yourself and provide consistent styling between similar components.

Decision

To be discussed.

Consequences

1. Slow development at the beginning
2. Architecture might be too challenging by unexperienced developers. Architecture requires good knowledge of algorhytms and patterns used on the front-end.
3. Must be very well tested with at least TDD
4. As this architecture is complex it needs to cover use cases for multiple BCC project to make sense investing time on it.
5. Developing with this architecture will fail if developers are focused on out-of-the-box solutions. This architecture requires to identify templates/patterns rather than using libraries which solves simple use cases. This is generic solution which is focused on reusing as much as possible.
6. Debugging might by more complex. Developers needs to known architecture to be able to identify potential issues.
7. This architecture requires big effort also on backend side: building validators, JSON schema which make sure that data which is given to front-end will be rendered properly.
8. Architecture is good for long-term solutions because it separates layers for business logic into separate place. Traditional modern front-end apps binds business logic with front-end code. Poor separation of concerns. Metadata approach solves that problem.

Alternatives

Developing standard SPA applications as before with ability to share some content by using micro front ends. This solution will not solve inconsistency and technology stack fragmentation between BCC projects.

We need to admit that choosing Vue.js or React.js is not based on analysis between those ecosystems, but personal preferences and familiarity of developers with specific frameworks.

[github-actions]

Remember that ADRs are publicly available hence do not include any confidential information in the issue description!
To read more about ADR please refer to documentation.

[rvanoord]

Metadriven architecture looks like an interesting approach for large systems with many similar UIs (like an ERP system).

At this stage I have a few concerns with this approach in our context:

1. There is no framework to support this (we need to role out our own framework - which isn't really part of our core business)
2. Basing multiple teams on a custom-built framework will increase coupling between teams. In general we want to reduce coupling (meaning teams can develop and deploy independently), but increase collaboration (meaning it's easier to consume services / share ideas across teams).