Rewrite website asynchronous networking to be efficient
I was looking at the api used by the site internally and I discovered something horrifying: html code for asynchronous parts of the page are being constructed on the server side and then sent to the client!
This is a terrible idea. It would be much better if your internal api simply sent a json object to the client, exclusively containing data about the comics, comic list etc... and then have the client construct the dynamic page parts, rather than having the server construct the asynchronous page parts. The benefits of doing it this way would be as follows: reduced network load for client AND server as api response will be MUCH smaller, faster load times, lesser server load, easier maintainability because constructing the page and serving the data are entirely separated, an api usable by others. Also, for something as simple as sorting a list, the server should not be involved AT ALL (I was horrified when I found "order=alpha-asc" in a request).
An 8-year old website that predates SPAs with HyperText Transfer Protocol returning HyperText? Whoa.
-
Hexellate commented
I should start by saying that I probably shouldn't have worded my statements so strongly. That aside, even if the website is 8 years old, this is still an area that it could be improved in future. I didn't mention it, but I was actually referring to the asynchronous request to "https://leagueofcomicgeeks.com/comic/get_comics". While I understand that this webpage is 8 years old (and is clearly not an SPA), I feel that it is a bit redundant to return a json object containing mostly html code (and also bloats the response). I also understand that this is not a simple thing to change, but honestly I think that the benefits (which include better response times, better UX and lower resource strain due to less network traffic and requests to the server) outweigh the time and effort required to improve this. Perhaps it would be more agreeable to develop a new api (for internal site use) that returns json data (without preformed html) alongside the existing system, and then to slowly switch over to the new api? Maybe I'm pushing this too much, but I just feel that having to wait up to 38s (with my terrible internet) to download a response of size 4.9MB for something as simple as changing the sort order of a list is a little excessive.
-
Hexellate commented
Should also mention that I would be more than happy to help fix this issue, as I use this site regularly and always like seeing improvements (also I have skills in programming so there's that too).