“Phoenix Product Codex” updated: generating variant codes

Two new chapters and 53 new pages of Phoenix Product Codex are now live on Leanpub !

In Chapters 9 and 10 we take a break from API design and focus on a domain-specific challenge: generating unique codes for variants of a product family, especially in a way that mistake-proofs them against typos. These chapters build on the earlier modeling work (e.g., suppliers, brands, categories, families) and introduce some fun algorithmic problem-solving in Elixir.

• Chapter 9: Issuing random variant codes explores automating code assignment to avoid manual pitfalls like sequential or keyboard-adjacent errors that could mess up offers, invoicing, or orders. We start with criteria for uniqueness and typo-resistance, implement queries in a new VariantCodes module, and try out a brute-force approach of randomly “rolling the dice”. Performance is abysmal, and so we set the stage for a more sophisticated approach, with more constraints.

• Chapter 10: Generating unique variant codes with a Markov Chain pivots to using a Markov Chain for probabilistically selecting sequences of transitions between the character of the code using weighted sampling. We incorporate more penalties, including one that uses a new Keyboard module to penalize transitions that include characters that are keyboard-adjacent. This helps reduce the likelihood of “fat-fingering” a code. We also build in a feature that weakens the penalties based on the “degree of depletion” of the pool of available codes for a product family. This means that code generation becomes less and less picky as the pool is gradually depleted over days or months (or years) of creating new variants. Here, we optimize queries, handle edge cases, integrate the result into Variant.changeset/2 so that a :code value is automatically generated if not manually provided. Finally, we run a few benchmarks and look at the pretty good (to excellent) performance of this approach, while also noting some of its shortcomings.

Chapter 11 is already in the works, and brings us back into API design. We’ll get into the new Content domain, in which we use use tables for storing metadata for different entity types, such as multilingual marketing and invoice descriptions, variant availability and status. In the Taxonomy domain, we’ll make it possible to tag records so that API consumers can filter collections by attributes, such as showing all families or variants that comply with ATEX regulations, variants in stainless steel, etc. This will become important for enabling facet search.

• The book is available as PDF and ePub on Leanpub
• Join the discussion on elixirforum.com