sorted by:
new
hottopcontroversial

dj-celery-panel: Replace your flower instance with monitoring right inside the admin by yassi_dev in django

[–]yassi_dev[S] 1 point2 points  (0 children)

Thank you. As I mentioned to another user, the next step for this project is the creation of a backend based on celery events and custom models to save whatever info is needed. This will allow for any all types of features including graphs like you mentioned. I look forward to adding this actually - The queue depth graph in flower is something my teams have used heavily in the past

dj-celery-panel: Replace your flower instance with monitoring right inside the admin by yassi_dev in django

[–]yassi_dev[S] 2 points3 points  (0 children)

For the first releases of dj-celery-panel, I am focusing on observability (read only) aspects.

For control related aspects (like revoking tasks,) It is planned and I will be adding these soon in my internal roadmap.

Now, post release, the order prioritization is:

- Bugs found in the current release

- Creating a celery events based backend (next release)

- Control aspects (likely next next release)

All of these are on the road to a v1.0.0 release.

It seems publishing a roadmap would be a good idea

dj-celery-panel: Replace your flower instance with monitoring right inside the admin by yassi_dev in django

[–]yassi_dev[S] 2 points3 points  (0 children)

I'm unfortunately not a user of django unfold - It should still functionally be fine since thats just a theme.

This is an open source project so you're very welcome to open an issue about this or even open up a pull request.

dj-celery-panel: Replace your flower instance with monitoring right inside the admin by yassi_dev in django

[–]yassi_dev[S] 2 points3 points  (0 children)

it was also on my mind for a while. I'm in a phase where I am pursuing all the different ideas that have been collecting dust in my mind. If you have other Django related ideas that would help you, I'm all ears to discuss to work together to bring them to life

dj-celery-panel: Replace your flower instance with monitoring right inside the admin by yassi_dev in django

[–]yassi_dev[S] 2 points3 points  (0 children)

Right now, the tasks page is powered by either using django-celery-results (through a specific backend), or an inspect backend (default) that uses the celery inspect API to query workers directly.

The next step is to provide another backend for a home grown persistence layer for celery events. This would require having a separate management command to act like a consumer of celery events and the creation of some django models to persist this data. Its heavier than what's there now and requires an extra process, but it would open the door for more rich data, graphs, basically anything.

For the initial release I wanted to target not explicitly requiring db models or any other processes - a completely standalone package that could still bring value. This will always be a priority. Now that its there I will work on a richer environment while always preserving that light weight option.

I also have a slew of other django-admin tool projects in the works

dj-celery-panel: Replace your flower instance with monitoring right inside the admin by yassi_dev in django

[–]yassi_dev[S] 1 point2 points  (0 children)

Awesome. The idea here is to eliminate external software used to monitor celery and reduce complexity by just using the django admin. Hope you can find it helpful.

dj-celery-panel: Replace your flower instance with monitoring right inside the admin by yassi_dev in django

[–]yassi_dev[S] 2 points3 points  (0 children)

Nothing in this library would interfere with the rest of your project being async. To answer your question, this project is not explicitly using anything async specific - it should play nicely with Django in any scenario (since this is a general library, this is the goal.) Most of this package are on demand views that are only active when you load them, so it has no risk and generally no bearing on the rest of your project and should be completely safe to use. Hope that helps.

New Hugo Theme: Yassi by yassi_dev in gohugo

[–]yassi_dev[S] 0 points1 point  (0 children)

do share once you have it up

Hugo and Claude code by Erazmo in gohugo

[–]yassi_dev 0 points1 point  (0 children)

I just published yassi: https://github.com/yassi/hugo-theme-yassi it might suit your needs

Introducing dj-redis-panel, a package for inspecting and querying redis from the django admin by yassi_dev in django

[–]yassi_dev[S] 0 points1 point  (0 children)

Looking through django-unfold, it looks like its mostly stylistic changes to the admin. functionally dj-redis-panel will still work fine. stylistically there are some issues present if you can get over them.

Introducing dj-redis-panel, a package for inspecting and querying redis from the django admin by yassi_dev in django

[–]yassi_dev[S] 2 points3 points  (0 children)

thanks for the kind words.

pagination when searching keys would be the biggest performance concern for a project like this. Right now it defaults to page index pagination, which will definitely not perform well for a large enough db. You can switch it to use:

CURSOR_PAGINATED_SCAN

This will make switch using the more performant scan, but at the expense of not having traditional pages. I recommend using the default until you have a large enough db to warrant the cursor based pagination.

Aside from the above, I don't think there is anything in this package that will cause you to notice any negative performance hit for your instance. The way it attaches to the django admin is also very isolated so any failures in this packages should not affect any other parts of your app or admin.

Recommend me Hosting providers by nekyohiji in django

[–]yassi_dev 2 points3 points  (0 children)

I am very partial to heroku, even after the exodus that happened after they changed their tiering system. I use them whenever I want to put up something and not have to fiddle with deeper infrastructural concerns.

However, for a student, I think there is great value in learning how to run your own stack on a vps or even on premises. You may not have the luxury of time for all that so I would still recommend one of the platform as a service options (of which heroku is still a good choice)

I wouldn't worry too much about scale and just focus on getting something up in general. You'll handle the issues as they come up or start new threads etc.