Refactor main.py

[rviscomi]

The main.py server code has grown in size and complexity and it may make maintenance easier to refactor it into smaller, more discrete files.

Some things that can be grouped:

• Flask subclass
• template functions
• static helper functions
• chapter-specific routes
• error routes
• static file routes
• ebook functions

@bazzadp WDYT?

[tunetheweb]

Yeah could probably do with a bit of clean up alright. Are you suggesting 7 files? Not sure I'd go that far.

One other thing I'd like to do is remove these out of the top level directory into a src/python directory or similar.

[rviscomi]

+1 for a subdirectory to organize the code!

Not suggesting each grouping has its own file.

[ibnesayeed]

Are we only talking about reorganizing the code or something beyond that? I have been considering Responder to replace Flask in some of my projects going forward.

[tunetheweb]

Sky's the limit! So whatever we think is best.

Why's it better than Flask? Not averse to moving, but always like a good reason for moving away something that's working fine.

Also, as per some goals I suggested for this year if we are doing to take the disruption of moving then I'd prefer to consolidate the tech stack and maybe move more to JavaScript with Node and EJS, rather than a sideways move to another Python based server. Unless of course there's a good reason for it!

[ibnesayeed]

Why's it better than Flask?

I am not too excited about unnecessarily switching stack, but I mentioned Responder here because it has an elegant API, has built-in testing support with the popular Requests Python HTTP library (the two projects are steered by the same person), RESTful resource classes, API documentation, and an over-all more modern feel to its design is what feels appealing (look at their README).

[ibnesayeed]

Also, as per some goals I suggested for this year if we are doing to take the disruption of moving then I'd prefer to consolidate the tech stack and maybe move more to JavaScript with Node and EJS, rather than a sideways move to another Python based server. Unless of course there's a good reason for it!

I looked at the stated goals and to be honest I would prefer going to the static site route. A lot can be done using data files and Jekyll to cover some gaps. Writing Ruby plugin for Jekyll can help cover some missing parts. After the inception of GH Actions, we do not have to limit ourselves to the Jekyll plugins whitelisted by GitHub Pages.

[rviscomi]

Are we only talking about reorganizing the code or something beyond that? I have been considering Responder to replace Flask in some of my projects going forward.

For the purposes of this issue, it's narrowly scoped to reorganizing the server code.

I think switching platforms is a more serious discussion that needs to be designed/debated during the off-months to ensure that it's not in the critical path of the launch. Let's not consider it blocking for 2020.

[tunetheweb]

@HTTPArchive/developers anyone with good Python skills fancy tackling this one?

[SaptakS]

I can give it a look over the weekend.

[Super-Fly]

Hey, I created a PR for that, can you take a look and see if it looks ok?
There a couple of things that can be improved but my focus in that PR was just to clean up main.py for now.