Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🔨 Refactor apiRouter into smaller files #4350

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

danyx23
Copy link
Contributor

@danyx23 danyx23 commented Dec 20, 2024

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.

@danyx23 danyx23 force-pushed the refactor-api-router branch from c830ca6 to dbe1aa1 Compare December 20, 2024 15:28
@owidbot
Copy link
Contributor

owidbot commented Dec 20, 2024

Quick links (staging server):

Site Dev Site Preview Admin Wizard Docs

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

SVG tester:

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

Edited: 2024-12-20 15:43:57 UTC
Execution time: 1.23 seconds

@rakyi rakyi self-requested a review December 23, 2024 09:35
Copy link
Contributor

@rakyi rakyi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +121 to +122
req: Request,
res: e.Response<any, Record<string, any>>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

danyx23 commented Dec 23, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants