5 ms·

What could you possibly be doing that you need those things within a Django app? If you're placing CPU-intensive and scientific code directly into your web app

What could you possibly be doing that you need those things within a Django app? If you're placing CPU-intensive and scientific code directly into your web app backend, I'd rethink your architecture before you consider switching languages.

CuriouslyC 10y ago
Of course anything long running is going to be run as a service via something like Celery. That being said, there are actually a lot of things you can do with SciPy for which the turnaround time isn't sufficient to justify dispatching multiple messages.
deleted 10y ago
[deleted]
collyw 10y ago
Come one, even scientific work will require a front end at some point. Not everything will be CPU intensive. And even if it is it may need some user interaction to get the task started - even if it is just uploading data to be processed offline.
- RussianCow 10y ago
  But you don't need the scientific code inside your Django app—it should live in a separate process. What I'm saying is there is no need to have the scientific code directly inside the Django app.
  - collyw 10y ago
    There are plenty of web based scientific apps. Genome browsers for example. Why would you have those in a separate process, when its essentially a crud app?
Scarblac 10y ago
> What could you possibly be doing that you need those things within a Django app? If you're placing CPU-intensive and scientific code directly into your web app backend, I have worked on a lot of projects that involve science related stuff and Django. Directly in the web app backend was relevant mostly for GIS apps that could take large raster data, process it based on the user's wishes, apply the right projections, apply a colormap and return an image to be shown on a map. Python has great tools for that sort of thing and it doesn't have to take much longer than rendering a HTML template does. Other than that, the CPU intensive science-related stuff usually ran in background tasks, with Celery or otherwise. But those would still need access to the database, so why not use the same Django models for the web backend and the background tasks. I find that once Django is part of your Python code it tends to find its way to all parts of it, through the ORM, settings files, handy admin interfaces, management commands as scripts, and so on.

CuriouslyC 10y ago

Of course anything long running is going to be run as a service via something like Celery. That being said, there are actually a lot of things you can do with SciPy for which the turnaround time isn't sufficient to justify dispatching multiple messages.

deleted 10y ago

[deleted]

collyw 10y ago

Come one, even scientific work will require a front end at some point. Not everything will be CPU intensive. And even if it is it may need some user interaction to get the task started - even if it is just uploading data to be processed offline.

RussianCow 10y ago
But you don't need the scientific code inside your Django app—it should live in a separate process. What I'm saying is there is no need to have the scientific code directly inside the Django app.
- collyw 10y ago
  There are plenty of web based scientific apps. Genome browsers for example. Why would you have those in a separate process, when its essentially a crud app?

Scarblac 10y ago

> What could you possibly be doing that you need those things within a Django app? If you're placing CPU-intensive and scientific code directly into your web app backend, I have worked on a lot of projects that involve science related stuff and Django. Directly in the web app backend was relevant mostly for GIS apps that could take large raster data, process it based on the user's wishes, apply the right projections, apply a colormap and return an image to be shown on a map. Python has great tools for that sort of thing and it doesn't have to take much longer than rendering a HTML template does. Other than that, the CPU intensive science-related stuff usually ran in background tasks, with Celery or otherwise. But those would still need access to the database, so why not use the same Django models for the web backend and the background tasks. I find that once Django is part of your Python code it tends to find its way to all parts of it, through the ORM, settings files, handy admin interfaces, management commands as scripts, and so on.