3 ms·

Definitely seen a lot of developers who, every time they want to go use a library- metrics, logging, http-clients, they go build their own TypeScript wrapper an

Definitely seen a lot of developers who, every time they want to go use a library- metrics, logging, http-clients, they go build their own TypeScript wrapper and interfaces. They think they're doing us all a huge favor by giving us something that might be portable, and which has an interface which is this way or that way easier or better. But it becomes a sticky not quite-sensible mess pretty quick, and ultimately, and no one can StackOverflow or nom search their way to success, since the internet has nothing to say about our homegrown overgrown wrapper + helpers. I really want to find ways to better capture "we use X for logging along Y and Z plugins and U and V configurations". Making top down tools, that hide whats afoot, is just plain bad, but copy pasting the same solution dozens of times also doesnt fly. Anyhow that all said, my problem here is more about encapsulation masking whats really happening, which I think is treacherous. I dont necessarily agree with the author; etcd for example I think has huge epic wins the author just doesnt get & that databases have simply never caught up on (common Http-centric interfaces, watch-api). But I did do many years of java and the Service Provider Interfaces (SPIs) everywhere were a cherishable & adorable source of great power & flexibility. That point is retained. I just think favoring sql is a terrible terrible example that ignores how excellent & typical http based interfaces are.

shepherdjerred 4y ago
Sometimes it makes sense to write a wrapper. I've worked on a team where every few months we'd have some mandated framework change, or a microservice we depended on was being replaced by some new project. In that case it's easier to update an abstraction in some common library than ripping the code out from every place it's used in application code.
- andrewstuart2 4y ago
  I love the rule of three. I know I've heard it on the Go Time podcast, but I'd heard it before then. Copy your code once. If you find you've copied it again later, that's the right time to think about whether you'll continue to, and therefore whether it's worth making something reusable. So yeah, wrappers are nice. But I'm also a really big fan of lazy wrappers. Wrap the thing barely enough to get the job done so you can upgrade in one place, but don't get fancy because you will probably hate yourself for it down the road.
  - tcfhgj 4y ago
    I hate that rule. It makes almost entirely sure that you'll loose control for your duplicates. The way around is way easier

shepherdjerred 4y ago

Sometimes it makes sense to write a wrapper. I've worked on a team where every few months we'd have some mandated framework change, or a microservice we depended on was being replaced by some new project. In that case it's easier to update an abstraction in some common library than ripping the code out from every place it's used in application code.

andrewstuart2 4y ago
I love the rule of three. I know I've heard it on the Go Time podcast, but I'd heard it before then. Copy your code once. If you find you've copied it again later, that's the right time to think about whether you'll continue to, and therefore whether it's worth making something reusable. So yeah, wrappers are nice. But I'm also a really big fan of lazy wrappers. Wrap the thing barely enough to get the job done so you can upgrade in one place, but don't get fancy because you will probably hate yourself for it down the road.
- tcfhgj 4y ago
  I hate that rule. It makes almost entirely sure that you'll loose control for your duplicates. The way around is way easier