4 ms·
Few points based on my experiences with (Micro) services: Note: None of these are cast in stone. These have worked well for us 1. Decide in your team/org what
by sudeepj 7y ago
Few points based on my experiences with (Micro) services:
Note: None of these are cast in stone. These have worked well for us
1. Decide in your team/org what constitutes a new version and what it means. Does every change means version change? What if an API adds an optional parameter; do I need to update the version?
2. Not everything has to be a service. Think if the same functionality can be consumed in the form of a library/sdk instead of a full service.
3. The dependency amongst services should resemble acyclic graph and not cycles. This limits the version change impact.
4. Think about abstraction. Can we logically group set of services A, B & C and provide unified API via pass-through service D? Only D needs to handle API breakage most of the time.