[Question] Why is dashboard another project

[eye-gu]

Question

I found that the dashboard is another project, and admin is putting the compiled files. I don't know what the current process is like. Why not link the two through Git submodule, or directly import the dashboard code into the Shenyu main repository through the frontend-maven-plugin?

[damonxue]

pls edit it in english.

[yunmaoQu]

Of course ,there are a couple of approaches that could be used to manage the integration of the dashboard with the main repository, and you're suggesting using either a Git submodule or the frontend-maven-plugin. Let’s break down these options and the potential advantages or disadvantages of each approach.

1. Using Git Submodule

A Git submodule allows you to keep the dashboard as a separate repository, but link it to the main repository so that changes to the dashboard can be tracked and pulled in as needed.

Benefits:

• Separation of concerns: The dashboard can remain in its own repository, which means you can manage it separately from the core gateway code. This is useful if the dashboard has its own release cycle or if it’s used by multiple projects.
• Versioning: You can lock the main repository to a specific version of the dashboard, ensuring stability, but also making it easy to update to newer versions when required.
• Reuse: If the same dashboard is used by multiple projects, a submodule makes sense for code reuse without needing to duplicate the dashboard code.

Drawbacks:

• Complexity: Submodules can be tricky to manage, especially for developers who are not familiar with them. You need to remember to update the submodule (git submodule update --init --recursive) and track changes across two different repositories.
• Deployments: Depending on how you're building and deploying the project, ensuring the submodule is pulled and built properly can add complexity to your CI/CD pipeline.
• Tight coupling: If changes to the dashboard and the main project are closely linked, using submodules could make the development process more cumbersome, as commits would need to be coordinated across two repositories.

2. Using the frontend-maven-plugin

The frontend-maven-plugin allows you to run Node.js and frontend build tools like npm or webpack as part of your Maven build process. This would involve pulling the dashboard’s code directly into the main repository and building it as part of the Maven build.

Benefits:

• Integrated build process: By using the frontend-maven-plugin to build the dashboard, you ensure that the dashboard is always built and compiled along with the main project. This makes the build process more cohesive and reduces the likelihood of version mismatches.
• Simplified workflow: Developers don’t have to worry about managing a separate repository or submodule. Everything is in the main repository, and the build process is unified.
• Easier deployment: Since the dashboard is built as part of the main project, deployment can be streamlined. The compiled frontend assets can be packaged together with the backend code or served directly from the gateway.

Drawbacks:

• Monolithic structure: Combining the dashboard with the main repository could lead to a more monolithic project structure. If the dashboard and the gateway code are developed by different teams or have different lifecycles, this tight coupling may be undesirable.
• Frontend dependencies in Maven: You’re introducing Node.js, npm, and potentially a lot of frontend dependencies into your Maven build process. This can increase build times, especially if there are frequent changes to the dashboard, and make the build process more complex.
• Scaling challenges: If the dashboard grows independently or has its own release cycle, keeping it in the same repository could be a bottleneck for scaling and could slow down development.

Which Option to Choose?

The decision depends on how closely coupled the dashboard is to the main project and how the team prefers to manage the repositories.

• Use a Git submodule if:

  • The dashboard is a separate, reusable component that may be used across multiple projects.
  • You want to maintain a clear separation between the dashboard and the main project.
  • You don’t mind the additional complexity of managing submodules.

• Use the frontend-maven-plugin if:

  • The dashboard is tightly coupled to the main project and is unlikely to be reused in other projects.
  • You want a more simplified build and deployment process where everything is handled together.
  • You don’t mind introducing frontend tooling into your Maven build process.

Potential Hybrid Approach:

• If you want to keep the dashboard separate for development purposes but still want a unified build process, you could use a combination of both approaches: keep the dashboard in a separate repository and use a Git submodule to pull it into the main repository, and then use the frontend-maven-plugin to handle the build process once the submodule is pulled in.

In summary, both approaches have their pros and cons, and the best choice would depend on how your team prefers to manage the separation of concerns, the complexity of the build process, and future plans for the dashboard’s development. Are you happy with this answer?