Imagine you're in a Python setup, with all of the projects you're working on. Now, as a base line, you have a Python module that is the backbone (backbone.py) to everything when it comes to getting data from a datasource. There is also a FastAPI implementation of this this backbone (backbone-api.py), offering a handy way of getting the data out.

Now, there is another project emerging, which needs to use the data of the backbone. Also implemented with python and FastAPI (different-angle.py). Pretty much just a different angle of the data.

There appear to be two options:

Option A: Importing the backbone module directly into the new project, to allow direct access to the data and best performance.

Option B: Using the FastAPI implementation of the backbone, to simplify the process, but at the cost of latency.

To my mind, Option A seems to be slightly better. This is mostly as this will increase performance and leverages Python modules better. Option B has the advantage of being an easy setup, as you don't need to install the backbone module and its configuration. This is probably also fine for smaller operations, but Option B would probably have some disadvantages when it comes to returning larger amounts of data.

enter image description here


A few things to consider whether to directly import the backbone or use the API layer.

  1. How many components are dependent on backbone.py? How will the change in the backbone affect your component?
  2. If you can directly access to backbone.py, what is the need for backbone-api.py? If this is acting as a layer of abstraction to decouple different-angle from the backbone, then it may be required or you can get rid of it.
  3. Is backbone.py a layer you have control over or is it a third party.
  4. What is your acceptable level of performance. Agreed the performance may not be that great with API layer, but does that break your SLO in any way?

If the API layer performance is so bad that you cannot go through it, then there is no need to read further, you go ahead by importing directly (I would still recommend to try and solve for performance issue).

I would recommend having a uniform way of accessing/importing modules. If backbone.py is an external module, it is better to decouple the dependency from your module and hence use the API. If it is a third-party module you should definitely consider using the API layer and stick to the contracts rather than doing a direct import.

If you are the sole owner of the backbone module, not a lot of other places where this module is imported, and performance is your priority - then you go ahead with direct import and have your decision documented.

| improve this answer | |
  • In this scenario we would have 2 components depending on it already, plus a few other ones. A change in backbone.py may has some side effects, but this is always up to how you implement it on the receiving end I'd assume. – tschaka1904 Oct 20 at 10:26
  • 1
    There is full control on the backbone.py, despite some imported libraries. I'd assume that using the backbone-api.py would hide those dependencies. That would be one advantage of option B, I guess. – tschaka1904 Oct 20 at 10:32
  • 1
    hmm..but I think no matter how well you implement at receiving it, the moment you create a direct coupling, you are at the mercy of changes in backbone directly. This will make development very hard. Besides breaching encapsulation as well. Testing will get difficult too. It's a lot easier to maintain versions at API layer rather than changing versions of module directly. – skott Oct 20 at 10:46
  • 1
    That definitely would, but the question is why not the API when it exists already? if it's performance and you can't compromise on it, then it is understandable, but otherwise, I would still recommend the API. Better to deal with interfaces especially if it is already there. – skott Oct 20 at 11:34
  • 1
    Sure, makes sense. I guess, assessing the need for the performance is the way forward. Will be interesting to compare both options on larger scale. – tschaka1904 Oct 20 at 11:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.