Hey Eric, thanks for getting back to me again! As I don't want to have an externally-consumable API for this application (would be more of a liability than asset for me right now), I am most likely going to not use DRF.
I know it'll be more time-consuming refactoring if I ever do decide to use DRF, but I'm okay deferring this decision for now. Do you think there's any reason to use DRF despite not needing an externally-consumable API? Would using an internally-consumed API have different benefits? It seems the consensus is that adding DRF is more likely to limit performance than enhance, as you suggested earlier. Regards, Tyler On Friday, 26 October 2018 18:02:43 UTC-4, Eric Pascual wrote: > > Hi, > > > You mention that adding DRF can actually make you lose some potential > benefits from caching? > > > 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 > > > Eric PASCUAL > > Centre Scientifique et Technique du Bâtiment > 290 route des Lucioles - BP 209 > 06904 SOPHIA ANTIPOLIS CEDEX > http://www.cstb.fr > > ------------------------------ > *From:* django...@googlegroups.com <javascript:> < > django...@googlegroups.com <javascript:>> on behalf of Tyler Lynch < > tyler...@gmail.com <javascript:>> > *Sent:* Friday, October 26, 2018 4:18:49 PM > *To:* Django users > *Subject:* Re: Should I use Django-Rest-Framework for performance > reasons, despite not needing an externally-consumable API? > > Hi Eric, > > Thanks for the response > > You mention that adding DRF can actually make you lose some potential > benefits from caching? Might i ask how that is so? I actually thought it > was supposed to be the opposite (shows you what I know tho hah) > > I guess DRF can be added to the project at any time tho, so there's no > need to build the project with DRF built-in from beginning. So if I do need > it down the road, it won't be difficult to add it in. > > > On Friday, 26 October 2018 04:28:23 UTC-4, Eric Pascual wrote: > > 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 > ------------------------------ > *From:* django...@googlegroups.com <django...@googlegroups.com> on behalf > of Andréas Kühne <andrea...@hypercode.se> > *Sent:* Friday, October 26, 2018 9:29:40 AM > *To:* django...@googlegroups.com > *Subject:* Re: Should I use Django-Rest-Framework for performance > reasons, despite not needing an externally-consumable API? > > 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 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 > > <https://groups.google.com/d/msgid/django-users/8b55ff9a-e915-4546-bf3c-1b20a25e4826%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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. > 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/CAK4qSCeFqeGT8EbZFbWOGpHKY36D4bwvayLBxGm0YsBBFX6jnw%40mail.gmail.com > > <https://groups.google.com/d/msgid/django-users/CAK4qSCeFqeGT8EbZFbWOGpHKY36D4bwvayLBxGm0YsBBFX6jnw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > 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 <javascript:>. > To post to this group, send email to djang...@googlegroups.com > <javascript:>. > 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/e35331db-df90-487e-af6e-4fb77071ec17%40googlegroups.com > > <https://groups.google.com/d/msgid/django-users/e35331db-df90-487e-af6e-4fb77071ec17%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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+unsubscr...@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/5c46062f-4b34-412c-a160-ed9fd0a6a040%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
