4 ms·

I like to do that too. Having a thin layer over the actual API makes maintenance much easier and you can test your layer better. But it's hard to implement this

I like to do that too. Having a thin layer over the actual API makes maintenance much easier and you can test your layer better. But it's hard to implement this in a bigger team. A lot of people don't see the point.

laumars 8y ago
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.
segmondy 8y ago
why would it be hard to implement this in a bigger team? if it's hard, then it's leadership failure.
- maxxxxx 8y ago
  It's easy to implement if you are the dictator who can just tell people that that's the way how things are done. Or you have worked with people for years and learned your lessons. If you have to convince people it's much harder. I find that a lot of people these days avoid writing code and just want to plug components from GitHub or npm together. They don't see the point of writing an API layer if it's not coming from GitHub.
  - mk89 8y ago
    I somehow understand your comment. Logically you are right. Having the first and last word is always the easiest way. I mean, the easiest way to get what you want for a limited amount of time, until all hell breaks loose. I hear a lot of frustration in your words, as if you had difficulties trying to explain to your colleagues why a certain thing could be done better in a certain way. I think that sometimes they might be right, sometimes reinventing the wheel is pointless, sometimes it needs to be invented, and sometimes you need to add that layer of complexity. It seems that information is not shared correctly at your workplace, as not everyone is probably aware of the same problem to solve, or maybe not everyone has the same skills, in which case you need to mentor and explain. Or it seems that you don't have constructive design discussions. And no, this does not depend on the company/team size. Probably in larger teams it's actually easier to convince, as generally there is a process in place for such things like design, refactoring, etc.
    - zdragnar 8y ago
      It's not unique. I've worked in large teams with benevolent dictators (who were open to feedback and suggestion), and large teams where everyone wanted to be at the same level. In the latter scenario, generating momentum is damned difficult, as everyone is trying to herd cats to their own priorities. Smaller teams in that regard can be more flexible / nimble, as there are fewer total competing priorities, but that isn't to say that it is always true in either direction.
grogenaut 8y ago
I do it on my current server stuff as well. Generally I don't talk to dynamo directly, I make a pretty simple wrapper that speaks the language of the project. This helps with mocking and with isolating the business logic from shifts in schema. Also makes it easier to use test dynamo db.
- maxxxxx 8y ago
  I would recommend this approach to any project that deals with databases. Having SQL or other query languages spread around the codebase makes it extremely hard to refactor or test and can also cause security issues. I always write simple functions like "CustomerFunctions.GetCustomersByCountry" and keep all SQL in that file. Makes the code more readable and testable.
fit2rule 8y ago
Is the point: thin layers defeat NSA?

laumars 8y ago

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.

segmondy 8y ago

why would it be hard to implement this in a bigger team? if it's hard, then it's leadership failure.

maxxxxx 8y ago
It's easy to implement if you are the dictator who can just tell people that that's the way how things are done. Or you have worked with people for years and learned your lessons. If you have to convince people it's much harder. I find that a lot of people these days avoid writing code and just want to plug components from GitHub or npm together. They don't see the point of writing an API layer if it's not coming from GitHub.
- mk89 8y ago
  I somehow understand your comment. Logically you are right. Having the first and last word is always the easiest way. I mean, the easiest way to get what you want for a limited amount of time, until all hell breaks loose. I hear a lot of frustration in your words, as if you had difficulties trying to explain to your colleagues why a certain thing could be done better in a certain way. I think that sometimes they might be right, sometimes reinventing the wheel is pointless, sometimes it needs to be invented, and sometimes you need to add that layer of complexity. It seems that information is not shared correctly at your workplace, as not everyone is probably aware of the same problem to solve, or maybe not everyone has the same skills, in which case you need to mentor and explain. Or it seems that you don't have constructive design discussions. And no, this does not depend on the company/team size. Probably in larger teams it's actually easier to convince, as generally there is a process in place for such things like design, refactoring, etc.
  - zdragnar 8y ago
    It's not unique. I've worked in large teams with benevolent dictators (who were open to feedback and suggestion), and large teams where everyone wanted to be at the same level. In the latter scenario, generating momentum is damned difficult, as everyone is trying to herd cats to their own priorities. Smaller teams in that regard can be more flexible / nimble, as there are fewer total competing priorities, but that isn't to say that it is always true in either direction.

grogenaut 8y ago

I do it on my current server stuff as well. Generally I don't talk to dynamo directly, I make a pretty simple wrapper that speaks the language of the project. This helps with mocking and with isolating the business logic from shifts in schema. Also makes it easier to use test dynamo db.

maxxxxx 8y ago
I would recommend this approach to any project that deals with databases. Having SQL or other query languages spread around the codebase makes it extremely hard to refactor or test and can also cause security issues. I always write simple functions like "CustomerFunctions.GetCustomersByCountry" and keep all SQL in that file. Makes the code more readable and testable.

fit2rule 8y ago

Is the point: thin layers defeat NSA?