jojo64

We have a European market of Energy. If it's not sunny && windy in France, maybe it is in Germany or Spain etc.

Did you try to learn another language? I found that people who learnt another language are less conservative on their native language and make effort to speak slowly etc. Generally speaking they are more open-minded when they travel abroad.

For our usage that's my point of view. When you need to manage ws & asynchronous task, you are just ending stacking technologies to make Django enter in 2018 (remember tornado?). I would say that the framework didn't followed technology evolution and so our new requirements

For old good stuff is still a good framework. It really depends on your usage.

Well I don't blame python. It's just that the stack python/Django/DRF is not more efficient for us now as our requirements changed spa/ws/asynchronous tasks. Investing in this stack is more and more difficult as our requirements don't fit. But yes we can also check flask/sqlalchemy . I'm just afraid of the stuff needed for ws/asynchronous task. This will not simplify our architecture.

Good point. Lost of performance in the query is acceptable a as we gain support of MySQL & Postgresql. Lost of performance in JSON serialisation is more difficult to accept.

The goal will be to take benefits of the elixir/OTP platform and the concurrency assets. Today we have a lot of asynchronous/background task distributed with rabbitMQ. If our investment provide better stack and simplify the architecture , this could be a better ROI than keep the current stack up-to-date.

Well we can migrate to python 3 but this will be more investment in a stack that is more and more obsolete (Django) for SPA. Developers need also to learn the new best practices for python 3. At the end this will result in short term with python 3 code base written in python 2 style without the benefits of typing etc. Investment without benefits except keep our stack up-to-date.

Each solution for Python/Django add complexity: - async -> celery/rabbitmq - websocket -> Channels, Daphne, asgiref, channels_redis, redid.

It's quite huge to manage.

This implies to create 2 queries each time you want to hit the database. One query for PostgreSQL and one query for MySQL. This is something we can't afford. Do you have some good tips to manage this ? To be honest the ORM is required only to support multiple database.

We are in python 2.7 and we need to migrate the application to python 3.0 For me it's another language to learn if we want to make good python 3 code. Python/Django/DRF is a stack with very poor performance if you are dealing a lot with JSON. We already have API points in golang with very good performance. No need to deal with nginx/CGI etc. nightmare. Conclusion was that our code in golang has a lower downtime. (Typed etc.)

The issue is on the ability to provide code compatible with MySQL and Postgresql. Without ORM you have to duplicate your queries.

So looking at a framework with ORM we are doing a benchmark of Elixir/Phoenix/Ecto. This solution could simplify our architecture a lot: websocket with room shared between server etc.

Bad point is the lack of documentation on Phoenix 1.4

Indeed we are also looking for a framework to change our Django/python. We were looking at golang as half of our backend is in go but the lack of ORM make the choice impossibile. Gorm, xorm.. are not supporting Foreign Key...

Yes you can write your raw SQL query but that means that your backend can't support MySQL and Postgresql (one of our prerequisites for on-premise deployment).

So we are ending with phoenix. Very sad that golang doesn't provide a very good ORM.