# 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.