I have no need for an externally consumable API, but I am interested in using Django-Rest-Framework simply for performance reasons.I'm led to believe that by decoupling my front and back end and then simply consuming the DRF api within views, that I can setup a better caching system? Does this make sense? Using DRF from an architectural standpoint (with the goal of optimizing caching & performance) despite not needing an externally used API? Or am I totally off base and confused? Any advice would be much appreciated.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/8b55ff9a-e915-4546-bf3c-1b20a25e4826%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi,
Using DRF can help when there is a need for decoupling the presentation layer from the logic one, for instance if the logic is planned to be used in other scenarios that the interactive Web app.
One can argue that structuring the logic as a Python package can do it, but this will not work if the deployment involves splitting front-end and logic back-end in distinct nodes (f.i. in a Docker multi-container based deployment).
Introducing DRF adds for sure a level of complexity and you'll loose some potential caching benefits, but it lets the path opened if ever the above mentioned evolution of the application appears in the future. You will not have to refactor anything then.
The bottom line is that there is no absolute answer to the question. It depends on what can be the plans for the application evolutions in the future.
Regards
Eric
To post to this group, send email to djang...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/8b55ff9a-e915-4546-bf3c-1b20a25e4826%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to djang...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7a64fee3-d691-4c68-b29c-cd871c52fbc2%40googlegroups.com.
Hi,
Django does a lot of job WRT caching data at the ORM level and there is a "direct path" from the UI and the ORM. I've the feeling that putting a REST API in the middle have chances to defeat some of the involved strategies.
I guess DRF can be added to the project at any time
Yes of course, but the views of the UI layer will have to be reworked. When dealing directly with the ORM, they use query sets. When the REST API is added, you'll have to deal with serializers instead. The migration will represent some work.
So if you think that there are 80% of chances the application will evolve to a REST API based architecture in a not too distant future, my advice would be introduced it from the begining.
But once again, this is a matter of appreciation.
Best
Hi,
IMHO it is just a matter of planing for the future. If you are certain that nothing else but your current app will need to play with the models, adding a REST API (be it written on top of DRF or not) is not required at all. To my knowledge it will not bring any benefit WRT performances. Chances are that it will be the opposite (but not in dramatic proportions however if the underlying stack is properly chosen and configured) since the REST API adds a layer of HTTP based exchanges.
Regards
Eric