search

FoxComm / highlander

Because there can only be one
MIT License
9 stars 3 forks source link

New promotions module #2127

Open annappropriate opened 7 years ago

annappropriate commented 7 years ago

New promotions module

Link to documentation: https://github.com/FoxComm/highlander/tree/master/documents/design/promotions

Why do we want to go for new implementation instead of refactoring old one:

  1. existing code is heavily tied to other parts of phoenix. Moving is total pain
  2. implementation must be changed anyway
    • promotions must be implemented on relational model rather than form/shadow
    • ES queries are difficult to track and often superfluous

Approach

  1. start not from model definitions, but from an API. For now, promotions will exist as phoenix module, so API is purely programmatic rather than HTTP, but this approach should be taken in case of HTTP API implementation as well.
  2. promotions module should know nothing about other entities existing in phoenix. It must receive some primitive data and either use it in qualifiers or echo back for API convenience.
  3. module should not make any external calls to ES or Kafka or whatever
  4. tests should be contained in promotions module and broken down into multiple test suites instead of one multiple hundred lines integration test.

Migration to new module

What I'm thinking about is:

  1. As soon as module API is ready (even as a stub), start placing calls to new module in phoenix code where they're supposed to be
  2. When module impl is ready, migrate old data to new tables
  3. Leave both implementations (old and new) running in phoenix only on dev/stage envs
  4. Compare results in search views, switch dev/stage to new version of search view
  5. If new module behaves well, rip out old impl

Open questions

General technical design changes

Roadmap

Phase 1: Pre

Start with basic outline, define streams of parallel work. It's totally possible for us to start writing tests before the implementation is done as we already have a set of existing ITs that we can analyze and migrate.

Create in code:

The above objects are two only entry points for phoenix. APIs should each have a sufficient API defined for a full-blown communication. We need to define how we want them to look. I would also argue that PromotionsBulkAPI and CouponsBulkAPI must be separate objects.

For test suites, I would like a better separation: I think each method in API object deserves its own suite at very least

Phase 2: Barebone promo implementation

Everything should be ready at this point for implementation to be filled in.
Requires tech spec.

Phase 3: Auto-apply algorithm

Auto-apply seems more difficult to get right than coupons, so I suggest we start with it.

Phase 4: Coupons implementation

Phase 5: Auto-apply vs coupons

I figured this deserves a separate section. If, by any chance, we already have this covered, then this can be skipped. Otherwise, spend some time on this.

Phase 6: Search view

Instead of building a trigger-based table in postgres, push directly to Kafka

Phase 6: Versioning

To implement relational versioning, consider using this trigger approach that Roman uses for CMS. This section will be filled in later.

michalrus commented 7 years ago

Failures: this is a good chance to try and define a new Failure structure

It would be very cool if they were auto-deserialized in tests, but probably not going to happen…

michalrus commented 7 years ago

I think each method in API object deserves its own suite at very least

Yea, those 4897 LOC files are pain!