4 ms·
This is good advice, but the benefits and advantages are not entirely explained. The approach is that client's should declare their own interfaces and librarie
by gitgud 7y ago
This is good advice, but the benefits and advantages are not entirely explained.
The approach is that client's should declare their own interfaces and libraries/backend's should implement those interfaces.
- So instead of:
app > depends on > api
- It's
api > depends on > app interface
&
app > depends on > app interface
Basically another version of [1] "The Dependency Inversion Principle", which allows you to break hard dependencies into lightweight interfaces.
[1] https://en.wikipedia.org/wiki/Dependency_inversion_principle https://en.wikipedia.org/wiki/Dependency_inversion_principle
- taberiand 7y agoI extend this to explicitly have an adaptor in the middle: app > depends on > app interface service > implements > api adaptor > composes (api >> app interface) That way the app doesn't need to know about the API, nor the API about the app. The wiring up the two are managed by the adaptor which is free to be implemented on the client/app side or vendor/service side.