9

I always had this mentality that I shouldn’t rely on a certain library or framework for my entire project because what if one day they stop supporting it. (Yeah I’m talking to u vuetify) That’s why I came up with this code structure that for everything that I wanna do I have a ‘driver’ library all coded by myself that interacts with that third party framework or library so if they stop supporting it I could just change a couple of lines of code in my driver file and my codebase should be working again. But I feel like this ‘driver’ approach is not the most efficient way of going in terms of memory usage. Do you guys think I should keep it simple and directly use those libraries or this is actually not a bad approach.

Comments
  • 0
    What if _you_ stop supporting the driver? Then the single point of failure is there instead of on the framework 😛
  • 2
    @alexbrooklyn but then it’s on me being a lazy fat fuck not them. I have trust issues with humans lol
  • 1
    I'd say et t depends on the library/framework. For example, one version of most js framework run for 2-3 years.
    In three years you would still run the same GUI??
  • 1
    Urgh. I did that myself up to a few years ago and it's SOOO BAD, especially in Java. So don't do that, Kids. Ever
  • 1
    I do this most of the time, too. But I keep the adapters inside the project I need them in. It's not much work and it helps me to decide when I need to mock something as these adapters clearly tell me where the "outside" begins. It's easier to "don't mock your friends" that way I think.
    Another bonus is that I only use what I really need inside my project as I have to write the wrapping method first. This at the same time makes it easier for me to see what features I really need library x for.

    So far it really saved me a lot of trouble as I had to switch to other libraries for the same features more often than I expected.
  • 0
    Currently in the colab project that I'm working on with @ishank-dev and @M1sf3t we ensure that we don't use inheritance with framework classes and inject any dependencies we need with interface typehints, this also goes for our controllers.

    Also our ORM/routing/serialization/validation is separated from our source code to increase loose coupling and make it easy to migrate between libraries.

    Ofcourse it's not 100% loosely coupled, but maintaining my own adapters/libraries on top of the project itself seems like an absolute hell to maintain
  • 0
    the way you're describing it sounds like no.

    the idea you describe is sensible and necessary to some extent.
    and that valid extent is wrapping external library code.
    but you shouldn't wrap a framework like vue. definitely no. nope nope nope. no senior.

    (fuck, just noticed this post is a month old)
Add Comment