Hello there!
It’s been a while since the last release of Phoenix Product Codex, and for good reason: I just published a new release with two new chapters spanning 72 pages.
Chapter 6 is about modeling the families table, but doesn’t stop there. We also make it possible to accept a :category_name/:category_code and/or :brand_name in the JSON body of a POST to the /api/families route, besides only :id values of the associated category and brand records. Moreover, we implement association fields across all modeled schemas, so that we can flexibly get a family’s supplier, a supplier’s families, a category’s suppliers, etc.–eventually, also by adding more nested routes to all top-level routes.
Chapter 7 is a break from database modeling, and deals with implementing the improvements of the previous chapter across all types of records. We implement a “flexible identifier” feature for GETting records by their unique identifiers other than their :id, so that you can now do (for example). GET /api/categories/Rotary%20Valves (by the category :name) or GET /api/categories/161 (by the category :code). Most importantly in this chapter, we evaluate the associated fields that we should Repo.preload/2 by default for each type of entity, and even more importantly, we make JSON responses consistent across all entity types by centralizing the *JSON modules’ data/1 function within a new ResponseData module and using the defdelegate/2 macro from the *JSON modules to the new ResponseData.data/1 function. Therein, we use recursion and Ecto’s schema reflection capabilities to automatically populate the response map with non-nil association values. It works out nicely.
Many thanks to @belgoros for the first testimonial and his kind words:
An amazing and completely unusual approach to presenting the material of the book, as if you are looking for a solution to the problem with the author and go through all stages of searching for a solution with him. This is exactly what is happening in practice and, in my opinion, this is a huge advantage of this book compared to other books or courses.
With the summer already underway, things are getting relatively quieter and more predictable in my other businesses, so expect to see more frequent updates during July and August.
With the next release, the book will break the barrier of 200 pages. Though the number of pages is a misleading indicator of progress (due to the amounts of code snippets), I am marking the book as 28% complete in terms of scope (not pages). We still have a lot of ground to cover, but the data bedrock of the Products Elixir application are almost complete, and due to be completed in Chapter 8 (variants and kits/bundles in the Catalog context) and Chapter 9 (descriptions in a new Content module, and tags and other metadata for sales-item status, availability, discontinuation, etc. in the Taxonomy module).
Though it’s tentative for now, I foresee that we’ll deal with business logic for issuing unique and lexicographically (i.e. also more typo-resistant) item codes for variants in Chapter 10. After that chapter we’ll be ready to import real-world data from the ISATEK product portfolio into our database (and also implement an exporting feature into CSV/ODS/XLS/XLSX), and we can then move on to implementing features like caching, pagination/filtering/sorting/search and HATEOAS, API rate limiting, webhooks for event notifications, API documentation with OpenAPI, audit logging, and monitoring with the Phoenix LiveDashboard, before we finally learn how to deploy our app to production.
A big thank you to the 49 early adopters who have purchased Phoenix Product Codex at such an early state. Enjoy the two new chapters!
Cheers from Athens,
Isaak
isaak@overbring.com
