I picked up the book and it’s great so far. Thanks @waseigo ! Now I wish I’d picked up the Northwind book when it was on discount.
adam
joeb
ghannam80
Thanks for the work done till now , on this AI subject I think @zachdaniel is introducing a nice thing with Ash AI as it tries to let software ready to serve new AI agent customers.
0
waseigo
Hello everyone, I’m dropping in for a quick update. I’ve been preparing for a Real Estate exhibition and a new release for Breek.gr • The property management software for Greece 🇬🇷 for the past 2 weeks, so no time for the book. However, starting next Tuesday, work continues on the next chapter.
3
waseigo
Hello dear readers and API builders!
After a month-long pause, I bring you a new release of Phoenix Product Codex, v0.23.4. In this release:
-
The concept of how we will/might approach bundles/kits of products in Chapter 1 has been reworked, as the previous explanation still leaned too much on the now-outdated concept of a split between sales items and product variants. With the new concept that we’ll pursue in the upcoming Chapter 7 (i.e., in 2 releases’ time, target by end of June), we are leaving the old concept of the Python-based ProductItems API behind for good, and rely on a purely relational model to deal with variants that themselves can be either component variants (“singles”, i.e. not bundles/kits) or “kit variants”, i.e. variants that themselves are made of other kit variants and/or component variants. The section has been reworked.
-
The new Chapter 5 on modeling the
categoriestable, the first table of the Taxonomy context, has been added. Here, we also implement custom validation functions for 3-character product-category codes using only characters from Crockford’s Base32 alphabet for reducing the probability of typos, and use the Jaro-Winkler string distance metric (withString.jaro_distance/2) to help API users prevent typos or duplication of%Category{}records. We also modifyrouter.exto convert theGET /api/categories/:idroute toGET /api/categories/:identifierthat makes it possible for API consumers like a website to Read category information by the category:codetoo, instead of only by the:id(which is only useful for admin purposes of Create, Update and Delete actions). The categories table was a simple one and the chapter is therefore quite short and punchy.
Some insights about the roadmap
In the upcoming release, we’ll return to the Supply context, where we’ll model the families table of the product families (that belong to product categories). There, due to the growing number of data that the GET /api/families route returns, we’ll start implementing a way to optionally paginate the returned list of results and perhaps also add HATEOAS-compatible link fields to the JSON response (prev/next/first/last), which will also make micro-frontends with htmx simpler to implement.
In the release after that one we’ll tackle the biggest chunk of functionality, the variants table for product variants (supplier-provided singles or kits, or our business’ bundles/kits) and its companion kit_compositions table that will tackle the bundling/kitting functionality. I expect that this will be a pretty long chapter, as we need to also write validation functions that prevent self-references and circular references within the “bundle recipes”. Latest by that point, we’ll also start working on caching database query results with a GenServer and then with Cachex, to keep the API performant even with thousands of %Variant{} records in the database.
After the entire ERD will have been implemented together with the business logic (if it makes sense, perhaps even parallel to that), we’ll start adding the rest of the nice-to-have features in the “Coming Soon / Eventually” section; most importantly, authentication with Bearer tokens to prevent data such as list prices and supplier discounts from leaking to specific consumers (e.g. a website), API rate limiting with Hammer, filtering and sorting for the :index action of all endpoints, and tags that can be applied to entire product families and to variants, for example so that the API can provide data usable by a frontend implementing facet search.
There’s plenty more to come, since we also need to associate all relevant records with Ecto’s has_many/belongs_to and provide nested routes like what we did for /api/suppliers/:id/brands and /api/brands/:id/supplier, so I’m marking the book as a tentative 23% complete for now. However, now that my work on Breek.gr has let off a bit, I can focus on Phoenix Product Codex once again.
Enjoy, and let me know by email or here what you think about the book so far!
Cheers from Athens, Greece,
Isaak, isaak@overbring.com
2
dani
Is there assurance that the book will be 100% completed? Sorry for asking this, but I bought leanpub books before that didn’t get completed 
0
waseigo
imposter_syndrome
waseigo
It’s done well so far, with great feedback, despite only being available through Leanpub for now, and only an estimated 28% complete. We’ll see! 
0