How to create a class in one module(A) that implements an abstract class from another module(B)-CodePudding

I use Microservices architecture with Spring-cloud stack.

For communication between services I decided to use gRPC.

I had an service named Accounting and today I implemented a gRPC-interface project and added it to Git repository.

I added gRPC-interface to the Accounting service using Git-submodules using following commands:

git submodule add -b master <Git-Repo-URL>

git submodule init

Now I want to create a service class in Accounting that implements one class from gRPC-interface but it doesn't recognize any class from gRPC-interface module!!

I think I need to make some changes in setting.gradle and build.gradle files in Accounting module, but I don't know what changes should I do and even don't know what topic to look for on the internet.

Any help or clue would be appreciated!!

CodePudding user response：

It sounds like you're in over your head on microservices here, but, in the interests of answering the question as stated:

Think 'twitter API'. Twitter has 2 'projects' (not in the git submodule sense, in the english word sense). There's twitter-the-website, which is non-public code that runs it all, notably including the code that answers when you connect to api.twitter.com. But there's also an open source (or at least, publicly available) library that you can include in your java projects that lets you talk to the twitter API. This public API includes model classes that match concepts in the twitterverse (such as 'a tweet', 'a user', 'a direct message', 'the concept of one user deciding to follow another', etc), as well as functions (presumably on an 'api' object) that you call with parameters and which returns instances of these model classes.

You need to do the same thing. A microservice consists of two projects: Its API which another microservice includes in itself, which is analogous to the public 'java API' library that twitter offers, and the actual code. Which could be one project or a million, a significant part of the point of microservices is: From the point of view of microservice A that depends on microservice B, you don't need to know anything about B at all except the part that describes its public API. Everything else is an implementation detail that just doesn't matter, as far as service A is concerned.

If you included all the code of a microservice in another, then you end up with every 'microservice' including all code of all others, and there's nothing micro about your services anymore.

Yes, this is annoying. You don't exactly need to duplicate code (the 'public API' part that defines the models can also be a dependency of the microservice itself), but every microservice turns into maintaining 2 separate ones, and you need to find a way for the 'public API' part to be distributable as if it was the twitter API. You probably don't want to put it on maven central, but that's why maven (sonatype, really), gradle, etc all offer the notion of a company-wide intermediate dependency server - that one can host your 'public API' projects. As well as local dependencies - read the docs of your build system on how to deal with non-open-source-publicized (I.e. not on maven central) dependencies.