🔨 Refactor apiRouter into smaller files

[danyx23]

apiRouter.ts has become quite large and when you work with LLMs, large files are pretty annoying. This PR splits the route implementations into new files by topic.

The individual commits make it easier to follow along what happens and should hopefully also make review easier.

[owidbot]

Quick links (staging server):

Site Dev	Site Preview	Admin	Wizard	Docs

Login: ssh owid@staging-site-refactor-api-router

• Site-screenshots: https://github.com/owid/site-screenshots/compare/refactor-api-router
• SVG tester: https://github.com/owid/owid-grapher-svgs/compare/refactor-api-router

SVG tester:

Number of differences (default views): 0 ✅
Number of differences (all views): 0 ✅

Edited: 2025-01-09 20:42:33 UTC
Execution time: 1.28 seconds

[rakyi]

LGTM! And I have additional suggestions.

This might be subjective, but since we are already doing the refactoring: I feel like we have too many layers of abstraction and I suggest we get rid of FunctionalRouter.

I think the error handling it does is wrong — we should use an error handling middleware if we want to do anything custom (which should probably just be a Sentry integration).

And we can configure the same middleware that we do in the constructor either at the top app level, or per each nested router.

[rakyi]

Not specific to this route, just noticed it here. Why are we using Request from our authentication module, which is just — IMO — an unnecessary alias for express.Request and Response from Express, when we have our own Response in the same authentication module with additional properties? If anything it should be the other way around, right?

My preference would be to use Request and Response only from Express, if possible.

[danyx23]

@rakyi good points! I'll give it a stab to clean this up as well.

[github-actions]

This PR has had no activity within the last two weeks. It is considered stale and will be closed in 3 days if no further activity is detected.