Investigate moving UI to flask

[ccstan99]

The frontend is currently running on Next serving React which makes API calls to a Flask backend. If it can easily be moved to be served by the Flask backend, it could simplify deployment.

[FraserLee]

Disclaimer: I'm not a web developer, the following could be wrong.

This isn't really possible. NextJS lets us ship a pre-rendered page to the frontend. If we want to drop the next runtime and serve our frontend from flask, it means one of

Swapping to vanilla React

We're not using any next specific features, so it is possible. That said, waiting for first paint and shipping that large a bundle really isn't an acceptable trade-off. Our app would be much worse, unnecessarily.

Rewriting the entire frontend in something else that doesn't need a backend

Could work. I've heard good things about some options here (preact, svelte, etc) - but if we're doing this we need a good reason. A mildly easier deploy probably isn't that.

[FraserLee]

One other thing: it was mentioned in the past that deploying flask and python might be tough. If that turns out to be the case, rewriting the backend into something else would be super easy 🙂

[ccstan99]

We tend to have more Python developers on the team than JS, so there's a strong leaning to keep the Python for long term support. However, if it's a big hassle to move the UI away from NextJS, then we will close this out. This is just a placeholder for discussion, since it was mentioned as something to investigate. Obviously, @FraserLee doesn't want to do it, but if someone ELSE considers this fun, easy, and/or beneficial... 😁

[FraserLee]

Just to clarify: what is the exact issue with deploying NextJS from a droplet? CORS is working, so it can even be a completely unrelated url and everything from the flask stuff.

[FraserLee]

It seems like they have pre-made tutorials for it and everything https://docs.digitalocean.com/developer-center/deploying-a-next.js-application-on-a-digitalocean-droplet/

[ccstan99]

It wasn't a deployment difficulty per se. Maybe more, why use NextJS instead of Vanilla React with Flask? ... which you probably answered above already. I don't personally have an issue with keeping it as is, especially if you feel NextJS adds value. Just wanted to check with others with more web experience who might have any words of wisdom to add.

[FraserLee]

To answer a bit more on the motivations at play here - In the scramble to get something out before April 1st, I went to Next for a few reasons that don't matter anymore

• I had used it before a few times
• It's painless, instant, and free to deploy on Vercel
• (the big one) We initially thought we could use the built-in Next serverless function capabilities, and avoid hosting a separate backend entirely.

This last one ended up not being the case for a few reasons, landing us where we are today with flask.

That said, staying with NextJS is my first choice for the project - and there's a really compelling case to keep it.

1. React seems to be a bit of a lingua-franca among front end developers. In a small focused team I don't doubt we could get more mileage out of a tool more suited to our needs (I'm particular to elm, there's infinite others), but given that we expect open source contributors to come and go it's a pretty good place to be. Next has these exact same benefits from React, since >99% of the lines of source are literally just React code.
2. For a lot of the reasons I went into in other messages in this thread, vanilla React would be untenable where Next is great. Tl;dr it comes down page load sizes, page load times, google-ability, and the time to see and interact with stuff after the page loads.
3. Next does need a runtime on a server. That adds a bit of complexity but if we're doing anything a cent more involved than serving a static HTML page with some JS, Next actually has a really good deploy story. It's supported nearly everywhere, in my experience easy to setup, low overhead, and usually ready to go without writing a line of code.
4. Rewrite would be a nightmare.
5. Maybe a nightmare is overstating it, but the frontend is certainly both the majority of the code in this project, and contains the most complex parts of it.
6. Bonus: There's already an amazing library of React components out there. Not that we need it much for our use case, but it helps. I'm already using this to have a text box that expands to the number of lines written, without having to reimplement that kind of boilerplate myself.

[FraserLee]

Again, I'm not a frontend dev. By day I'm interning on compilers stuff - basically the polar opposite. If anyone who works professionally in frontend has opinions on the matter that would be stellar.

[SimonBiggs]

It might be possible to make nextjs undergo static site generation:

https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation

Then that static site generation could be served by flask (or potentially even simpler, served by GitHub pages)

---

This would mean the server itself would be Python only and just serve the built HTML/JS static files for the front-end.

[ccstan99]

After the last dev meeting, it was decided that this nice to eventually consolidate for easier maintenance but not very pressing. We'll leave it as is since NextJS might provide other useful features and it's currently working well for the project. We can revisit later if needed.

[cvarrichio]

Realize this is now closed, but I wasn't following the commentary until now. I have to ask, as an old school programmer, why a static HTML page with nothing dynamic on it wouldn't just be written in static HTML? My entire index.html is like 15 lines of code, with javascript only used for handling the websockets/SSE stuff. Why do we introduce all this added complexity?

[ccstan99]

Yes, that was part of the concern. Whoever implements the upgrade to the UI will likely have more experience here. Instead of investing the time to "simplify" things now, just to recreate the existing functionality, we'll let the frontend developer use whatever method they deem most appropriate at that time. It's possible they might need NextJS for other features. If not, they can remove it.