Introduce React and DRF

[SiqingYu]

Currently, mygpo uses Django-templates for the frontend. I think we can decouple the frontend and backend by using React and Django REST framework. It would be a much cleaner architecture.

We can learn from sentry, which uses React extensively.

[SiqingYu]

@fundatillus @stefankoegl Your advice is appreciated.

[clementsjosh]

If it's something you want to try out, I don't see a problem with running a dev branch to code this out and see how it ends up.

I suggest we keep up with Django for now until a mature prototype is available to see how it plays out.

[SiqingYu]

Semantic APIs give us the flexibility to preserve the API V2 while migrating to V3. The main concern is user interface migration. But since we can let users choose the old UI, I think we can migrate smoothly. Though, expect server downtime during migrations. Also, we will deprecate the old APIs and UI once the new versions go into production. 😐

[ryoung29]

Currently, mygpo uses Django-templates for the frontend. I think we can decouple the frontend and backend by using React and Django REST framework. It would be a much cleaner architecture.

@SiqingYu these are my opinions (not fact). I think separating the front and back end will add additional complexity that may not be suited for the small team currently involved in the project. It complicates deployment, and may limit contribution (you will need front-end devs and back-end devs). Also, the level of effort may be more than we want to deal with.

DRF would be valuable whether we move to split architecture or not. I’d love to hear your opinion about the concerns that I’m raising.

[strugee]

I obviously am not a GPodder core developer, and I'm not trying to tell you how to run your project here (I genuinely mean this, even though I ended up writing a lot 😅). However, I do want to point out that the engineering effort to use something like React is even higher if you want to maintain some nice properties of server-side HTML. The easiest way to deploy a single-page application - which if I'm understanding right, is the proposal here - is to serve a tiny HTML page with basically a single <script> tag that points at your JS. This "works", of course, but in the process you've completely nuked even halfway-decent SEO, the ability of the site to be archived by e.g. the Wayback Machine, and just generally support for anything that doesn't do JS (see js;dr). You've also roughly doubled* the time to your First Contentful Paint (because it now takes two request-response cycles - one for the HTML "boot" page, and one for the JavaScript bundle), and (very) roughly tripled the time to your Largest Contentful Paint (two request-response cycles to get to First Contentful Paint, then at least one more cycle to retrieve the data to populate the frontend models with, possibly more), which is around when the webapp is getting close to becoming interactive and actually usable by the user. Not to mention that you've defeated the browser's ability to do optimizations like the preload scanner. Remember, all of your users, every single one of them, has JavaScript disabled until their browser downloads your JavaScript - including users with poor connectivity or in rural areas that don't have good internet access.

Almost all of these problems are fixable - or at least able to be alleviated (especially for return visitors) with good, aggressive caching policies - but all of the fixes incur significant additional complexity, like trying to render React templates server-side (made even harder since the server isn't in JavaScript), or deploying HTTP/2 and doing server push.

Again, it's totally up to you if y'all want to use React. I don't want to argue with you or be a jerk (though I'm happy to clarify anything I've said or be even more detailed about the performance impact) - I just want to make sure you're aware of the potential downsides of this approach as well as the upsides. I've been a part of the JS community for many years now and a lot of the hyped-up popular frameworks, IMO, are more trouble than they're worth.

*: I'm being slightly disingenuous here by ignoring HTTP Keep-Alive and caching. But the general point stands.