Implement a strictly typed service client for comms between services

[rikukissa]

This is not used anywhere yet, but the more we start using it the better. This will effectively provide a much nicer dev experience, less room for human errors and better type safety for refactoring.

Features

Autocomplete for request paths

Compiler errors if you are submitting an invalid or missing body

Typed path parameters

Typed return values

Changed the factory call signature a bit
Service URL now has to be passed from outside

What's missing

• Typed query parameters
• Quite a lot of Joi definitions from many of our endpoints 😄

[naftis]

comment what this does

[rikukissa]

@naftis @Zangetsu101 I've also started thinking if writing our internal APIs in https://trpc.io/ would actually be better in the grand scheme of things. Thoughts? It would take us a step further from "easily approachable tech" but would yield other benefits for our team

[Zangetsu101]

@naftis @Zangetsu101 I've also started thinking if writing our internal APIs in https://trpc.io/ would actually be better in the grand scheme of things. Thoughts? It would take us a step further from "easily approachable tech" but would yield other benefits for our team

tRPC is ideal for communicating between frontend and backend so kinda at the place where our GraphQL layer sits. Of course it has this requirement that both of them must be using typescript (which we already do). But not sure if anyone's using it for backend services tho. TBH this PR did look to me like a tRPC implementation but for backend microservices 😄

[naftis]

Idea: the country-config routes could be typed like this as well. Then we could go as far as create a Swagger / OpenAPI docs of what routes the country-config should implement.

[rikukissa]

I'm closing this for now. I think tRPC is a better option