Osmose

I make websites and chiptunes!

  • he/him

AKAs:
Lapsed Neurotypical
JavaScript's Strongest Warrior
Fake Podcast Host
Thotleader
Vertically Integrated Boyfriend
Your Fave's Mutual
Certified 5x Severals by the RIAA
Inconsistently Medicated
The Source That Views Back
Carnally Known
The Alternative


Homepage
osmose.ceo/

I've seen it happen enough times that I'm about 90% confident that any company scaling to like 1 million users or more will probably want to build abstraction layers over the major standard components of their app, e.g. primary data storage, caching, phone messaging, sending emails, etc. And, depending on your stack, these layers may themselves follow a pattern like being implemented as microservices or injectable dependencies or whatever.

To restate this in concrete terms: Instead of making calls to the Twilio python lib for sending SMSes to users, you're gonna wanna call MyCompanyPhoneLib.sendSMS or something instead.

The reason is that, at some point, you almost certainly will be doing one of the following:

  • Moving to a different external provider with better pricing
  • Modifying the internal representation of some data for performance reasons
  • Switching from a single storage service to a distributed store
  • Adding standard analytics to any call between separate components
  • Adding some kind of permissions system that prevents certain calls being made between services
  • Mocking out a service or component during testing, or providing an alternative during local development

And all of these will be made much easier when the only thing you need to change is the abstraction implementation. Sure, sometimes the abstraction API itself needs changing to support things it didn't consider at first, but that's hardly something you get to avoid by not using one. You still do that work either way.

At times I've thought this was standard wisdom, but I've seen shops where any kind of abstraction is treated as unnecessary complexity–the kind of places that think the main difference between Django and Flask is that Flask uses less code and thus is simpler. I think there's a little value in reinforcing the support for abstractions as a very useful tool that can be taken too far.


You must log in to comment.

in reply to @Osmose's post: