Platform customisation and extensibility approach

[twist900]

We want to build Solidex to be highly customizable and extendable. Specifically, as an ecommerce developer building on top of Solidex, I wish to have full control over its functionality and to be able to modify any of its source code.

A potential approach could be based on code overrides. Your store code can override any part of the ecommerce platform code. With Ruby, this would be done by listing the platform as a dependency and then overriding its functionality by prepending patches at runtime. Thus, any part of the gem can be "elegantly" patched. However, Elixir is a compiled language and you don't have this freedom of patching. In Elixir such monkey patching is not possible. 😞

We cannot override the code with full freedom. Then let's consider Elixir's language constructs. Protocols, behaviors and higher-order functions are the mechanisms that Elixir offers to support code extensibility. With the use keyword we can even build mixins and define certain functions as defoverridable. But these language constructs, while allow writing extensible code internally, don't solve the issue of modifying it from the outside. 😞

Perhaps we don't need to modify the source code at all. Let's build a library of functions as legos and then leave it up for the developer to compose them into pipelines. Custom functions can then be introduced for new functionality or to substitute a default one. We would need to provide functions at a really low level of abstraction to allow somewhat high platform customisability. But then we don't have a desired out-of-the-box store and with all the amount of parts that constitute a store this could be quite an issue put a new store together. 😞

An ecommerce platform based on plugins and callbacks, while could be an elegant and clean solution, however, is highly limited in customisability. 😞

A viable solution is then to distribute the platform as is, without the packaging (no hex/mix). Allow ecommerce developers to start directly from the source code by forking/cloning the project repository. Sort of vendoring. This allows for maximum platform customisability 👍, although surely has its downsides (e.g. syncing with platform updates).

@MinasMazar @zabrador What are your thoughts?

[zabrador]

Interesting, yeah it's unlikely we'll be able to reproduce the developer experience of Solidus exactly in Solidex 😞

Let's build a library of functions as legos and then leave it up for the developer to compose them into pipelines.

This strikes me as the most similar to other Elixir projects I've seen (granted, I'm by no means an Elixir expert). Phoenix exposes most of the projects it relies upon transparently. The developer directly configures plug and ecto, for example.

A viable solution is then to distribute the platform as is, without the packaging (no hex/mix).

This definitely makes me cringe a bit, although I'm not 100% sure it's for valid reasons. The greater Solidus community already has a reputation for being quite fragmented (with respect to version) and this vendoring approach would likely make that worse. But like you said, it does more-or-less solve all our other problems 🙃

---

Would this be affected by the scope of the project? Do we want to build a full-stack framework, or have this be more of a headless CMS?

[twist900]

This strikes me as the most similar to other Elixir projects I've seen (granted, I'm by no means an Elixir expert). Phoenix exposes most of the projects it relies upon transparently. The developer directly configures plug and ecto, for example.

True. But it's unfair to compare customisability of a framework to that of a platform. The former gives you the tools to build any kind of product, the latter is the assembled product. The issue is, as an ecommerce developer, I do not want to start from zero (i.e. a framework), but at the same time, given a store (the product), I want to have full control over its code, even if some of my current or future tasks are not foreseen by this platform. I certainly do not want to be limited by plugins, specific extension points, prepared mixins, configuration system, dependency injections etc. I don't want to compromise.

This definitely makes me cringe a bit, although I'm not 100% sure it's for valid reasons. The greater Solidus community already has a reputation for being quite fragmented (with respect to version) and this vendoring approach would likely make that worse.

Solidus is open to any modification by monkey patching, that seems similar to working directly with the source code, perhaps only a better separation of custom code from the original (but then I always find myself in the Solidus source code anyways). And then Solidus version upgrade can lead to unexpected result as much as merging in upstream project changes. Not that Solidus must be a the role model, but it does give me the level of customizability I need.

I do not say the "vendoring" is the best approach and in fact it seems strange in the modern world of gems and packages. Moreover, I see other Elixir ecommerce projects tend to follow this "no-packaging" approach and I recognize that there is no good Elixir ecommerce solution distributed as a package with official extension points and certain ways to its extensibility.

One can say that this lacks design or all the above is motivated by OOP, but I guess the truth might be that the only way to have full control over a product (not a framework) is to own it's code (or monkey patch it). And perhaps this gives us more freedom for designing the internals.

Would this be affected by the scope of the project? Do we want to build a full-stack framework, or have this be more of a headless CMS?

Do you mean full-stack vs API-only? Full-stack sounds interesting + develop the API as well 😎😅. I am interested in a fully customizable plug-and-play solution. WDYT?

[zabrador]

Sorry for the delay here, it's been a busy few weeks 😩

Full-stack sounds interesting Ambitious! I'm in 😎

You make fair points about the limitations of packaging. Let's explore what "full ownership" of the code might mean! How would users implement updates that we've made to the repo? Would they simply fork our repo and pull upstream changes? Maybe we could provide guidelines for how to augment functionality in such a way that it will be easier to merge new changes into people's stores.