...
Document: https://docs.google.com/a/edx.org/document/d/1qBeZG8Z-qqeHdTzQlS5e2-s6iuui7OEnzGZLzFp45W4
Attendees: Ned, Will, Steve Sanchez, Miki, Beth, Piotr, Dave O., Jason Bau, Steve Magoun, Nimisha, Cale, Ed
Will walks us through slides.
Goals next quarter:
- Enable e-commerce features that we could build ourselves but would be one-off work, so we want to be able to get them elsewhere
- flexible product catalog
- product bundles
- Independent deployment of e-commerce
- a/b tests done quickly, optimize the pipeline
- (miki) could also reduce the time to run tests
An open-source shopping cart implementation, more features than we have now
- backend APIs for products, orders, discounts, etc.
- more payment processors
- provides an admin UI
- NOT using the off-the-shelf user UI
- whitelabel will need it
- assuming the worst, and will need to a/b test the cart experience itself.
- looking at existing open-source cart implementations
- want to be good open-source citizens, will contribute back
Services
- E-commerce front-end
- UI for payment and verification
- eventually, UI for course discovery and student dashboard
- communicates with cart and LMS through well-defined APIs
- need to support whitelabel, and open-source theming.
- (cale) wasn't part of the point to avoid the complexity of whitelabel and theming?
- (will) maybe we'll start with separation, and then add back in theming, but where we can, build in the hooks as we go.
- for Q3, our focus will be on the velocity of the destedx team.
- (steve m) can't compromise the cart in white label, it needs to work all the time
- (will) end of q3, edx.org can switch over, then we can talk about whitelabel.
- (steve m) could be tricky to support two carts, with untested assumptions between them.
- (steve s) need good test automation for microsites to ensure no breakage.
(Beth) why are we not looking at whole e-commerce suites?
(Chris D joins)
(Miki) likes a homogenous tech stack, and wants to be able to support the open source community.
[Q3 Architecture drawing]
- Payment processors: external now, but not necessarily
- Report and Audit: Chris D has started it.
- Looking to move course modes to be variants of products in the shopping cart.
- "Product" vs "Course": carts will call it "product", and we need to be able to sell things other than products
- in the diagram, e-commerce front-end and shopping cart are shown as two services, but we could combine them in one-process
- (ed) will credit-card numbers ever be on our network?
- for pci-compliance, we want them not to be.
[Post-Q3 Vision]
- better encapsulation
- drupal has a reduced role
- more, smaller services
- should we make it a requirement that services can run in-process for ease of debugging, etc?
- defining a flexible in/out process layer will be a good strategy for pulling code out of the LMS
- (steve m) resiliency in the face of service failure?
- (cale) we have patterns for this, but we haven't implemented them.
- (miki) is this different than the db being down?
- (ed) yes, because db is essential, nothing can happen if it's down. These services, we could make more optional.
- (miki) IDA addresses a lot of these sort of patterns. we need to do that.
- (nimisha) feature-flag thinking already gets us thinking about optional services.
- (piotr) latency? many network hops will mean a slow UI
- (miki) we'll need to solve the response time problem.
Providers in other languages:
- The bar is really high to choose a provider in a language other than Python.
- If we choose one, we have to have really good reasons.
Comments needing response
- What patterns will be used to make the system resilient to service failures?
- All APIs should come through the Architecture Council
- What approach is being used to be certain of interoperability with external services?
- Payment processors can be re-chosen by other operators, but not other services.