Web app to browse the data

[prototux]

To browse and view the data, it would be very useful to have a web-app available that parses the yml files.

Unfortunately, i don't have any (front) web dev experience, so this is a todo (until i learn vuejs or somebody help on it) issue.

[rachmataditiya]

you can ask chatgpt now :D

[radston12]

Well I know this project is with one foot in the grave, but I had some free time and did some work (only prototype for now)

This comment is just a simple question:

I currently have the following file structure:

In white there is the database, and in green (and yellow) there are all the programs / tools.
├── buses
├── cars
├── dbmuxev
├── nodes
$${\color{green}├}$$ psa-db-tool
$${\color{green}├ }$$ sandbox
$${\color{yellow}├ }$$ web
├── .gitignore
├── .gitmodules
├── architectures.yml
$${\color{green}├ }$$ dumball.py
├── LICENCE
├── README.md

The question now is:

1. Move web-dev to its own repo
2. Make a folder called something along the lines like _tools where everything marked green/yellow should go
3. Keep it like it already is

If you feel like this is an unnecessary question, I am sorry. I just wanted to clarify how I should continue after reading. [Message #the-big-yml-project]

[prototux]

Ideally, the global architecture would have been (if there was proper adoption of the standard) something along this:

• There's a standalone repo for the dbmuxev format + repositories for libraries implementing the format (and those should probably be on OpenLeo's namespace, not here)
• This repo would only contains the yml files + the sandbox folder, aka only documentation (sandbox isn't meant to be used as-is, it's more like "documentation thru code")
• There's another repo (something like the awesome-* lists) which lists the main dbmuxev repo, the data sources (which wouldn't only be this repo i hoped) and the tools using dbmuxev (which then would be on each dev's own namespace)

For the web app, ideally, i hoped to be able to make something like an app using the api + one-page-app model, with the API being "only" a yml-to-json-api app, and the client querying that api to display the data.

I hope this answers your questions, feel free to send a message on Discord if you need/want :)

[radston12]

Thanks for the reply. I will get to the repo architecture and file structure after my thing leaves the "prototype/development" phase.

But for the parsing of the yml in Node.js, I needed to do some changes to the general dbmuxev layout:
master...RadSton:PSA-RE:master

Most of these were just removing duplicate keys.
(Also there is one new frame in the master branch from the discord in there, which I could describe because it was in English)

Small change summary:

1. When cars had multiple codes I combined the codes into an array
2. I changed some signal names if they were duplicate and the description was different
3. Removed duplicate CDPL in nodes
4. Added 'bitrate' and 'protocol' value to architecture->network->bus so that I could include that data in the .dbc parser
5. Added some stuff (name & comment for EMF node ; etc.)

If you have any concerns on these changes please tell me, this is still your project,

I guess the rest of this comment is a "dev log":

Well before I even asked I implemented an API that converts the yml structure to json but I also made the whole searching process from the client run on the backend (At the moment it was smart but when thinking about hosting it for the general public (which isn't / wasn't the goal yet) this may cause performance / resource issues).

The client-side is a single page application in vanilla javascript with basic css (not responsive yet).

The whole client/server web thing is in the branch web-dev folder web

(No comment needed; I may have to pause this project for the next 2 weeks since I also have other things to do, so I don't know how I will continue yet)

[silvered-shark]

Hi everyone, I’d be happy to help with this. I’m a full-stack developer with experience in Node.js, APIs, and frontend apps, and this YML -> JSON API + web app idea sounds really interesting.

I think the current direction makes sense. For now, it may be best to keep the web part in this repo while it’s still in the prototype phase, and move it to a separate repo once it becomes more stable. Separating the data, tools, and web app later would keep things clean and easier to maintain.

Regarding the API and search, moving most of the filtering and searching to the client side sounds like a good approach for performance and hosting. The backend can focus on parsing the YML and serving structured JSON, and we can optimize later if the dataset grows.

The schema and cleanup changes you mentioned also sound reasonable. It might help to document those changes so future contributors understand the format clearly.

If you’re open to collaboration, I can help with improving the API, structuring the frontend, adding search and filters, and making the app more responsive and production-ready. Just let me know where you’d like support, and I can start with a small PR.