2

I'm developing an application with backend which will be also be used by mobile applications.

Therefore I chose to create REST API using DRF.

Now I'm deciding what to do with my frontend. I don't really want to use any javascript frameworks and would like to stick with Django.

I see that I can render HTML templates and forms using DRF (https://www.django-rest-framework.org/topics/html-and-forms/).

However I would like to stick with regular Django function based views and develop the application and simply expose REST API with DRF that can be used by mobile developers.

Would this be a good programming practice ? If not what are the drawbacks to such approach.

Marijus
  • 4,195
  • 15
  • 52
  • 87
  • What ever you do, the main question will be does it [scale](https://stackoverflow.com/questions/886221/does-django-scale), so ask you're self how deep is the rabbit hole ) – copser Feb 18 '19 at 17:52

2 Answers2

1

I think there can only valid answers in some circumstances, or subjective answers to questions like this. I think it's also somewhat true to say that if you're rendering all the HTML in Django, and there's no Javascript framework, then there's essentially no front end. Sure, the client still renders HTML with their browser, but you don't have to write or debug that.

Would this be a good programming practice?

Sure - it's definitely falling out of fashion, but it has been for numerous tasks. If your use case requires low client numbers and processing load, and few navigation switches/page reloads/data updates, a backend-everything design can feel really quick under some circumstances - the browser doesn't have to do any work or load any js libraries. Maybe you're mostly displaying seldom updated data, or collecting a large amount of data in big forms. We use this strategy for many services at my work because we own all the computers anyway and have less than a few hundred employees to support- we may as well work the servers we paid for harder, and less the laptops we also paid for (because users tend to accidentally spill coffee on slow computers, and ask for new, faster ones).

However, if this is for general web use you might find many users will expect the ability to enter/retrieve data without reloads, and the reload experience will feel slower then POSTing data and throwing up a pre-loaded spinner to distract the user. The capacity for many more users stressing the server may become a problem.

You also have only one code-base to support (for API and web anyway), and less languages and frameworks to switch between.

If not what are the drawbacks to such approach.

  1. Reloads between every navigation/load
  2. Processing load on the server - lots of users, or heavy computation can become expensive
  3. Page loses 'interactive' feel standard web users have grown to expect
  4. commits for the API supporting your mobile app and your web frontend become coupled (some pro-monorepo fans might consider this a positive). Some people might warn against coupling front and backend code, but I think Django lets you keep this tidy enough, so long as you're mindful to not write anything stupid into your views.
  5. You're making an API for your mobile apps anyway, and you could route all data access through this to reduce duplication, inconsistencies, bugs etc.
  6. You might like to make nicer components, or use existing component libraries that would be a pain without a js frontend
  7. you might have more issues with changing models and view coupling in the future, without abstraction via the API, which can be versioned more easily.
  8. You might lose the capacity for more effective caching, depending on your data, updates, layout etc.

Hopefully this will give you something to think about - like I said, I don't think there's a correct answer here - it depends on your use case, and I undoubtedly will have missed some points others might bring up. Honestly, I would be more personally inclined to lean toward using a js frontend.

Good luck with your project :)

Alastair Beattie
  • 11
  • 2
0

first you should ask yourself why do you want to use something like React, because despite it's popularity it's used for a reason Reuse of components , double way binding, etc. if you're doing something that is not big it's not a bad idea especially if you're good DRF.

the thing with react is that there is a lot of people using it you may find more help on the internet if you're stuck , although remember it's quite hard at the begining.

think about what you need for your application and remember that each framework is valid it has pros and cons

chuni
  • 136
  • 1
  • 14