4 ms·

Often you wrap a library api with your own to minimize impact of updating library versions to the rest of the codebase or to provide cross version support, not

Often you wrap a library api with your own to minimize impact of updating library versions to the rest of the codebase or to provide cross version support, not just to say swap it for Oracle. At a game studio I was at we shimmed all of the PS3 API. No system Apu was allowed to leak past one layer in our codebase. It helped us move to PS4 quicker. Or to windows (with everything nerfed) between the consoles.

maxxxxx 8y ago
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?
shawn 8y ago
It just takes so long. And sometimes you end up with the minimal api featureset across N platforms.
- grogenaut 8y ago
  Sure.. but we were also only a sony shop, so we had 3 platforms ever, and only 2 were supported at any time (during transitions). So it was more that moving from PS3 -> Windows (while ps4 was only a gfx card) -> PS4 had little impact on the rest of the code base. I'm not saying we were windows / mac / linux / ios / android / ooya / ps4 / ps3 / switch / xbone / 360. I have no experince into that.
Cthulhu_ 8y ago
How would you rate this wrapping? I mean how do you prevent the 'leaky abstraction' where you just wrap a method with your own which has the same signature and struct parameters? Or do you have your own language or domain to wrap e.g. the ps3/4 apis?
- grogenaut 8y ago
  I would say it worked pretty well. We also had some pretty dogmatic rules that were revised once per project and people didn't argue about until the end of a project. This was good and bad. It made the devs who had been there 3+ years super effective with like no mental overhead. It was very difficult on new poeople to learn the system and the company AND fight with a lot of other rules at CR time. The company was biasing for lots of long term happy programmers who were super effective so I understand why they did it. The average tenure was 5+ years on the dev staff. we wrapped it into our engine language. Even though we were a sony only shop we still just talked our stuff. For instance we didn't use any reference to any of the input apis, we just had a global input class g_Input and Input that did all of the input logic. It was pretty easy to make this work for direct input on windows vs the state machine polling system on PS3.
  - lifeisstillgood 8y ago
    My takeaway here is surprise that a game development company biases for long term employees (my understanding was to push for long weeks and early burnouts)
    - grogenaut 8y ago
      It depends on the company for sure and can change over time. I think there are also often 2 tiers of employees at game companies. The ones who are there for the project (their choice or the company choice) and those they feel are the nucleus and treat well. And well if you're at a place like EA the size of the nucleus may be differen due to shifting across projects vs at a single project shop where there are no other projects and loss of the nucleus means the next project fails too.
krylon 8y ago
You know what they say: Every problem can be solved by introducing another layer of indirection. Etc. ;-) But seriously, that sounds like a very good idea if one has to target multiple platforms work with a change-prone API.
- grogenaut 8y ago
  Well think about it, if you're unit testing or functional testing (full stack api based but mocked out downstreams) then you have at least 2 maybe 3 platforms to run against. The real, the mock and maybe the more fancy mock for the functional tests. So say you were talking directly to dynamo api for all of this, it's a lot harder to mock out the dynamo API than it is to mock out a simple 3 method interface.
kornish 8y ago
Gary Bernhardt, as usual, has an excellent screencast about that. https://www.destroyallsoftware.com/screencasts/catalog/wrapping-third-party-apis https://www.destroyallsoftware.com/screencasts/catalog/wrapp...

maxxxxx 8y ago

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?

shawn 8y ago

It just takes so long. And sometimes you end up with the minimal api featureset across N platforms.

grogenaut 8y ago
Sure.. but we were also only a sony shop, so we had 3 platforms ever, and only 2 were supported at any time (during transitions). So it was more that moving from PS3 -> Windows (while ps4 was only a gfx card) -> PS4 had little impact on the rest of the code base. I'm not saying we were windows / mac / linux / ios / android / ooya / ps4 / ps3 / switch / xbone / 360. I have no experince into that.

Cthulhu_ 8y ago

How would you rate this wrapping? I mean how do you prevent the 'leaky abstraction' where you just wrap a method with your own which has the same signature and struct parameters? Or do you have your own language or domain to wrap e.g. the ps3/4 apis?

grogenaut 8y ago
I would say it worked pretty well. We also had some pretty dogmatic rules that were revised once per project and people didn't argue about until the end of a project. This was good and bad. It made the devs who had been there 3+ years super effective with like no mental overhead. It was very difficult on new poeople to learn the system and the company AND fight with a lot of other rules at CR time. The company was biasing for lots of long term happy programmers who were super effective so I understand why they did it. The average tenure was 5+ years on the dev staff. we wrapped it into our engine language. Even though we were a sony only shop we still just talked our stuff. For instance we didn't use any reference to any of the input apis, we just had a global input class g_Input and Input that did all of the input logic. It was pretty easy to make this work for direct input on windows vs the state machine polling system on PS3.
- lifeisstillgood 8y ago
  My takeaway here is surprise that a game development company biases for long term employees (my understanding was to push for long weeks and early burnouts)
  - grogenaut 8y ago
    It depends on the company for sure and can change over time. I think there are also often 2 tiers of employees at game companies. The ones who are there for the project (their choice or the company choice) and those they feel are the nucleus and treat well. And well if you're at a place like EA the size of the nucleus may be differen due to shifting across projects vs at a single project shop where there are no other projects and loss of the nucleus means the next project fails too.

krylon 8y ago

You know what they say: Every problem can be solved by introducing another layer of indirection. Etc. ;-) But seriously, that sounds like a very good idea if one has to target multiple platforms work with a change-prone API.

grogenaut 8y ago
Well think about it, if you're unit testing or functional testing (full stack api based but mocked out downstreams) then you have at least 2 maybe 3 platforms to run against. The real, the mock and maybe the more fancy mock for the functional tests. So say you were talking directly to dynamo api for all of this, it's a lot harder to mock out the dynamo API than it is to mock out a simple 3 method interface.

kornish 8y ago

Gary Bernhardt, as usual, has an excellent screencast about that. https://www.destroyallsoftware.com/screencasts/catalog/wrapping-third-party-apis https://www.destroyallsoftware.com/screencasts/catalog/wrapp...