Call for contributors - golang, typescript / angular, Docker / containerization

[kaysond]

With maintainer permissions on the repo (see #506 (comment)), but not a ton of time, I'm asking for the community's help to with the development work so I can focus on reviewing/merging PR's and triaging issues.

scrutiny is primarily written in go. The web front end is in typescript using angular as the framework. Releases are delivered both as binaries and as docker containers. If you have expertise in any of those and are interested in contributing, please reach out by commenting below so we can organize efforts.

Priorities are:

• get a new release out
• update the docker container to build more modern versions of smartmontools to resolve outdated drive db issues (and similarly update documentation for binary deployments)
• fix front end issues
• implement high value feature requests (e.g. custom attribute thresholds)
• update dependencies

[kaysond]

@venku122 @CoreyJ87 - would be great to have your help

[masoncfrancis]

Curious to hear the maintainer's thoughts on the fork at Starosdev/scrutiny?

[kaysond]

Curious to hear the maintainer's thoughts on the fork at Starosdev/scrutiny?

Would love to get some of those fixes merged here.

[AlliotTech]

Hi, I implemented a new frontend based on next.js + ts + shadcn/ui, will we consider a major UI overhaul? (Fully compatible with existing components without introducing changes to backend or other components.)

[kaysond]

Hi, I implemented a new frontend based on next.js + ts + shadcn/ui, will we consider a major UI overhaul? (Fully compatible with existing components without introducing changes to backend or other components.)

I know there are not a small number of UI issues, but none seem related to the framework. What's the point/benefit of moving frameworks? It's substantial change.

[venku122]

Hi, I implemented a new frontend based on next.js + ts + shadcn/ui, will we consider a major UI overhaul? (Fully compatible with existing components without introducing changes to backend or other components.)

I know there are not a small number of UI issues, but none seem related to the framework. What's the point/benefit of moving frameworks? It's substantial change.

1. Angular "sucks". I already updated a fork to use the latest version of Angular to address some CVEs. For a simple dashboard app it's much more boilerplate than is needed
2. React et al have a much larger knowledge base and general skill set so more people will be able to jump in and contribute changes.
3. While it is a substantial change since the design patterns are so different, the actual volume of code and number of pages/components is pretty small. There's 3-4 screens total in the dashboard

[AlliotTech]

Hi, I implemented a new frontend based on next.js + ts + shadcn/ui, will we consider a major UI overhaul? (Fully compatible with existing components without introducing changes to backend or other components.)

Added mobile responsiveness and multilingual support.

https://github.com/AlliotTech/scrutiny-ui

demo: https://alliottech.github.io/scrutiny-ui/

I have created a standalone frontend project that only needs to be mounted in a container.

services:
  web:
    image: 'ghcr.io/analogj/scrutiny:master-web'
    ports:
      - '8080:8080'
    volumes:
      - './data/config:/opt/scrutiny/config'
      - './data/web:/opt/scrutiny/web:ro' # <- mount static files here
    environment:
      SCRUTINY_WEB_INFLUXDB_HOST: 'influxdb'
    depends_on:
      influxdb:
        condition: service_healthy
    restart: always
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/api/health"]
      interval: 5s
      timeout: 10s
      retries: 20
      start_period: 10s

curl -L -o scrutiny-web-frontend.tar.gz https://github.com/AlliotTech/scrutiny-ui/releases/latest/download/scrutiny-web-frontend.tar.gz
tar -xzf scrutiny-web-frontend.tar.gz -C ./data/web

preview:

[CoreyJ87]

@kaysond / @venku122

I agree with everything Venku mentioned. The amount of boilerplate Angular requires is pretty extreme compared to React. I already went ahead and did the port here:
CoreyJ87#2

Its forked from Starosdevs fork but could easily be merged backwards.

There are still a couple things I want to finish and clean up when I have time, but I’ve been using it myself for a few weeks now and it’s been working without any issues. Although, I'm checking my own math here. So it would be probably be good for others to try it on more platforms. Beyond just porting the code, I also made some general cleanup and usability improvements to simplify things overall.

The codebase went from roughly ~100k lines of Angular down to ~10k lines in React, and it’s significantly more straightforward to work with. As Venku mentioned, far more people are familiar with React at this point, so onboarding contributors should be much easier. On top of that, the Angular version was relying on several libraries that are now deprecated or no longer maintained.

Long-term, I think moving to React puts us in a much better position in terms of stability, maintainability, and future upgrades. I was actually kind of blown away that 3-4 screens would require that much code. I guess its been a long time since I've used angular lol.

Edit: Oh I missed the message from @AlliotTech. I guess we could see which we like better overall. I used vite instead of next but also used shadcn/ui

[AlliotTech]

@kaysond / @venku122

I agree with everything Venku mentioned. The amount of boilerplate Angular requires is pretty extreme compared to React. I already went ahead and did the port here: CoreyJ87#2

Its forked from Starosdevs fork but could easily be merged backwards.

There are still a couple things I want to finish and clean up when I have time, but I’ve been using it myself for a few weeks now and it’s been working without any issues. Although, I'm checking my own math here. So it would be probably be good for others to try it on more platforms. Beyond just porting the code, I also made some general cleanup and usability improvements to simplify things overall.

The codebase went from roughly ~100k lines of Angular down to ~10k lines in React, and it’s significantly more straightforward to work with. As Venku mentioned, far more people are familiar with React at this point, so onboarding contributors should be much easier. On top of that, the Angular version was relying on several libraries that are now deprecated or no longer maintained.

Long-term, I think moving to React puts us in a much better position in terms of stability, maintainability, and future upgrades. I was actually kind of blown away that 3-4 screens would require that much code. I guess its been a long time since I've used angular lol.

Edit: Oh I missed the message from @AlliotTech. I guess we could see which we like better overall. I used vite instead of next but also used shadcn/ui

hhh, no problem. actually, since Scrutiny is a project with a separated frontend and backend, as I mentioned earlier, using a web mounting approach is a relatively lightweight and suitable solution.
Scrutiny itself can focus on the backend, data collection, and alerts, while encouraging more community-driven frontend solutions. WDYT?

[kaysond]

Thanks all for the feedback and especially for putting the work in already. I'm all for shrinking the codebase and encouraging contributions. Nonetheless, it's a big change that would need a lot of manual testing to ensure parity with the existing frontend. Given that there's nothing about angular that strictly prevents fixing the existing bugs, and that most of pressing issues are backend-related, this wouldn't be a high priority, assuming it's even something we'll take on.

Ultimately, I think @AnalogJ will have to make the call. It would probably be a v2.0.0 kind of thing.

[CoreyJ87]

hhh, no problem. actually, since Scrutiny is a project with a separated frontend and backend, as I mentioned earlier, using a web mounting approach is a relatively lightweight and suitable solution. Scrutiny itself can focus on the backend, data collection, and alerts, while encouraging more community-driven frontend solutions. WDYT?

I completely agree. It probably is worth rethinking Scrutiny as more of a backend-first project, with a clean API that different frontends can plug into.

I also like the idea of not hard-coupling Scrutiny to a single UI long-term. Having a default/bundled frontend is still important so things work out of the box, but keeping the core focused on data collection, analysis, and alerts gives us a lot more flexibility.

One thing I’d also keep in mind is Home Assistant. Not sure how many people using Scrutiny also run HA. But I could easily see HA becoming a frontend for Scrutiny for a lot of users, which makes having a well-defined and stable backend/API even more important. If we design around that, it opens the door to multiple UIs (web, HA, apps, others) without forcing the project to bet on one framework forever.

[CoreyJ87]

Thanks all for the feedback and especially for putting the work in already. I'm all for shrinking the codebase and encouraging contributions. Nonetheless, it's a big change that would need a lot of manual testing to ensure parity with the existing frontend. Given that there's nothing about angular that strictly prevents fixing the existing bugs, and that most of pressing issues are backend-related, this wouldn't be a high priority, assuming it's even something we'll take on.

Ultimately, I think @AnalogJ will have to make the call. It would probably be a v2.0.0 kind of thing.

That sounds good. I completely agree. Whichever UI we go with would definitely need more testing. Also kinda plays into what I mentioned. Make scrutiny be more backend focused and allow community UI repos to be released separately.

With all that said. I do think starodevs fork has alot of things fixed in it. We've made a good amount of progress in that fork. So it might be good to backport some of those features from his fork into this one. As @venku122 mentioned. He updated the angular part of it. I fixed the bug around seagate drives. Staro fixed a bunch of random things. So might be good to compare what the differences are now.