back to home

Energinet-DataHub / greenforce-frontend

GreenForce monorepo for the DataHub and Energy Origin frontends. Part of Energinet DataHub.

80 stars
19 forks
134 issues
TypeScriptC#HTML

AI Architecture Analysis

This repository is indexed by RepoMind. By analyzing Energinet-DataHub/greenforce-frontend in our AI interface, you can instantly generate complete architecture diagrams, visualize control flows, and perform automated security audits across the entire codebase.

Our Agentic Context Augmented Generation (Agentic CAG) engine loads full source files into context on-demand, avoiding the fragmentation of traditional RAG systems. Ask questions about the architecture, dependencies, or specific features to see it in action.

Source files are only loaded when you start an analysis to optimize performance.

Embed this Badge

Showcase RepoMind's analysis directly in your repository's README.

[![Analyzed by RepoMind](https://img.shields.io/badge/Analyzed%20by-RepoMind-4F46E5?style=for-the-badge)](https://repomind.in/repo/Energinet-DataHub/greenforce-frontend)
Preview:Analyzed by RepoMind

Repository Overview (README excerpt)

Crawler view

GreenForce [nx]: https://nx.dev [angular]: https://angular.dev Monorepo for the DataHub frontend backed by [Nx] and [Angular]. Table of Contents • General • Prerequisites • DataHub • Documentation • Getting Started • Development • Backend For Frontend (BFF) • Configuration • Watt Design System • Workspace • Applications • Libraries • Tools • Scripts • Workflows (CI/CD) • Visual Studio Code • Domain C4 model General > The documentation in this README assumes the reader has a general understanding > of [Nx] and [Angular]. For beginners in these technologies, the > What is Nx? and the > Interactive Angular tutorial serve as a good > introduction. This repository is a monorepo which hosts serveral applications that all share the same dependencies (for example, every application is running the same version of Angular). _Note: Since this is an [Nx] workspace, the Nx CLI should be used over the Angular CLI._ Prerequisites • Bun: Alternative to Node.js® and Yarn that this repository uses. • .NET SDK: Required for running and developing DataHub. • Volta: Manager for JavaScript command-line tools like Node.js®. DataHub The application is deployed to the following environments: | Development 001 | Development 002 | Development 003 | Test 001 | Test 002 | PreProd | Prod | |-----------------------|-----------------------|-----------------------|-------------------------|-------------------------|-----------------------|-----------------| | [dev_001][dh-dev_001] | [dev_002][dh-dev_002] | [dev_003][dh-dev_003] | [test_001][dh-test_001] | [test_002][dh-test_002] | [preprod][dh-preprod] | [prod][dh-prod] | [dh-dev_001]: https://dev.datahub3.dk [dh-dev_002]: https://dev002.datahub3.dk [dh-dev_003]: https://dev003.datahub3.dk [dh-test_001]: https://test.datahub3.dk [dh-test_002]: https://test002.datahub3.dk [dh-preprod]: https://preprod.datahub3.dk [dh-prod]: https://datahub3.dk Documentation Be sure to check out the additional DataHub documentation for the following areas: • Testing • Mocking • Feature Flags • Logging with Application Insights • Adding new processes to Getting Started Before starting the development server, you must install in your list of locally trusted roots. Run the following command as an administrator from the root of the repository (Windows): Use the following command to serve the DataHub application locally (with request mocking): The application utilizes request mocking for some of the requests to the backend for frontend (BFF), but there are still features that are not mocked. When working with those features, it might be required to serve the BFF locally as well. To do so, run the following command (requires some initial setup, see Setup of BFF). _Note: It is recommended to use mocking as much as possible, see mocking.md._ Development When it is time to add a new library, refrain from writing files manually or copying from existing libraries. Instead, use the provided local generators that takes care of all the manual work and avoids common pitfalls. _Note: Make sure to read the Workspace section beforehand to understand which library type to generate. **It is currently not possible to generate libraries of type and **._ To generate a new library, run the below command\* and follow the instructions: While rarely needed, it is also possible to generate an entirely new domain. Running the following command\* will create a new domain with , , and libraries included: > Also available in Nx Console. Best Practices$$ Take a look at our developer examples to see how to implement certain features like, and an overall best practice guide: • Data table • Form • Modal • Dropdown • Drawer • Description list • Navigation Backend For Frontend (BFF) There is currenly only one BFF located in under . It is for and is using .NET 8.x. Check the Development notes for how to get started. Configuration Configuration files are located in the folder. These local configurations have a filename suffix, but is overridable by a configuration file without the suffix. For example, configures the DataHub frontend to use a local DataHub API. To use a remote DataHub API, place a file in the same folder and set the remote address in the relevant property. Watt Design System > Contributing? Check the Watt Design System README > for developer documentation. This is a shared UI library meant to be used by all frontend apps and it contains basic components and functionality for speeding up app development. It is located in and can be imported from in other libraries. The design system is showcased using Storybook, and can be found here: Latest version (main) To use components or other functionality from Watt, import as in the following example: Workspace The structure of the monorepo is based on general conventions from Nx with a few extensions. On the highest level the workspace is separated into **apps** and **libs**, with most of the logic placed within the **libs** folder. The **apps** should mostly be slim containers that links to functionality implemented in libraries. On the top level, the workspace is divided into the following folders: Applications Within the **apps** folders resides the applications, which includes frontends, BFF and E2E tests. These applications are prefixed with their type and further grouped by a product root folder. Expanding the **apps** folder looks like this: In other words, all applications must follow the naming scheme . Below is an exhaustive list of permitted application types, along with their intended purpose, folder name and which library types they are allowed to have direct dependendies to: | Type | Description | Name | Allowed Dependencies | | --------- | ------------------------------ | --------------- | ---------------------------------------- | | ** ** | Serves as BFF for the product | | - | | ** ** | Entry point for the frontend | | | | ** ** | Runs E2E tests on the frontend | | | Libraries As mentioned above, librarie…