[PB-4201]: feat/health check server setup

[jzunigax2]

Adds a Fastify-based health check server in health-check-server/ to monitor Internxt API endpoints for Uptime Robot.

• Uses SDK methods for real API checks
• Environment-based configuration (API URL, credentials, etc.)
• Returns 200 on success, 503 on failure
• Not included in SDK package build

[larryrider]

Hey, shouldn't be better to create this "server" in another git project?
It has its own package.json, .env, .gitignore, config, methods, etc.
It is not included in the build so its not really related to this project.

What are the advantages of having it inside this project instead of outside by its own?

[jzunigax2]

Hey, shouldn't be better to create this "server" in another git project? It has its own package.json, .env, .gitignore, config, methods, etc. It is not included in the build so its not really related to this project.

What are the advantages of having it inside this project instead of outside by its own?
Hey Larry, yes you raise a valid concern. The reason this lives inside sdk is to allow us to use sdk methods directly, but the main reason is that this living inside sdk forces us to keep the health check always up to date.

If we put it in a separate project, we risk the monitoring tests getting out of date and creating extra work to manage dependencies between two different repositories. Keeping them together ensures the test always matches the code.

[apsantiso]

@sg-gs This is just a kickoff, looks good to me. WDYT?

[sg-gs]

The idea is to keep the SDK in sync with the EPs health checks that we use as monitors @larryrider, so each time you add an EP, a monitor is automatically created / updated

[sg-gs]

I have some questions:

• How are we adding an EP for each SDK method? This should be as automatic as possible and it is, in fact, the important point here. I see some imports of '/drive/routes' but that should not be the case nor the idea of this initiative is. Only complex cases could be added manually by overriding
• Why Fastify? Only one project is using this technology right now. Nest.js has been our way-to-go these last 3 years.

[jzunigax2]

I have some questions:

* How are we adding an EP for each SDK method? This should be as automatic as possible and it is, in fact, the important point here. I see some imports of '/drive/routes' but that should not be the case nor the idea of this initiative is. Only complex cases could be added manually by overriding

* Why Fastify? Only one project is using this technology right now. Nest.js has been our way-to-go these last 3 years.

hey @sg-gs:

• Maybe I misunderstood the scope of the task, just spoke with Andres and now I have a better understanding. Let me get back to you on this point once I come up with a sort of strategy
• As for why fastify, this use case seems simple enough where nest js seems to be a bit of an overkill plus it entails a lot of biolerplate. I considered using express directly but opted for fastify as it's simpler, more lightweight and not entirely unfamiliar to us. But if you disagree I don't see why we could not switch over to nest js, like I said it just feels like overkill

[sg-gs]

it just feels like overkill

Yeah, in theory it is. Let's see first if you can make it work without it (as automatic as possible, I assume Swagger could help here), but still, Fastify was a test but this health-check thing is not for scaling it, it will receive like 100 requests/minute. I would go the Express route, as it is the other option we use. WDYT @apsantiso ?