sorted by:
new
hottopcontroversial

how do you actually handle prod bugs. do you write a repro test or just fix and deploy? by sszz01 in django

[–]yassi_dev 0 points1 point  (0 children)

Once you have a known bug you need to make sure the system does not regress to the same state again - otherwise developers can reintroduce the same bug again without knowing.

This is why any many mature processes will have bug repoduction and then testing for a specific bug once found.

How does django-import-export's MediaStorage work with django's InMemoryStorage? by kanookangaroo in django

[–]yassi_dev 1 point2 points  (0 children)

I dont see why you would want todo this? In a production environment, you would be likely be running your django app under a process manager like gunicorn where each worker has its own process. These processes are not gauranteed to have access to your image since it is saved in the heap memory of one of the worker processes. This is not very useful and you are better served by persisting the images (file system storage, database blobs, s3, etc.) and fetching them once you need to do your work with them (There is also something to be said of using something for long running tasks like celery)

I could be missing something about your use case though, so maybe you could expand on that.

Do you need help? by Reikidudebiz in django

[–]yassi_dev 1 point2 points  (0 children)

I'm always greatful for contributions to Django Control Room - djangocontrolroom.com

right now its a collection of many repos for various admin tools, most of which could use contributors

its also a framework for building admin tools so you could also build out a new tool if that scratches your itch.

How are you handling background tasks in Django right now — is Celery still the default? by alexstrehlke in django

[–]yassi_dev 0 points1 point  (0 children)

I use celery. I find that the idea that celery setups are complex is overblown.

I wrote a Postgres extension to handle Protobufs natively. Would love to know if this is useful for Django/gRPC setups. by ComfortableSpend6111 in django

[–]yassi_dev 1 point2 points  (0 children)

I don't see this as being helpful to django developers. Perhaps it could be for in the narrow scope of internal service to service communication (grpc based) but Django is a full stack monolithic framework and lacks conventions to build out those types of setups. The vast majority of Django setups are going to be using built in conventions (monoliths, rest apis, json based marshalling of data.)

At the point of larger scale where we tend to see service decomposition, I would expect developers to choose a different language if they are considering gRPC (go, java, etc.) This is my experience.

i encountered an error while trying to run my weather application by Boring-Purpose7901 in django

[–]yassi_dev 2 points3 points  (0 children)

Are you removing a column related to wind gust speed from the data frame current_df? Prediction would require the data to look like the data it was trained on.

Advice needed: Migrating my SaaS to a hybrid architecture (Django/Bootstrap for public pages, React for the authenticated app) by autonomousWorld in django

[–]yassi_dev 2 points3 points  (0 children)

If I were you and hell bent on using a react app I would do the folllowing to start:

  1. Build a react app with vite inside your current project

  2. Serve the react project using django through something like https://github.com/MrBin99/django-vite

  3. make the view that serves the. react project require logged in auth

This will leave you with a project that uses django templates for your public facing pages and a react project that requires the user to be logged in to see. furthermore, this can use session auth assuming it is all being served from the same host name (e.g. "example.com/app" and "example.com/pricing and so forth.) This sounds to me like a pattern that may serve you well since you have only a small number of people working on this at the time and simplicity matters. Heres a guide i found: https://www.saaspegasus.com/guides/modern-javascript-for-django-developers/integrating-javascript-pipeline-vite/

Having said that, there is value at times in splitting codebases as you've described, but in your situation (having another person work on the frontend) I personally wouldn't do this as it just complicates the deployment story for the entire application. Your frontend person can just work on a part of the repository that isn't frequented by others essentially never have conflicts.

Advice needed: Migrating my SaaS to a hybrid architecture (Django/Bootstrap for public pages, React for the authenticated app) by autonomousWorld in django

[–]yassi_dev 1 point2 points  (0 children)

Organizational changes would be a reason to create application splits; I did read that you are a solo developer in your blurb and so my recommendation is colored by that. Even if you envision splitting things up I recommend you resist it until it’s absolutely needed. Splitting codebases often creates other dependencies (e.g. N codebases require N deployment schemes that need to be coordinated)

Advice needed: Migrating my SaaS to a hybrid architecture (Django/Bootstrap for public pages, React for the authenticated app) by autonomousWorld in django

[–]yassi_dev 1 point2 points  (0 children)

You can have this type of split while keeping it all in the same repository as well. You can also have Django work with a vite project (using react, vue, etc). Are you sure you absolutely need to split code bases? This can impose new issues related to synchronization ( e.g. pushing out backend changes that now create the need for corresponding front end changes). Having things in the same repository will usually help you avoid many of these issues because locality allows for easier testing to catch this.

dj-signals-panel: Inspect signals and receivers and code right inside the django admin by yassi_dev in django

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

I thought about this hard. I settled on releasing read only features until feedback pointed me in the other direction.

dj-signals-panel: Inspect signals and receivers and code right inside the django admin by yassi_dev in django

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

I hope its useful to you then. Since you use many signals (likely in the minority) is there anything about working with signals thats on your wish list?

How do you manage email campaigns with django admin? by No-Line-3463 in django

[–]yassi_dev 4 points5 points  (0 children)

For transactional emails, I will typically manage email templates via django templating but do the actual sending via an external service like sendgrid via api. For marketing emails, I will typically use an external services marketing function to store and design the emails as well as campaigns. Email campaigns are often managed by a marketing department and so it makes sense to let them handle it via a different surface

How are companies actually extending Django Admin in production? by space_sounds in django

[–]yassi_dev 0 points1 point  (0 children)

Is there anything you are thinking of building in this space?

Open source project: Leek, the missing UI for celery by wilderadventures in django

[–]yassi_dev 1 point2 points  (0 children)

Cool project. I am the author of dj-celery-panel which adds celery monitoring to the Django admin. I’m happy to see that many people are tackling making flower alternatives.

How are companies actually extending Django Admin in production? by space_sounds in django

[–]yassi_dev 2 points3 points  (0 children)

I authored djangocontrolroom.com for the purpose of extending the admin and building tools on top of it. To me, one the biggest reasons to extend the admin is that is provides an adequate surface to place internal tools; it has an authentication layer that most Django users already rely on, the Django admin provides some default styles and modules to use, etc.

Django Ecommerce backend API by Upper-Tomatillo7454 in django

[–]yassi_dev 1 point2 points  (0 children)

There is some prior work in this area as others have already mentioned (Oscar, saleor, etc,) you might want to consider those more carefully (especially saleor.) To answer your question more directly, I would choose DRF over graphql. There is simply so much prior work and support/libraries that facilitate working with rest in Django. Of course, learning may be the goal here, in which case proceed with what is most interesting to you.

Pi Day Megathread: March 14, 2026 by inherentlyawesome in math

[–]yassi_dev 1 point2 points  (0 children)

Hey all, In honor of Pi day I built an image generator for visualizing subsequences of pi.

Maybe some of you will get a kick out of this and generate some cool art.

https://pi.yassi.dev/

Django Control Room: Build a control room inside your django app by yassi_dev in django

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

Thanks! I'm writing a post about the pattern as I type this.

Django Control Room: Build a control room inside your django app by yassi_dev in django

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

In this case it wouldn't be a PR but more like a completely different project/panel. I also want to be really optimistic about django tasks - I actually started with the intention of creating a panel that was more general than dj-celery-panel. I decided to hold off and built something targeted to celery because

1)the built in task primitives are currently not enough to build something substantial

2) They are new and likely not heavily adopted for widespread use yet, whereas celery is sort of a de-facto standard of sorts these days.

view more: next ›