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.
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.
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
The changes from Python 2.7 to 3.x are hardly so dramatic that it's like learning a new language. I'm pretty sure your performance issues can largely be addressed after proper investigation where the bottlenecks are. I do understand how nice it is to have a simpler architecture, but make sure it's worth all the work.
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.
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.
I love Elixir (more so than golang), so I would sincerely recommend using it. Erlang concurrency story is lightyears ahead of Python3 asyncio (despite being older by maybe 20 years). And OTP has no equivalent anywhere.
But if you are migrating just to avoid spending a couple of days learning and migrating to Python 3 based on reading too much FUD I'm very saddened. Migrating from Python 2 to Python 3 is not much harder to handle than a Django migration. Though of course it depends on your codebase, but compared to moving to Elixir/Phoenix/Ecto it's a peace of cake.
Move to Elixir/Phoenix/Ecto because it fits your needs better than Python, be proud of it even. But please, learning Python 3 to write good Python 3 code coming from Python 2.7 is very easy, nothing like switching to a completely different paradigm...
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.
Normally people use something like uWSGI to host python apps behind Nginx - in any case, it’s something you figure out once and pretty much never deal with again. So it shouldn’t be an ongoing nightmare.
While I didn’t downvote you, I suspect the people that did have done so because it sounds like you’re making quite a naive mistake in blaming the tool for your issues. Changing language is almost certainly the wrong thing to do, period. You should profile your existing code and figure out where the real issues are. If you don’t know how to do that effectively, no amount of rewriting from scratch in a new language will save you.
Sounds like you really care about the ORM (though if you’re using the Django one, it’s pretty basic). Python has hands down the best ORM (SQLAchemy), so if that’s such a priority, then why not start there?
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.
I'm surprised you are worried about JSON performance and not ORM performance. It seems like if you really needed better serialization/deserialization you could just call a c module from python.
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.
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.
