Communication between Service Fabric Applications -


we have grouped different functionalities in different service fabric applications. each service fabric application responsible set of functionalities within scope(e.g. news, blogging, user separate applications). different teams can work on functionality scopes.

each application has public rest api, /users or /news or /blogs. public website can call these endpoints , retrieve/post information.

however, many times these applications need communicate each other. best way set up? there 2 ways go far can see now:

  • create new http endpoint on each application use internally(using own ip port not published publicly). loosely coupled.
  • use rpc calls (but create 'hard' link between applications). coupled.

for think separate http endpoint way go, wonder if rpc calls better? it, design philosophy, allowed use rpc calls between applications? or bring me trouble when application updated , interface has changed?

or there pattern use here?

for sure, have rewrite when change signature of services or add new. so, in both cases have touch code changed , calling code.

the problem rpc need have interface accessible in place use service. can't independently upgrade services. http communication solve issue.

but http communication need write pretty complicated code, lead to:

  • places new bugs
  • difficulties understanding logic , architecture new people
  • probably need tesst , have maintain them
  • you need think how enroll updates — service should updated first

yes, becoming free dependencies(not me), amount of work , maintenance rises little well. , rpc cheap , simple.

i use http on rpc in case upgrading service separately critical , upgrade of service should not stop or affect work of other.


Comments

Popular posts from this blog

Spring Boot + JPA + Hibernate: Unable to locate persister -

go - Golang: panic: runtime error: invalid memory address or nil pointer dereference using bufio.Scanner -

c - double free or corruption (fasttop) -