---
# System prepended metadata

title: Front-end architecture

---

# Front-end architecture

## DCHI implementation considerations

1. Designs are refined further and reach certain maturity level - need to define what that level is
2. Custom power levels - authorization might be setup differently (discussions, projects, organization around challenge -> opportunity -> project hiearchy)
3. Crowdfunding support
4. Different domain objects = different client-side api
5. Support maps
6. External data links / components
7. Chart integrations

## Front-end architecture considerations

1. Support custom look-and-feel for seperate hubs
2. Share the same server version (EASY) OR support server + client side versioning (COMPLEX)
3. Support integration with external data-sources
4. Analytics and usage statistics need to be available per hub

## Front-end paths that account for considerations

1. [TEMP] Implement custom front-end for a hub inside the current solution
    - Change the client look and feel for a specific hub based on route / flag / etc.
2. Support custom development (build a seperate client)
3. Support high degree of flexibility in content management (host the application in the alkemio client, but offer flexibility and wide range of components, option 1 can be a starting point) [Shopify path]

*Note: There is a possible transition between Options 1 to 3.*

### Exploring Option 2
Isolate core logic and reuse in the new client

1. Core - the absolute necessity, base layer
	- Data models
	- Configuration - queries + data models
	- Metadata - queries + data models
	- Usage & Analytics
	- Utils

2. Data layers (each one builds on top of the others) (Convention over configuration)
    - [NO-REACT] data - graphql queries
    - [REACT] react-data [deps on core]
        - Plugin queries + react code gen + custom hooks
        - Container components (transformations to core objects)

3. React Core [deps on core]
	- [REACT] Configuration - Container components
	- [REACT] Metadata - Container components
	- [REACT] Sentry

4. Visual Components (can be per client or common ground can be found)
	- theme + base components

### Exploring Option 3
Going down the platform path where each hub/organization can have it's own separate client look and feel, that is branded to their standards, but part of a global system (alkemio) that connects them all.

1. Define supported core components/widgets
    - support high degree of customization and share common/standardized api & convention
2. Design and implement management system that will allow:
    - defining pages, navigation, etc.
    - defining page content - placement, components
    - per component styling + feature toggles
    - usage metrics per component
3. Allow plugin component libraries 
    - handles external data-sources and act as adapters
    - use existing data model from alkemio but visuals are entirely different - e.g. instead of table someone implements it with a chart.
4. Allow per hub/organization configuration and monitoring
    - analytics
    - feature toggling
    - domain navigations
    - authorization policies, etc. 
