[
https://issues.apache.org/jira/browse/AMBARI-26507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17956555#comment-17956555
]
vanshuhassija commented on AMBARI-26507:
----------------------------------------
the proposal structure wise looks good but few concerns # Existing application
is written in bootstrap and using shadcn would mean revisiting the designs.
Using existing component library will make it easy to reuse css by just copying
the classes as already an effort was made to upgrade it to latest version.
# Regarding routing, react-router-dom is super efficient and the license is
also available which is not the case with tanstack routinv I guess
# Me and my team have done a great amount of work in the existing structure
and a new folder has been added to existing web folder along with switch
experience. While we are totally aligned with the proposal you sent, we would
like to contribute the changes according to the current raised PR structure.
The ultimate goal is to move towards unification which will be minimal effort
after completion of project.
We are aligned with proposal but my proposal would be to work in parallel
folder of existing ambari-web experience, stabilise it and move forward towards
unification.
Let me know your thoughts.
> MonoRepo design for reactJS admin and web
> -----------------------------------------
>
> Key: AMBARI-26507
> URL: https://issues.apache.org/jira/browse/AMBARI-26507
> Project: Ambari
> Issue Type: Story
> Reporter: Nikita Pande
> Priority: Major
> Attachments: image-2025-05-19-18-41-01-314.png,
> image-2025-05-19-18-45-42-911.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With the efforts of Ambari community members and lots of contributors, Ambari
> 3.0.0 [released|https://github.com/apache/ambari/releases/tag/release-3.0.0]
> with a large number of new features and upgrades. In this release, there are
> relatively few frontend updates for
> [ambari-web|https://github.com/apache/ambari/tree/trunk/ambari-web] and
> [admin-admin|https://github.com/apache/ambari/tree/trunk/ambari-admin/src/main/resources/ui/admin-web].
> It is worth noting that the update of Jquery and Bootstrap in
> [#3770|https://github.com/apache/ambari/pull/3770] brought many improvements,
> including: cleaner and more modern syntax, and easier-to-use and more
> controllable new components. However, it is undeniable that this update has
> also exposed some issues:
> # The underlying frontend framework ([emberjs|https://emberjs.com/]
> {_}Version: v1.0.pre{_}) has not been updated, and its compatibility with the
> new version of Jquery is poor, which can lead to unpredictable results
> (AMBARI-26252, AMBARI-26193, AMBARI-26251). CVE vulnerabilities are also a
> hidden danger.
> # The Bootstrap upgrade has a significant impact on global styles, including
> some breaking changes, and conflicts with the old [custom
> styles|https://github.com/apache/ambari/tree/trunk/ambari-web/app/styles]
> (AMBARI-26199, AMBARI-26250).
> # The build tool ([brunch|https://brunch.io/] {_}Version: v1.7.20{_}) is too
> old, and the latest version stopped maintenance in 2023. Brunch itself is not
> suitable for large-scale web applications, lacks dependency analysis and tree
> shaking, and its core packaging mechanism will result in very large bundle
> size. This version also does not support proxies.
> # There is a lack of code formatting standards. There are no prominent
> formatting tools for [handlebars|https://handlebarsjs.com/] and there are [no
> plans|https://github.com/prettier/prettier/issues/5340#issuecomment-641954294]
> to support it.
> # Frontend module building is coupled with Maven, which makes debugging
> difficult for developers.
> # Dependency management is missing. Multiple frontend modules are scattered
> across modules, making it difficult to unify dependency versions and leading
> to redundant test code.
> And so on...
> It is worth noting that this submission may be the opportunity to upgrade the
> entire frontend technology stack. Considering the difficulty and benefits of
> some upgrades, AMBARI-26060 and
> [mailing|https://lists.apache.org/thread/rxfd35rnnd0sot0lc0tgftpsr7l5yq36]
> chose to refactor the entire frontend application (including ambari-web and
> ambari-admin) using React. As the saying goes, "A good beginning is half the
> battle," here I provide a possible
> [solution|https://github.com/apache/ambari/pull/3967#issuecomment-2788573351]:
> !image-2025-05-19-18-41-01-314.png|width=652,height=257!
> The frontend code for ambari-admin would move into
> [ambari-web-next|https://www.google.com/url?sa=E&source=gmail&q=https://issues.apache.org/jira/browse/AMBARI-web-next]
> as a package, and the React-refactored
> [ambari-web|https://www.google.com/url?sa=E&source=gmail&q=https://issues.apache.org/jira/browse/AMBARI-web]
> would also live there as its own package. Shared components (like buttons,
> tables, etc.) would be handled by a ui-shared package. Meanwhile, the classic
> [ambari-web|https://www.google.com/url?sa=E&source=gmail&q=https://issues.apache.org/jira/browse/AMBARI-web]
> stays untouched.
> Here’s how it could look:
> {code}
> ...
> ├── ambari-views
> ├── ambari-web
> │ ├── api-docs
> │ ├── app
> │ └── ...
> ├── ambari-web-next
> │ ├── web
> │ ├── admin
> │ ├── ui-shared
> │ ├── utils-shared
> │ ├── package.json
> │ └── ...
> ├── ...
> └── version
> {code}
> Here’s what we’d get out of it:
> # With pnpm workspace, we’re not just sharing components—we’d also share
> dependencies and keep versions in sync. That’d speed up dev and builds(CI/CD)
> time.
> # Keeping the original ambari-web as-is means we don’t have to mess with
> existing docs or guides (though admin might still need some tweaks). We can
> focus on writing fresh docs for the refactored projects.
> # Moving ambari-web would bundle in vanshuhassija’s change commits, which
> might make tracking issues a bit trickier. This can be avoided.
> Regarding the technology stack, I offer my personal suggestions:
> # Build tools: [vite|https://vite.dev/],
> [plugin-legacy|https://www.npmjs.com/package/@vitejs/plugin-legacy].
> [CRA|https://create-react-app.dev/] is gradually being
> [deprecated|https://react.dev/blog/2025/02/14/sunsetting-create-react-app],
> and vite has become a good choice for React applications, providing a modern
> development process.
> # Engineering tools: [prettier|https://prettier.io/],
> [eslint|https://eslint.org/], [husky|https://typicode.github.io/husky/]
> (force commit formatting),
> [lint-staged|https://github.com/lint-staged/lint-staged].
> # i18n: [i18next|https://www.i18next.com/],
> [react-i18next|https://react.i18next.com/],
> [i18next-browser-languagedetector|https://github.com/i18next/i18next-browser-languageDetector].
> # Web requests: [axios|https://axios-http.com/].
> # Utility functions: [es-toolkit|https://es-toolkit.slash.page/],
> [react-hookz/web|https://github.com/react-hookz/web],
> [clsx|https://github.com/lukeed/clsx].
> # State management: [zustand|https://zustand-demo.pmnd.rs/],
> [immer|https://immerjs.github.io/immer/].
> # Component library: [shadcn|https://ui.shadcn.com/]
> # Routing: [tanstack/react-router|https://github.com/tanstack/router]
> # Testing: [vitest|https://vitest.dev/]
> Additional suggestion, regarding package.json script commands:
> {code:java}
> {
> "scripts": {
> "lint": "eslint --ext .ts,.tsx --ignore-path .gitignore .",
> "fix": "eslint --fix --ext .ts,.tsx --ignore-path .gitignore .",
> "format": "prettier --write ./**/*.{tsx,ts,scss,json,md}"
> }
> }
> {code}
> With the cooperation of lint-staged, we can effectively control the code
> format finally submitted to the repository:
> {code:java}
> {
> "lint-staged": {
> "src/**": "npm run format",
> "src/**/*.{ts,tsx}": "npm run fix"
> }
> }
> {code}
> In network communication with ambari-server, I noticed that request links are
> often very long, similar to GraphQL in function, but the parameters are
> placed in the link, which adds some difficulty to debugging. For example, the
> following path is for querying Hosts information. I often need to concentrate
> to know whether the query includes a certain field:
> {code:java}
> /api/v1/clusters/ckf_test/hosts?fields=Hosts/rack_info,Hosts/host_name,Hosts/maintenance_state,Hosts/public_host_name,Hosts/cpu_count,Hosts/ph_cpu_count,alerts_summary,Hosts/host_status,Hosts/host_state,Hosts/last_heartbeat_time,Hosts/ip,host_components/HostRoles/state,host_components/HostRoles/maintenance_state,host_components/HostRoles/stale_configs,host_components/HostRoles/service_name,host_components/HostRoles/display_name,host_components/HostRoles/desired_admin_state,host_components/metrics/dfs/namenode/ClusterId,host_components/metrics/dfs/FSNamesystem/HAState,Hosts/total_mem,stack_versions/HostStackVersions,stack_versions/repository_versions/RepositoryVersions/repository_version,stack_versions/repository_versions/RepositoryVersions/id,stack_versions/repository_versions/RepositoryVersions/display_name&minimal_response=true,host_components/logging&page_size=10&from=0&sortBy=Hosts/host_name.asc&_=1747645752540
> {code}
> The reason is that the query information contains fixed fields such as
> Hosts/rack_info, Hosts/host_name, Hosts/maintenance_state. The word "Hosts"
> is repeated here. Can we design a general structure and function to solve
> this problem? For example:
> {code:java}
> interface FieldsObject {
> [key: string]: Array<string | FieldsObject>
> }
> const HOST_FIELDS: Array<FieldsObject | string> = [
> 'alerts_summary',
> {
> Hosts: [
> 'rack_info',
> 'host_name',
> 'maintenance_state',
> 'public_host_name',
> 'cpu_count',
> 'ph_cpu_count',
> 'host_status',
> 'host_state',
> 'last_heartbeat_time',
> 'ip',
> 'total_mem',
> ],
> host_components: [
> 'logging',
> {
> HostRoles: [
> 'state',
> 'maintenance_state',
> 'stale_configs',
> 'service_name',
> 'display_name',
> 'desired_admin_state',
> ],
> },
> ],
> stack_versions: [
> 'HostStackVersions',
> { repository_versions: [{ RepositoryVersions: ['repository_version',
> 'id', 'display_name'] }] },
> ],
> },
> ]
> function flattenObjectPaths(arr: Array<string | FieldsObject> | string):
> string {
> if (isString(arr)) return arr
> const pathSet: Set<string> = new Set()
> function processItems(items: Array<string | FieldsObject>, prefix: string =
> ''): void {
> items.forEach((item) => {
> if (isString(item)) {
> const path = prefix ? `${prefix}/${item}` : item
> pathSet.add(path)
> } else if (isObject(item)) {
> Object.entries(item).forEach(([key, value]) => {
> const newPrefix = prefix ? `${prefix}/${key}` : key
> processItems(value, newPrefix)
> })
> }
> })
> }
> processItems(arr)
> return Array.from(pathSet).join(',')
> }
> {code}
> I believe this would be much clearer. At the same time, we can also try to
> encapsulate all network request logic into a new package: api-adapter:
> !image-2025-05-19-18-45-42-911.png|width=298,height=341!
> Below is the directory structure:
> {code:java}
> ambari-web-next
> ├── web
> ├── admin
> ├── ui-shared
> ├── utils-shared
> ├── api-adapter <===
> ├── package.json
> └── ...
> {code}
> The benefit of doing this is that in web and admin, we no longer focus on the
> specific logic of requests, but pay more attention to the business level.
> Adjustments to ambari-server will only affect the api-adapter package.
> Perhaps we can adapt to the golang/rust version of ambari-server in the
> future?
> what are your thoughts or suggestions for improvement?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
