[ChrisLovering]

What does this PR do? Makes everything better of course!

Changes

• Switch to Poetry & Python 3.9.5
  • There isn't a tiangolo 3.9.5 image, so we've made our own, based on the same script.
• Split the different types of endpoints into their own files
  • This moves us away from having almost everything in pixels.py
• Changed our manual auth implementation to use FastAPI's dependency injection pattern
  • This also meant I could remove the manual OpenAPI spec modifications we were doing to make the auth work in the docs
• Use more of a RESTful style of endpoints, rather than having separate endpoints for get and post.
• Moved all rate limit and cooldown config into constants.py

[vcokltfre]

👁️ unstable but unstabler?

[ChrisLovering]

Pls don't merge this...yet.

I need to summarise and change some readmes. This was just for the diff

[jb3]

for your own protection.

[ChrisLovering]

for your own protection.

Lol tyty

[ChrisLovering]

This is ready for review, it shouldn't be merged until after the current event, due to some breaking changes.

[ChrisLovering]

I am not sure how thoroughly this has been discussed, and how much of a say I have in this. But I have some opinions on the new endpoints, you currently have:

• GET /size: Get the size of the canvas
• GET /pixels: Get the whole canvas
• GET /pixel: Get a specific pixel
• PUT /pixel: Set a specific pixel

One quick thing I want to mention about /pixels, it doesn't really make sense, we're already at pixels.pythondiscord.com. Making the URL pixels.pythondiscord.com/pixels..

In my opinion, the following seem more RESTful:

• GET /canvas/size: Get the size of the canvas alternatively this info could be included in the headers and would be mainly requested using HEAD /canvas.
• GET /canvas: Get the whole canvas
  alternatively the following two endpoints could use /canvas/pixels
• GET /canvas?x=x&y=y: Get a specific pixel
• PUT /canvas: Set a specific pixel you could also use query parameters here and the body would only consist of the color

I actually really like that style of API, ready for the next time we run this event.

For now I believe I have covered all of your comments, once again, thanks for taking the time to ready through the PR :)

I will raise an issue with your suggestion for the re-work of the endpoints, rather than add more to this PR.

[Bluenix2]

Did using multiline strings cause issues?

[Bluenix2]

Pretty much only comment and doc-string improvements at this point