Microservices with External Integration

Question

I am creating a microservice based application which has to interact with Github through its API. Some of the microservices are Projects, Tasks, etc.

My question is: should I have a microservice dedicated only to communication with github? so when I need to create a project in the project microservices, I register it in my database and send an event to the github microservice to create the project in github (same for task microservices, send an event to the microservice of github to create the task).

Or should I do the communication with github in each microservice, registering the project (or task) in my database and registering it in github?

Answer 1

Short answer: hide the github-service behind a service interface so that using github-mircorservice or linking against a github-library is a implementation detail that can be decided later.

Using and maintaining a library is less expensive than having a seperate microservice. You need more reasons than "reusability" to justify the extra costs.

Long answer:

(I assume that you are using a compiled programming language like java or c#)

To avoid analysis+paralysis I would not decide upfront if this should become a mircoservice or not.

Instead i would implement in cyles and decide later how to proceed:

• (1) Start implementing the code directly in a pilot consumer application.
• (2) when the pilot is done and you still have more than 3 usecases that need the same functionality refactor the github specific code of the pilot into one or more service classes so that the pilot only comunacates with the service
• (3) move the service classes into a seperate library that has no dependencies to the pilot. Hide the service functionality behind an interface. The pilot will only use the library through the interface. (This pattern this is called onion-architecture )
• (4) implemented two other usecases and link them against the extracted libraries.
• (5) Find more usecases where you need the github feature. if you find real benefits of having a github-processing-microservice over linking against your library then create a microservice that does nothing more than wrapping your library-interface to the library. Since the consumers only use the service-interface this transition should be easy.

Answer 2

Both, Neither

Both are reasonable at twenty thousand feet.

First Question

Can Github support multiple concurrent connections?

If it can there isn't any technical reason why each of your micro-services has to deal with a middle man.

If it can't then there needs to be some kind of mediation. Its still possible for each micro-service to connect directly, they may have to obtain a lock first though, which leads to its own issues.

Second Question

Do you want to maintain operation despite GitHub being unreachable?

If you do, then a middleman is probably the right approach. It allows you to cache, and even customise your own internal requirements, even if GitHub is down, or suddenly changes its API.

If you don't then a middleman might still be useful for logging and auditing purposes.

---

So what are your requirements?