-2

I'm trying implement in JavaScript/Node.js a data upload functionality. I want to be able to switch between different storage providers, e.g. AWS, GCP, Azure, with no code change, for instance, via config-file and at the same time to avoid chains of if-else/switch-case to be able to choose an optimal API/service provider in the code.

I, personally, considered to go with one of the following:

  • Façade;
  • Adapter;
  • Decorator;
  • Dependency Injection.

The questions:

  • Which design patterns (not necessary from a proposed list) should I focus on?
  • Pros and cons of the proposed patterns?
  • 3
    Whatever you want to call it, you need a common API that you can plug in "adapters" to translate between your API calls and each Service Provider. – Robert Harvey Apr 21 at 22:44
  • @RobertHarvey, you're right I just want to avoid an invention of a bicycle scenario and stick to the well-known DP. – Mike B. Apr 21 at 22:49
  • 2
    Does this answer your question? Choosing the right Design Pattern ... Anyway, there's no magic formula here; just design the interface, write the translation classes, and use your favorite technique for wiring up the dependencies. – Robert Harvey Apr 21 at 23:21
  • @RobertHarvey, thanks for the proposed thread, but it's too general. – Mike B. Apr 22 at 6:17
1

The well know design pattern is called: an API.

It provides a delineation between two sections of code, and describes how those two sections can interact and the reasonable expectations that both sides can have of the other.

This pattern though is very generic.

What you are looking for is a specific kind of API called a Plugin.

The purpose of a plugin is to provide an API for a set of actions, the implementation of those actions provided by code that may as yet not be written, but as it conforms to the API, and discoverability mechanisms can be loaded and plugged in.

The Plugin itself once discovered is probably provided via Dependency Injection to the code in need of its services.

The plugin itself is may be an Adaptor as the API the plugin must provide is probably not the API of the service it is attempting to plugin.

Alternately the plugin may be a Facade hiding a much larger and more capable implementation that has been organised to allow it to be plugged in.

It might be both a facade and an adaptor.

It is also probably that their are several plugin decorators providing additional behaviour or behaviour overrides, such as extra logging, security checking, and fixups for broken third-party implementations.


Perhaps its a nitpick, but you should consider Configuration to be code.

It is code, because it isn't plain data.

Plain data does not change the behaviour of the system. It is simply transported and transformed by the code, it does not change the code paths the code chooses.

On the other hand that configuration file is choosing the backend. Changing the config changes the backend, a change in behaviour, therefor it is code.

| improve this answer | |

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.