As it is told: “If there are no issue, and engineer will create some”. I have created a web interface, but now I am not really satisfied with the result. I have decided to start it from scratch.
This article is part of a series. Other already public articles:
Home Ticketing #1 – What my back(end) at home!
Home Ticketing #2 – High level overview
Home Ticketing #3 – Tables and relationships
Home Ticketing #4 – Handle data – EF setup
Home Ticketing #5 – Server environment
Home Ticketing #6 – REST API
What about the current interface?
I have created a web interface. My purpose was to make it “desktop like skin”, not because of the practically reason, I rather looked for this as a challenge. At the end, it works and actually I am using it when I am checking that everything is alright on my environment. You can see an image about, how does it look like.
As you can see, there are windows, there are like a “start menu” for applications. It is possible to switch among opened applications, etc. It also works fine, there is no technically problem with that. But I want to, not just change it, but rebuild and rethink the whole concept. Well, you could ask that “Why?”.
Actually, this web interface is using only for ticketing purposes, but I want now, is a shared center of my current (and future) applications. This could be integrated into this model on a difficult way.
What now?
I have begin to redesign and rethink what kind of functionalities I want in the future:
1. Create dashboards
2. Integrate my applications and allow them to have dashboard elements
3. Store my server related documentation on same site (like a wiki)
On the current interface, I use Blazor Webassembly. As it is webassembly it runs on client machine and fetch information from different APIs. At the new interface, I will change to Blazor server application, as the new interface is rather fetch information from the server and it sounds better from performance view, in my mind of course.
I made a quick image, how I image it, when it is done. This image contains a menu on left side, with the available functions. On the main part the enterprise dashboard can be seen (not fix how dashboard will look, it is just a more-or-less skin).
Dashboard plans
Regarding dashboard, I have not decided that dashboard elements will hard-coded in the project or it can be added created dynamically. Last option would be more elegant and better sustainability in a later grown in the future, but I am not sure yet, that it is really required for me.
Regarding dashboard, I will plan to implement 2 types of dashboards:
1. Enterprise dashboard: or with other worlds, common default dashboard. Every user who log in can see, like a common focal point. It could be changed only by admins
2. User dashboard: each users would be able to define their own dashboard(s). For example, John deployed a new app the a development environment, then he can create a dashboard about that application (CPU, RAM usage, database activities, etc.). Only he could see it.
Documents
I plan to make a component to write and store online documentation like a wiki page. During edit, I want to use similar markdown format method like Gitlab, Github uses. Why? Because I have got used to that! 😀
Applications
I have already some service what I want to add for it and there some what I plan in the future. This website will be a center of these applications from user interface view. When I design these applications I plan them like an ecosystem, so they will be able to communicate with each other and use their advantages if needed.
Designed applications are involved into the interface:
– Alerting services: this is that component, what this article series showed
– System monitoring: it is a component, which is monitoring the whole system and every process. Besides it is also gather information about performance of my databases. In this component it will be possible to create rules, for example “Create an alert if number of queries in database is twice as normal” or “Kill the process and make an alert if a non-system related process eat the CPU” and so on…
– Job scheduling: cron and systemd timers are a very good stuff. Really, they are one of my favorite features on Linux. But it has some problem: it cannot handle relationship among jobs and I do not have a centrelized view about them on a focal system. For this, I plan to figure out an own application which has similar tasks like cron but it has more feature and it is able to execute commands on cross-system too.
System monitor and job scheduler is currently on 0% progress, they just exist in my mind now. But I will make them real!
Security
From security view, all of the applications and this website will use a shared database, so one password will fit for every application. Besides, I plan to introduce a “tag system”, where it can be limited that who have access for specified applications.
Final words
So, I am at the end of this home ticketing project, although I am not done. I still have ideas and challenges what I want to achieve and because I have infinity material to learn about each field, I am ready my challenge! 🙂
You could say that there are existing product (which could be better than I will create) for this what I want. But I keep in my mind the learning. If I install somebody else’s product, I will learn nothing. But if I write these on my own, I will (and must) learn a lot.
