Deprecation/Removal: Ecommerce service (DEPR #22)

INTRO

edX’s monolithic Ecommerce Service was meant to be a full-featured product catalog, discounting, and order management service and has grown in complexity for many years until it has become very hard to maintain, let alone evolve. In that time, more and better hosted services have become available for solving many of these problems, and complex use cases have evolved that make flexibility vital for Open edX operators, including edx.org.

We are building a new system that should be flexible and adaptable enough to support any ecommerce product of choice. By uncoupling openedx from a specific ecommerce product, we will enable more contributors and deployments, and remove edX as a blocker for others’ ecommerce.

COMMERCE COORDINATOR

At the center of the new system is the Commerce Coordinator, a highly modular Django web service written in Python. Coordinator will provide a framework for configuring ecommerce capabilities. Individual Django apps will act as plugins to implement specific functionality, for example a webhook for a payment service provider to call when a purchase is successful, that plugin can then signal one that performs the fulfillment in the LMS. The core of the Coordinator will allow commerce workflows to be tailored by combining plugins and routing signals, and will eventually include tools for validating configurations and tracing signal flows.

ROADMAP

We have completed some upfront design and proof-of-concept work and are now bringing it to the community for awareness, review, and support. The next steps will be to flesh out the Coordinator Core while we begin building decoupling Coordinator Plugins to bridge legacy ecommerce. During this process, edX will also begin building plugins to bridge our ecommerce vendor of choice.

We intend to officially deprecate legacy ecommerce by April 1st 2022. When the legacy ecommerce service has been fully decoupled from the platform, it will be removed from openedx or transferred to a new maintainer. Please comment on the deprecation ticket by April 30th 2022 if you would be interested in taking over maintenance.

COMMUNITY SUPPORT

The community can support this development effort in three main ways:

  • Help with Core improvements, particularly signal validation and signal traceability
  • Write Plugins to decouple legacy ecommerce
  • Write “minimum viable” Plugins for development environment

Please reach out if you are interested in collaborating on any of these.

Coordinator will be rapidly evolving and may need some time to stabilize before being included in named releases. Once stabilized, the core should require relatively few changes, and anyone can write their own plugins to suit their needs and sideload them as desired.

COMMUNICATION

Tight and transparent communication with the community will be critical to success. To keep the community informed of our progress, edX will provide monthly updates to Discourse.

ADDITIONAL REFERENCES

Legacy Ecommerce Deprecation Ticket
Commerce Coordinator Repo
Commerce Coordinator Architecture Decisions

5 Likes

@bjh what will be the effect of the deprecation? It sounds like this deprecation is very early directional announcement and is meant to communicate that the ecommerce service is going to be put into “maintenance mode”. Meaning, new features are not likely to get added or accepted by the team that currently maintains the service?

When you are ready to proceed with the removal, I imagine there will be more communication as well as documented alternatives where it makes sense?

2 Likes

Correct on both counts

2 Likes

The ecommerce and ecommerce-worker repositories have been marked as deprecated; they will be in maintenance-only operation while we work on the replacement.

2 Likes

Have there been any updates to share? I’m definitely interested in keeping track of plans, progress, and timelines for commerce-coordinator as my team tries to plan out the eventual integration of our own payment provider.

1 Like

I have asked the Build-Test-Release Working Group if we are closely following the ecommerce deprecation and the forthcoming commerce-coordinator.

I felt “blindsided” when the Payment MFE stopped supporting custom payment processors with Lilac and this is the major reason why we have not migrated our Open edX instance to Lilac-Maple-Nutmeg yet. We are still using Netbanx/Paysafe with our Native Koa implementation. We will soon have to switch to Cybersource when we move to Tutor on our production system in the next few months. Months of dealing with the political implications of that change with our financial backend.

I know this is partially unrelated but I agree that most providers using ecommerce now will need to find a way to replace ecommerce, use commerce-coordinator and setup a new commerce solution in the near future. Regular updates would be a first step. Thanks.

1 Like

We can not upgrade to newer versions of tutor because custom payment processors are not supported and we don’t know when the new ecommerce is available. Really appreciate if we can get a very rough estimate of the timeline,

@michael, thanks for the question. We have only very recently begun coding on this project, but now that we have started I will set a reminder to post updates here on a monthly basis from here on out.

The main update is we are starting to build a small proof of concept focused on porting receipts and enrollment codes into the Coordinator.

We plan to build the prototype and Coordinator plugins we develop in the public edx/commerce-coordinator repo on GitHub, so you are welcome to follow the work there as well.


@sambapete I didn’t know of the historical context, so I’m glad you shared it. The plan continues to be to release documentation and preserve feature flags on how to do the migration to the Coordinator.

The first step is documentation for migrating from ecommerce receipts to frontend-app-ecommerce via the Coordinator. Development of that documentation will start after we finish the coding.


I’m not always the best at finding threads in Discord, but I try to be available in the #commerce-coordinator on the Open edX Slack. Looking forward to continuing to receive any thoughts, ideas, or feedback as we together as a community work on the future state of commerce in Open edX.

2 Likes

Hey @Anh_Vu_Nguy_n! We have wanted custom payment processors for a long time as well. Tutor is new to us, and we have experimenting with creating a Tutor plugin on our roadmap. Do you or anyone you know have the bandwidth to help us get a Tutor plugin set up for the Coordinator? Would love to work together.

1 Like

Thanks for the response @pshiu.

I have been trying to keep an eye on the repo, but your slides from the Slack channel were helpful in understanding how commerce-coordinator fits into the product. It sounds as if commerce-coordinator will eventually enable tremendous “pluggability” on the backend, but that it isn’t intended to address the issue of frontend-app-payment supporting only a fixed set of payment processors. Does that sound correct?

In any case, I’m really excited about the work you’re doing on commerce-coordinator, and looking forward to future updates.

That’s correct, @michael. Pluggability is something we’re hoping will make adding payment processors easier in the future.

Thank you!

Hi all,

this is a small update on ecommerce deprecation. We continue to build the prototype and Coordinator plugins in the public edx/commerce-coordinator repo on GitHub.