PROJECTS Posts
It's been a while since I did a weekly news update for All the Flavors, but I haven't blogged much lately either. These are updates that will be in the next release.
Light Mode Theme
Probably one of the oldest ToDo items on my list is finally done. In the next update, ATF will have a light mode, which can be set in user settings.
Persistent Page Counts
The pager selection for number of items on a page will now save between visits. That means if you always set the recipe list to show 50, next time you return it will already be set to 50. I also adjusted the default item counts to be more consistent, for instance Formulations on a Recipe will display 25 now instead of 5.
Tutorial Link for Features
I've added a new feature that will display a link to a tutorial for whatever feature is on the current page, if that tutorial exists. For instance, if you are on the Create a Recipe page and if there is a tutorial for it in our help pages, it'll display a link in the side menu to that tutorial
Expanded Home Page
The home page has had an overhaul, both in styling and how it loads the content. It will also have some new content, displaying recent batches and forum topics.
I also have several other features that are in the works, mostly totally new, but some are improvements over current features. The updates above should be active in the next few days.
I've merged Grazie! 0.7 from the dev branch into the main branch. It doesn't have everything I wanted, but I plan to incrementally build it up to 0.8 with rsbuild and more features.
The main feature in 0.7 is the site folder. This allows you to create a custom theme and routes, without modifying anything in Grazie. You can add additional routes or override a default Grazie route. Instead of having multiple themes within Grazie itself, there is now a single default theme and you can override it with a theme in the site folder. I've migrated the project for ProfoundGrace (PFG) to the new Grazie and it works really well. PFG adds a bible, which isn't in Grazie, but it just adds those additional routes in its site folder. It also has a custom theme, again, just in the site folder.
This makes it much easier to extend Grazie!, without causing merge conflicts when you want to update your base version of Grazie. The plan is to expand these extensions and overrides, so you can have a completely custom version of Grazie running a site, without having to change anything in the base version of Grazie. As I move toward 0.8, I plan to add block extensions and overrides as well as others. I don't know if I want to allow complete overrides, yet, or if the route overrides are enough. You could theoretically completely customize your site, just by overriding routes and having your own components (or just replacing the ones you want to replace).
The 3 main things I want for 0.8 is to finish the blocks system, which includes being able to extend or override blocks; the ability to extend the dashboard; and, of course, rsbuild. I'm still waiting for the React Router extension to be published by rsbuild; they are working on it, but it still hasn't been published to NPM yet. If I figure out the code splitting issues with Zulu, I may just swap to it, because Zulu already uses rsbuild. Unfortunately, I don't know if I'll have time for that and I don't plan to have Zulu ready until we are approaching 1.0 for Grazie or maybe even later.
Finally, I will be splitting a repo off of the main Grazie repo to use for this site. I think it's time Grazie is it's own thing and this site will just expand in it's site folder, while I build onto default features into Grazie. Eventually, Grazie will have it's own web site, but I don't know if that will use the official Grazie repo or it's own fork.
About a month ago, I mentioned I'd been building a scripting language named Languish. I've decided to rename it Yall. The main idea of Yall is to have a scripting language that is easy to use and learn, while having all of the features built in one would expect in a modern language. One thing I've been working on a lot is the error handling and exception system. In my opinion, this is one of the most important pieces of a language and most languages simply fail to implement a decent error handling system.
For instance, why is there ever an uncaught exception? Yall assumes that each code block, function, and method is able to throw or catch an exception. There's no need for a try-catch. If an exception propagates outside of the user code, then it is caught by a global catch, which can be configured with user code exception handlers or error types. In the user code, you can specify catch and throw as part of the return statement (or individually). There's no need for a try-catch.
Catch statements can also retry with another function, a new code block, or a loop back retry statement, which allows you to re-run that block of code or function with default or updated parameters or state. In addition to the traditional, immutable, error object, there is also a context object, which gives you a mutable object inside the exception system to define however you please.
The last thing, for error handling, I've been working on is a special kind of type for errors. These types define or structure the error handling and can be extended. I haven't worked out all of the details yet, but the idea is most of the error handling should be handled by the types assigned, and then you can supplement that, if needed, in the user code, but there should never be an unhandled error or uncaught exception, because they get handled by the interpreter if nowhere else.
I spent some time tonight working on the next version of Grazie!, which will be 0.7. Following my redefined roadmap, the major change is the update from Remix to React Router 7. That is mostly complete. I've also done some bug fixes and added some missing features: added delete functionality for Posts and Pages; fixed a bug where editing a Post didn't display the categories list; Pages now display status, if they are a draft, and an edit button; the Tumbleweed Snapshots feature has had a few display fixes and its feeds (RSS, Atom, & JSON) now also list the latest snapshot.
Some of the features I'd planned for 0.8 may come in 0.7 instead. This is mostly because 0.8 will, hopefully, use Rsbuild, and that looks like more of an undertaking than I initially expected. Rsbuild is working on a react-router-plugin, so that will be a lot of help, but it's not released yet. My intention is to fork that plugin to become a zulu-plugin, but Grazie! doesn't necessarily need to be running on Zulu for 0.8. I'd rather build up Zulu on the side and switch to it once it has matured some.
With that in mind, I'll probably do a few more fixes and update the main branch to 0.7, then build onto it a few incremental versions, on the way to 0.8. I would like to improve the Notes and there's also the Theme system updates and a Blocks system planned. The latter two will be transformational, as they add some very convenient features. I also want to add an RSS reader, image galleries, and auto-save.
Zulu is a server-side rendered framework for React. What makes Zulu different from other frameworks is it uses Rsbuild for its build tool/support libraries, Biome for linting and formatting, and the React Router 7 framework for routing, and it doesn't use Vite. Initially it will use Mantine for UI, for my own purposes, but I plan to provide templates, or at least a barebones version, people to choose their UI.
I personally feel this combination of tools provides a lot of functionality, so Zulu itself is actually very small, as it relies mostly on its core dependencies. It also provides a fairly straight forward migration from Remix 2 and React Router 7 framework. This is by design, as I use Remix for my personal and professional projects. The main difference between Zulu and React Router 7 framework is it doesn't use Vite and it uses a custom server built on node:http. I plan to experiment with other server options, but so far node:http has been more than adequate.
The real powerhouse behind Zulu is Rsbuild, which is blazing fast, and just very good all around. I really don't understand why more projects aren't using Rsbuild. In fact, Rsbuild was the initial step that got me to build Zulu in the first place. It's just not being used that much and it's almost silly how fast and flexible it is. A friend of mine, who generally uses SPAs, seemed quite impressed with the build speeds we are seeing in Zulu.
You can already fine Zulu in my public github repositories, if you want to take a peek. It's very much experimental and will probably be unstable until I can build up some decently sized test cases. I'm currently using it to replace React Router 7 framework (Vite) in the dev branch of Grazie!.
I think all of those names are taken, in one form or another. I'm mostly kidding anyway. But in all seriousness, I have a beginning of what could be the new base for Grazie! and potentially ATF. It works like Remix, but it doesn't use Remix, it uses React Router 7, but doesn't need Vite, it's server-side rendered, and it builds with Rsbuild. It also uses Mantine for the UI and, so far, just works. It has a few rough patches. It currently only has the production server and it's using node:http. I plan to work on the dev server next, preferably using the dev server that comes with Rsbuild.
It hasn't been easy to figure out all of the pieces. It seems not a lot of people are trying something like this. I'm not entirely against sticking with node:http for the server. I'd prefer express or maybe fastify, but it's not a deal breaker yet. I definitely want to use Rsbuild. I'd probably be happiest if someone could make a remix/react router plugin for Rsbuild, but from what I can tell all attempts at that have failed. I have been learning a lot about how Remix works internally, so maybe I could do it eventually, but I'm kinda liking the path I'm on at the moment.
The purpose of Grazie! is to have a CMS that can be used on multiple web sites, without having to start from scratch each time. It's still moving in that direction, it's not perfect for that yet, but that's where I want to get. The goal is to have Grazie that provides a reusable, stable base, and then you can extend that or override it.
Remix has been ok for the CMS piece. Unfortunately, everything I've tried with the Vite Dev server in the later versions of Remix 2 or React Router 7 has been atrocious. It's unusable as a dev server, as far as this code base goes. The production server is fine in React Router 7, but I've put too much time trying to figure out the dev server and I'm not doing it anymore. I'd rather do something else that may or may not work, either one still feels more productive.
So here's the new and amended plan:
I want to use rsbuild as my build tool.
I want to use Express server for production and rsbuild for my dev server.
I'm willing to use React Router 7 as the router, but it's losing it's luster for me.
I'll consider using Tanstack router, if it checks all of the boxes.
That's it for now. I think that's doable and then I can carry on with the more important stuff from there.
I've updated this site to the "latest" version of Grazie. It's now caught up with the main branch, which I'm calling 0.6. The actual latest is 0.7, which is the React Router 7 migration, but it's not ready yet. That branch isn't in the repo yet. I'll probably tag 0.6.0, as it is the last Remix 2 build, and 0.8.0, as it will be the first beta. 0.7 will be the beginning of a new dev branch in the repo.
I can't remember if I'd mentioned it before, but I've built a parser and page to track Tumbleweed snapshots. It'll be in the next site update, which should be sometime this week, I think. There will also be feeds for other sites to use. The Tumbleweed page will display what snapshot you are on, if you are using Tumbleweed, and there's a diff viewer to show package changes between the current snapshot and the past snapshots.
I haven't updated the Grazie versions in a while, so when I merge the React Router changes, I'll call it 0.7.x. Version 0.8 will have the new theme system updates, which will be a pretty big shift, and then 0.9.x will be betas and RCs.
I am not at all happy with the way the react-router dev server works, which is just vite dev. It is very slow and is basically only useful for error messages. I've put in a stop gap with nodemon and the production build/serve, which is much better, but not entirely useful as a dev server. I'm still trying to get it figured out. Unfortunately, it's the reason I hadn't migrated much sooner, even to newer Remix versions, because the dev server is just terrible.
I still have a few updates to do in the react router migration, mostly dealing with how route components changed from Remix 2, and tweaking the routing in general. It runs really well on the production server, I just want to get those few things cleaned up.
I'm not sure how much time I'll have to work on it this week, but I'd like to get this site updated with the last Remix 2 version of Grazie. I'm trying to decide if I want to launch ProfoundGrace.org with the Remix 2 version or wait and merge the React Router version into it first. It may be easiest to wait for the changes planned for 0.8.0.
Speaking of 0.8.0, my plan for it is to add a site folder outside of app, but I'm still trying to decide on the exact structure. The idea is to have the core Grazie app and then site specific stuff in the site folder, like theme, routes, and components. This makes it easier to build different sites which Grazie and makes merging upstream changes easier. I'm also thinking about dropping PostgreSQL support. Allora will have a better database alternative to SQLite, so I don't really see the point in having PG in Grazie!. It's not changing for now, but is a possibility.
I had planned to stay on Remix 2, without Vite, for a little longer, but some initial tests went well. I've rebuilt Grazie! to run on React Router 7 Framework, which is the equivalent of what would have been Remix 3. This means we get React 19 support and Vite. The latter, I'm not super impressed with. I kinda hate the Vite Dev server. It's super slow, compared to the Remix Dev server. I've tried a few things to speed it up, but I can't believe it wants to download every package file as a chunk on every refresh. That just doesn't make sense, plus it's non-responsive for a good 10 seconds after a restart. It has to be, something, not entirely correct, but I haven't figured out what, if that is the case.
The good news is the production server runs fine, so I've decided to press on. The big changes planned for February are, obviously, the RR 7/Vite migration, and then I plan to restructure the way themes and overrides work. Currently, you can override a page/layout, based on the loader value for that page, in your theme. I plan to add route and component overrides as well, but I haven't decided if those should be in the theme yet.
The goal is to build something that can be deployed and built onto for different purposes, without causing a lot of issues merging upstream changes. Th current structure is almost there, but I feel like it needs another layer between Grazie! and site specific changes. It needs a better core and customization separation, basically. That's what I hope to solve in February.
In addition to the package/framework migration, I'm also adding password resets and email support. The email support is kinda needed for the password reset. This change is driven by me moving away from bcrypt to the Node.js crypto module for password hashing. If a current user has a bcrypt hashed password, it will trigger a password reset workflow, when they try to log in.
If I get everything done, that I want to, in February, then we may be close to a beta for March. There are a few additional things I want to fix or add, but it wouldn't hurt for them to come later.
Today I merged the new RSS, Atom, and JSON feeds into Grazie!. The feeds are currently only for latest posts (up to 25 items), I plan to add feeds for categories in the future. I've decided to take a step back from the work I had done for theme component overrides. I think the block system is more important and may make component overrides unnecessary. I also worked on a page that processed Tumbleweed snapshots. That's mostly a personal thing for me, but it could be useful as an RSS feed, which I plan to add as well.
It's been sitting for a while (20250103 branch), so I went ahead and reviewed/merged the early January updates into Grazie!. It's mostly just the Notes functionality (although not complete) and some bug fixes. I've been working on theme overrides for route components/loaders. I'd like to get that finished for some other projects I'm working on using Grazie!. Either way I'll likely upgrade this site sometime this week just for the Notes functionality. I've also been working on RSS support for Posts, some RSS reader features, and a content block system, which will likely be part of the February updates.
I've been experimenting with creating a new scripting language that I'm writing with Rust. I've named it Languish, which is a synonym for Rust and a word play on Language. Surprisingly, it's actually coming along fairly well. I don't want to really get into details yet, but it has some novel capabilities and has been kind of refreshing to work on. I don't know when it'll be ready, but I plan to get it to the point I'm happy with it and then I'll begin sharing it with the world. For now it's just another side project.
In the evenings I've been working on the reboot of ProfoundGrace.org (PFG), which is being built on top of Grazie!. I have the Bible feature working fairly well, with some additional features it didn't have before. PFG will have it's own theme, named Rock, based loosely on it's existing color scheme. The work has driven some fixes and improvements to Grazie! as well. I found some bugs in the pager and content lists: the pager currently overwrites query params external to the pager itself; the posts listing page doesn't display correctly for privileged users when there are no posts. There have also been a few little fixes here and there.
In Grazie!, I've been working on the Notes feature, which will later merge into PFG and kinda be specialized for that use case. Notes in Grazie! are mostly a feature for me or any user that registers here; they are private notes and lists, so you can only see the ones you create. I also plan to add website Bookmarks to Grazie!, but I don't know yet if they will be public or private (or both).
ProfoundGrace.org (PFG) hasn't had any updates in a while and it uses ArangoDB, so I'm converting it into SQLite so I can use Grazie! with it. I had been planning to use Allora (the SurrealDB variant of Grazie!) for it, but it seems like overkill and I was working on some JSON to SQL scripts earlier, which gave me the idea to use it with PFG. The tooling is intended for a project on ATF, but it actually works really well with SQLite as well. I have the SQLite tool in a repo, on github, named dbtools, if you want to take a peek, otherwise I'll talk about it later on when it's more capable.
I need to get back to the ATF work, which inspired this change, but I mostly have the Bible feature ported to Grazie. I'll work on it on the side and try to get it online in a couple of weeks. This was all necessary because I'm moving to SurrealDB and want to drop my ArangoDB sites/servers. Getting PFG converted gets me another step closer and SQLite makes a lot of sense for mostly static data. The content features don't get a lot of traffic, but the Bible does, so I don't want to take it down without replacing it.
I've been working on several new development branches for All the Flavors. We also acquired VC (https://vapingcommunity.co.uk/), which was, previously, going to shutdown 1 January 2025. Hopefully we can keep this great community going.
Batches
We've added a Browse Batches listing, for public batches. You can also now feature a public batch by pinning it to the Recipe, there's now a list of public batches on the Recipe, and a toggle button to choose which batches are viewed. This one is completed, we just haven't pushed it to the live site yet.
Flavor Reviews
We are adding Flavor Reviews and updating the way reviews are displayed. Reviews will also have like and dislike buttons.
Recipes
We are updating the flavor tooltips in the recipe editor to display flavor ratings, favorites, inventory amount, and location info.
Tags
We are adding a page to browse by tags and displaying tags on item listings (like flavors and recipes).
Home Page
The home page is getting some styling updates and some new content, like recipe forum posts and recent reviews.
Flavor Compounds
We are building up a new data set of Flavor Compounds, which you will be able to use in Recipes. These will also enable you to create perfumes and other aromatic recipes.
We launched the new calculator updates. These allow you to mix recipes with flavor shots and premixes, as well as mix a premix from just a formulation.
We also had some bug fixes in the update. There was previously an issue where mix counts weren't incrementing, so that was fixed. We fixed a bug that would cause issues if a recipe had more than 20 revisions (due to a self-imposed query limiter). We also fixed a state bug when adding favorites or flash stashing flavors from a recipe view.
Next
I am currently working on enhancements for Batches. There will be a general Browse Batches menu item and page. Recipes are getting featured or pinned batches, so the recipe author can highlight a mix or variant of the recipe. Recipes will also be getting a public batches list. These will all be under a selector button, so you can choose which batch view is being shown, instead of adding more buttons or tabs.
We will also be adding the ability to set ingredients to 1/1000 instead of just 1/100 as well as the ability to mix by parts, instead of percent.
We have some new types of "ingredients" we will be adding soon, which goes along with the 1/1000 and parts updates.
Finally, there is still an outstanding bug in remixing batches: if you modify a formulation in the calculator, the changes don't show up when you remix it. I've worked on that some and will try to get that fixed soon. I will probably spend a week here soon just bug fixing, as I'm sure more will probably be identified with the more recent updates.
Just so you know, I've forked Grazie! (my own project) and created a version that supports SurrealDB, named Allora. So far it's a 1 to 1 port, with just changes related to SurrealDB and dropping SQLite/PostgreSQL support. It's taken a lot longer to find time to work on it than I hoped. It will be the platform BeSquishy will be built on and will be open sourced eventually, along with the SurrealDB tools developed for it.
We've been doing some big calculator updates for ATF.
Formulation Mixes
We've added a formulation only mode to the calculator, so you can make premixes.
Premixes
You'll be able to add a Premix to the calculator, which can match the formulation or be additional ingredients. You'll also be able to replace a formulation with a premix.
Flavor Shots
You'll be able to mix with a flavor shot of a recipe.
Other
A big focus of the calculator changes initially were to make it more modular, but I'm not very happy with how that turned out. That will happen, but it'll be a work in progress and may wind up being a separate experimental mode.
We've fixed a few bugs with the calculator, most of which people haven't seemed to have noticed. I also fixed some bugs in the Recipe History display (again, probably unnoticed). There is one outstanding bug for remixing a batch, but I haven't tracked that one down just yet. I also fixed a bug that wasn't counting mixes correctly and one that didn't update if you added a flavor to flavor stash/favorite from a recipe.
I've also worked on improving the formulation selection for mixing, including a selector in the calculator. This won't be in the next update, but it's coming.
There's more, including some enhancements for tags in item lists and some public batch improvements, and some all new stuff that has been a work in progress.
This past week we released Recipe History, which allows you to track recipe revisions, revert to older versions of a recipe, or save an older version as a new recipe. We also released an update that allows you to copy a new recipe from a Batch of another recipe or update a recipe from a batch that was modified in the calculator before saving it. The third update added the flavor information from the Recipe editor to the calculator freeform and modify features. Finally, we added user cards that can be clicked to activate on Recipes and Formulations.
It's hard to believe we only have 12 weeks left this year. We still have a lot we want to do. This past week I developed the user cards and did some finishing touches on the Recipe History before launch. I also worked on the ability to mix a recipe as a flavor shot, which is mostly functional now, and the ability to select ingredients in a formulation to be part of a premix. These are all built on the branch that adds the ability to mix a formulation without a recipe, so the part that creates a premix.
We are getting close to the calculator state we want, which will allow us to add more functionality to it. We also want to break up the calculator and make it more modular, but that should preserve functionality and just allow us to do more things more easily in the future. I should be getting my co-worker back soon too, so either the pace will pick up or we'll be developing a wider range of features.
This week I opened pull requests (reviews) for updates that add a revision system for Recipes. This displays every change to a recipe, including if it was created from a copy of another recipe or from a batch of another recipe, or updated from a batch from the same recipe.
I also opened a pull request that adds the flavor info to the calculator modify function and to the free form calculator.
After that I've worked on adding the ability to mix a recipe as a flavor shot, at a specific percentage, the ability to mix formulations as premixed bases, and the ability to designed premixes in the calculator. Those aren't complete and, due to the overall complexity of the calculator, are actually a little more difficult to implement than you may imagine.
There is another calculator update on tabs next, which will make it possible to select any formulation from the calculator itself, rather than having to find it on the recipe page. That should catch us up to what most people have requested and lines us up for a new type of ingredient and a new way to create formulations and use formulations. Eventually I want to add some new community features and better browsing features for batches and tags...but I'm slowly getting there.
I've been working on a Recipe versioning system for ATF. It's been...not that easy, but I ended up reverting back to the simplest way I could think of. I've probably built 10 different versions, ironically, of the version system. The system I ended up deciding was the best is mostly like openSUSE's Snapper. It creates a pre and post-change snapshot, with some pre variations, depending on the source of the revision. Currently, the only time a revision is triggered is when a flavor changes, but I am experimenting with other things, like recipe descriptions.
Additionally, I've also been working on the ability to update or create a recipe from a batch. This ties into the versioning system, but is change to the way we normally update recipes. The idea is, instead of simply editing a recipe, you create a new mix and change the flavors within the calculator. You then mix it and try it, if it's good, then you can update the recipe directly from the batch. This creates a new revision of the recipe and ties that revision to the batch and recipe. It's a change to the normal recipe development workflow, but it should make it simpler and reduce the number of clones and things like that.
Finally, I haven't forgotten about clones. If you clone a public recipe, that recipe will be tied to revision 0, which is the initial version. If it wasn't a public recipe, then it acts like the current cloning system and ignores the original version. This allows you to create original recipes, even if they are actually based on a private recipe base. Also, sometimes you may create a new batch that is good, but should be it's own recipe. The new version system will allow you to create a new recipe from that batch, like a clone, except it's from a batch. This means you can start out just creating batches, and when you get to the point where it's a legitimate recipe, then you save it as a recipe from the batch.
So the next features will be recipe versions and recipes (updates or new) from batches. After that we have some calculator updates and some new recipe features, plus some community features. I'm not sure which order those will come, but both are a priority. Among the calculator updates are some new features, mostly for our flavorists and vendors, but they could be exciting for others in our DIY community, who aren't necessarily happy just using regular flavors ;) More to come on those. That's it for the week 38 update. Sorry for the gap in weeks, I'll try to do better with the updates.
I've been spending my spare time working on Node.js tools for SurrealDB. The 2 that are showing some promise are named Surrealigrate (a migration tool) and Bole ORM. I may end up changing their names, but for now that's what I'm calling them.
I've talked about both of them, so I'll try not to repeat myself. I've worked on expanding Surrealigrate some, but I need to work on some more advanced schemas and namespace setups to really push it. This week I've mostly focused on Bole ORM. The word "bole" is a kind of clay or the trunk of a tree, which both are kinda fitting for an ORM, in my opinion. My approach with all of my SurrealDB tools has been to take advantage of the built-in info queries and generate database specific code. A lot of tools, especially ORMs, are very standardized and strict with their implementation. I don't want that. I want to be able to generate query tools that are specific to the database and then be able to adapt them however I want, without the ORM getting in my way.
Bole ORM is a simple CLI tool and it generates a query class built for that specific database, down to table names and specific fields' validation. It doesn't require any kind of schema files or anything that manually needs to be done by the developer, it's all generated by inspecting the database. While it currently generates a class, to be used as object-oriented, I also plan to make it configurable, so if you prefer chaining, it'll do chaining, instead of objects. It resembles Prisma in the way the queries look, when using the class output, but it's simplier and I'm pretty sure the where and fields (Prisma's select object) objects may support more options than most Prisma methods support.
All the Flavors uses Prisma, so I'm very familiar with it and it's actually powerful when combined with a GraphQL parser. That is why I'm mimicking Prisma, to some extent, but also adapting with some things I feel Prisma could have done better. Once the feature set is, well, set, then I'll go into more details for the actual capabilities...but there's also a catch. I plan to make the generator modular, so you can plugin whatever you want, leave out whatever you don't, or add custom modules. This means you can basically design your own ORM with modules and just let Bole generate it.
I want to add some additional utilities to each. For Surrealigrate, I want it to be able to identify potential missing indexes and suggest changes. I also want it to be able to use either schema within SurrealDB or from a library, such as Zod, to generate migrations. The other side of that, I want Surrealigrate to be able to generate a Zod schema and validations for use outside of Surrealigrate, in Bole ORM or just in your application in general. As far as Bole ORM additions, I want to generate documentation for the specific database, and Bole ORM itself, and I want to do automated tests, primarily on data integrity, but also for the application itself.
The idea behind these tools is to simplify development and have something you use when you need them, but they get out of your way when you don't. There's no point in making someone run a bunch of CLI commands, when you can use Surrealist to design your database, then just run a simple command that does everything else. That's the way I see it anyway. If extra commands are involved, they are optional and they add value, like a command to generate a Bole query that you can paste into your application. That could just be a plugin though, and then it just updates a generated export and you never have to touch it again. Working for you, not against you.
Every week I'm going to do a summary of what I've been working on for All the Flavors (ATF) and some of the things we are planning. I'll write it throughout the week and try to publish it by the following Monday. This is the first time, so I'll start with
Week 31:
We released ATF v.2.3.13. It featured administrative tools for creating and managing badges for Users, Recipes, and Vendors. It also fix a bug in the messages application that prevented replies to reports sometimes. Finally, it introduced improved email queuing and sending, without which could make the API seem sluggish at times.
I also submitted the Pull Request for Remixing Batches for Recipe + Formulation batches.
Week 32:
Monday I submitted Pull Requests for improving the button layout in the Recipe editor and permissions system improvements. Finer-grained permissions will allow us to delegate some tasks to specific users, such as a Vendor being able to assign their badge to users or a streamer having a badge for their followers.
I also worked on a new feature earlier in the day, which I wasn't able to complete. It involves a new calculator mode, but I'm not sure when I'll be able to finish it, so I wont say what it is just yet.
Tuesday I worked on ways to make the mix calculator more modular and the new mix mode. The calculator is very complex, so I want to refactor it to be more data driven, but found it was too much work for this time allotment. Then I planned out some ways to utilize public batches.
Wednesday I submitted a Pull Request that adds a Batches list to Mixers' profiles to display public batches. I also restyled the way batches display to make some slight improvements and added a Mix button to both the My Stuff batches and profile batches, which allows you to mix that batch [again].
Thursday & Friday I worked on a data expansion project we are integrating into ATF
Batches on All the Flavors are the result of mixing a recipe. They are an optional last step (Create Batch button), but they are useful snapshots of a recipe's history, and they provide the utility of updating Stash amounts. One of my goals is to make the batches more important and have more utility. The first step in that was to allow batches to be public, which has partially been done, but there isn't a public directory of batches, you have to have a link to find it. Now I am working on allowing you to remix a batch. I'm still working out the exact details, but the goal is to allow you to just go to a batch, click Remix, and do it over again. It's currently functional, but it's not using all of the batch data explicitly, as I'm still working out option for formulations.
This is a pretty big change in the normal workflow and isn't even the end goal. I wont share all of the plans, just yet, but this new feature, combined with public batches, means you can easily share different iterations of a recipe and other users can actually mix them. It also allows you to move recipe development out of the main recipe, because you can edit in the calculator and keep remixing, editing, etc before updating a recipe or needing to make copies of a recipe. It keeps the workflow for a recipe contained to that recipe, without requiring changes that you don't know if you want to keep or not. It also means if you've mixed a recipe and it was later changed, you can still mix the original recipe without cloning it, just remix the batch you mixed before.