cachethq / core Goto Github PK

Cachet should fire events for various model events.

Hi there!
I don't really understand why, but after making all the commands in the README to run Cachet in dev mode, I indeed get INFO Server running on [http://127.0.0.1:8000]. in the console, but when going on the URL, I have the following page showing up:

Would you know how I could fix this problem?
Thanks!

The API needs implementing for creating metric points. This isn't super straightforward as we need to first check whether the last created point was within the metrics threshold and increment a counter instead. You can see the past implementation at https://github.com/cachethq/cachet/blob/f40da226670a92934170c1adcfff3d1c40a6096b/app/Bus/Handlers/Commands/Metric/CreateMetricPointCommandHandler.php#L80-L98

However, metrics should be considered an "expensive" operation and so, I think we should make use of the cache instead of querying the database each time.

We need to provide any static strings as a translation file.

I'm quite keen on the idea of this package only containing the English US translations, then having other packages which can be installed to provide additional languages. Are there any objections to this?

Cachet 2.x has the ability to set various settings. These are stored in the database, but then also cached into a configuration file for performance.

I think as a first pass at implementing this, we can skip writing the configs to a file.

Also, I wonder whether we'd benefit from migrating our existing settings to something like spatie/laravel-settings, since most of Cachet's internals will need to read the settings at various points of the lifecycle.

We're also going to add additional settings such as:

• Colours for dark mode
• Images

We need to implement the metric charts into the status page.

Cachet 2.x can store custom meta data to be passed to incidents. We can extend this in 3.x to support custom meta on most, if not all models.

• Create Meta model.
• Add Meta relationship to models.
• Update actions and API to support passing meta.
• Add meta to the Http resources.

In Cachet 2.x, we had a setup wizard that may also be automated via the CLI.

• Routes
• Middleware to prevent access to /setup once Cachet is already configured
• Writing .env / settings.
• UI
• Tests

All index API endpoints should order the results as expected (by default). This also needs to account for filtering for example, hidden component groups.

Jump24 have kindly designed the new dashboard us. We'll need to code this design using Tailwind.

Unlike the status page we'll use Vue and Inertia.js for the dashboard. In my opinion, this is better suited for the task.

When creating or updating a component group (CreateComponentGroup or UpdateComponentGroup) it should be possible to supply an array of components that will attached to the group components.component_group_id = $componentGroup->id.

It's already possible to create a new component within a group, but you can't mass-assign components into a group in one request.

We should provide an RSS feed of incidents and their updates.

We need a way to generate and store a unique ID that will be used by the Beacon. This is provides us with anonymous telemetry.

This should live in the Cachet class as a applicationId() method. In 2.x, we sha1 a random generated string, https://github.com/cachethq/cachet/blob/2.4/app/Integrations/Core/Beacon.php#L87-L91. We could do the same again, then store in the DB.

We need to bring back support for tags.

• In 2.x only components support being tagged, but we could extend this to other areas including; incidents, metrics and schedules.
• The API needs to support filtering the endpoint by a tag.

We need to bring back the various notifications sent by Cachet.

• Components
  • ComponentStatusChanged
• Incidents
  • NewIncident
• Incident Updates
  • IncidentUpdated (this could be moved into the Incidents namespace above.
• Schedule
  • NewSchedule
• Subscriber
  • VerifySubscription
• System
  • Test

Jump24 have kindly designed the new status page for us. We'll need to code this design using Tailwind.

I think that the status page itself should be written using Blade & Livewire with sprinkles of Alpine.js for some additional reactivity. My thinking here is that the status page needs to render as quickly as possible and should be easily crawlable by search engines.

In dark mode the cachet logo looks a bit funny.

This should be able to fix that:
https://www.stefanjudis.com/notes/how-to-define-dark-light-mode-images-in-github-markdown/

As discussed here, Cachet should probably implement it's own API rate limiting middleware that can be configured via the cachet.php config file.

Incident templates should support Twig (for backwards compatibility) and Blade as a new renderer.

The renderer should be selected automatically via IncidentTemplateEngineEnum.

We could optionally broadcast events through websockets and have the status page / dashboard update in real time for anyone looking at it.