3 ms·

It really depends on the API. For stuff that is likely to change it makes sense to abstract away the API calls. eg either because the API provider likes to brea

It really depends on the API. For stuff that is likely to change it makes sense to abstract away the API calls. eg either because the API provider likes to break stuff or because you need your code to be agnostic towards that particular library eg for portability reasons. But that isn't always a concern and if you're abstracting away an API just for the sake of it then you'll have to question whether you're adding unnecessary complexity and overhead just for the sake of perceived modularity. Like everything in software development, it's about evaluating the right methodologies for the problems rather than hitting every screw with the same hammer.

maxxxxx 8y ago
'Like everything in software development, it's about evaluating the right methodologies for the problems rather than hitting every screw with the same hammer." Very true.
joebergeron 8y ago
Hitting screws with hammers, eh? Ever drive a nail with a drill?
- berti 8y ago
  It's a reasonable way to drill a few holes in wood if you're in a bind.
dgllghr 8y ago
Likeliness to change is certainly a factor, but I think the level to which you are agnostic to the particular technology is more important. If I am choosing the technology to provide functionality that can be provided with pretty much the same semantics by other technologies, then I think it often makes sense to create the abstraction so that they can be swapped out. On the other hand, if I am choosing technology for semantics that are particular to that technology, I don't think creating the extra abstraction makes sense. For instance, caching is functionality that could be backed by redis, memcached, etc. and I think it makes sense to create a cache API in most cases. On the other hand, if I am processing data with Kafka, I want to interface with Kafka directly for all the special functionality and nuance that makes it great for particular use-cases.

maxxxxx 8y ago

'Like everything in software development, it's about evaluating the right methodologies for the problems rather than hitting every screw with the same hammer." Very true.

joebergeron 8y ago

Hitting screws with hammers, eh? Ever drive a nail with a drill?

berti 8y ago
It's a reasonable way to drill a few holes in wood if you're in a bind.

dgllghr 8y ago

Likeliness to change is certainly a factor, but I think the level to which you are agnostic to the particular technology is more important. If I am choosing the technology to provide functionality that can be provided with pretty much the same semantics by other technologies, then I think it often makes sense to create the abstraction so that they can be swapped out. On the other hand, if I am choosing technology for semantics that are particular to that technology, I don't think creating the extra abstraction makes sense. For instance, caching is functionality that could be backed by redis, memcached, etc. and I think it makes sense to create a cache API in most cases. On the other hand, if I am processing data with Kafka, I want to interface with Kafka directly for all the special functionality and nuance that makes it great for particular use-cases.