Re: Should I use Django-Rest-Framework for performance reasons, despite not needing an externally-consumable API?

Hi Andréas, thanks again for the response.

I've decided to take your advice and not going to be adding DRF because I simply don't need an API, so no need for the added complexity.

It's funny that you suggest using pandas for the csv import/exporting though. I kept seeing pandas mentioned everywhere! So I finally looked into it last night and Wow! Pandas is amazing and dataframes are actually quite a profound data type. 

I'm definitely going the pandas route for converting data types. So thanks for the heads up and last push to investigate it!

On Friday, 26 October 2018 12:29:10 UTC-4, Andréas Kühne wrote:

Hi again,

I don't think there is any performance reason to add DRF. You should architect your application in a way that the database is the main speed issue (for example, avoid doing loops in python) - then you can add som caching to the queries that you know can be cached. That would give you the best performance regardless if you are running DRF or not :-)

And regardless the added complexity is probably not worth it - as long as you aren't using it for an external API.

DRF doesn't help importing from / exporting to CSV - it mainly understands json. I would use some form of CSV export lib - there are a lot of them on pypi. Or pandas of course!

Regards,

Andréas

Den fre 26 okt. 2018 kl 16:14 skrev Tyler Lynch <tyler...@gmail.com>:

Hi Andréas,

Thanks for getting back to me!

I guess adding DRF to my project right now would be a case of premature-optimization then. I had a bit of muddied thinking such that I thought DRF might help with caching the database queries, but I guess that is completely independent of DRF?

Is there no performance reason to adopt DRF?

I'm basically just running a crud app. One thing I was hoping DRF might've been able to help me with though is importing/exporting the data as csv's as well. I'm not sure though if it's more expedient to just use the csv reader. 

Thanks again for the response

On Friday, 26 October 2018 03:30:28 UTC-4, Andréas Kühne wrote:

Hi,

I really don't get why you would want to do that? If you are doing only a "standard" website - you don't want or NEED the extra complexity of running DRF. It's not that DRF is hard to setup - but for example if you want to present a list of items - in "standard" django, you create the list and add it to the context data. In DRF - you need to create the list, serialize it into json (or xml if you want to go that route), on the frontend you then need to deserialize the list and present it.

You add a lot of complexity and need to write a lot of frontend code.

Working with "standard" django - you can cache a lot of things in different places. You can for example cache an entire response with template, or just cache the database calls and present them in a template. This is not hard to cache or to setup. 

I think I would need to know more about your use case to understand it better :-)

Regards,

Andréas

Den fre 26 okt. 2018 kl 03:44 skrev Tyler Lynch <tyler...@gmail.com>:

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.

--
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/7a64fee3-d691-4c68-b29c-cd871c52fbc2%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+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@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/eea25ad8-25dd-46d0-ba49-c0d93039962b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.