Custom backend feature

[2tunnels]

As I understand right now, this package supports only 3 MJML backends: cmd, tcpserver, and httpserver. Also, there is no way to extend this list because all variants are hardcoded.

https://github.com/liminspace/django-mjml/blob/master/mjml/tools.py#L156

I think it would be very nice to have a custom option to pass any path to some callable. This way, anyone can build their backend if needed.

For example:

# settings.py
MJML_BACKEND_MODE = 'myproject.mjml.backends.custom_renderer'

# myproject.mjml.backends.py
def custom_renderer(mjml):
    return requests.get('http://mjml-server.cluster.local', json={'mjml': mjml}).json()['html']

Now rendering part can be easily delegated anywhere we want.

I can create pull request, but I think I will need some help with testing 😄

[liminspace]

@2tunnels hi! it sounds ok, but your custom_renderer is already implemented as httpserver mode :) It can be a minor feature in the future, but I don't see any reason to implement it right now. People usually uses one of the three modes and if they use something custom, the just implement their server for httpserver mode. I want to keep the library as simple and small as possible.

[2tunnels]

Yes, but HTTP server implementation is hardcoded. Let's say I want to use protobuf instead of JSON, or my request body looks a little different. Or I want to do custom authentication with another header. This feature will not break anything because it's just an additional check (after cmd, tcpserver and httpserver), and the only thing we need to check if this new string is importable and callable.

[liminspace]

I think it will be better to implement class-based backend pattern. I'll think about it.

[2tunnels]

Sounds good! But will callable approach you can use both functions and classes (classes that implement __call__ method). It's your decision, just saying that function is the simplest API abstraction you can have :innocent:

[liminspace]

I thing class is better because I want to support multiple backends and one backend will be able to initiate with different settings and it also allow the beckend to use instance variables to use caching, collect stats, keeping connections and so on.

[2tunnels]

If you want to separate configuration and execution steps, yes, class approach makes more sense.