"Actually needing to update the controllers to update CSS for the main app is kind of crazy."
The controllers don't return CSS: they return HTML fragments. I chose not to include CSS in the response because of the reasons you're thinking, plus the servers shouldn't really care about how their state looks.
The admin app styles the custom tags. I also figured this would make it easier for them to contract out changes to that app.
"the hard parts are the limited resources of the controllers and a need for high versatility for the rooms."
Yep! I didn't cover it in the article because it didn't fit the theme, but another challenge was the single execution thread. When you have a bunch of rooms on the same controller, you want to avoid blocking that loop, which is what the built-in Arduino delay function does. I came up with a timer system for non-blocking time-based triggers.
"it would be easier to change the single client versus multiple servers" + "trivially implemented on the client"
It would be! That said, adding a new feature requires implementing that feature on the server, so requiring an additional change on the client is actually more work.
For example, one of the rooms in the house just installed house lighting to help with resetting rooms between guest groups. One one of the controllers has this.
Once I implemented the hardware logic, I updated the server's state response to include a new button that pointed to a new house lights endpoint. That button immediately showed up in the admin app. Super fun DevEx, and this is what I meant by minimize future work - minimal work to expose new room functionality.
"My assumption rests on the idea that changing the client is easier though"
Think about the number of changes required to implement the feature end-to-end. You're right that updating N controller C++ templates for a button is wild, but that's not the entirety of the work. Those controllers already needed to be updated to handle what that button does. Adding the button itself is minimal work (copy-paste, really) in comparison to the feature work.
"I probably would have returned a blob of data from the servers"
That would certainly work, but adding new functionality to the rooms would require changes on the controllers (implementing the new JSON API) and on the client (calling, handling, and rendering the new feature). I wanted to minimize development time for myself now and make it possible to add new features using only C++ later.
Having the server declare the supported actions (not all rooms support the same features) and how to invoke them accomplished that. This independent evolution was a big reason why I leaned into HATEOAS.
"wouldn't have figured that doing handlebars style html templating is a good use of resources"
I didn't do a size comparison between the HTML fragment and a JSON response. Next time I'm at the house I'll come up with some measurements and add it to the article - I think it's interesting. That said, the performance was more than enough for the business and each of the controllers still had plenty or RAM and Flash Memory available, I didn't need to optimize this area. If I was going to, I'd want to avoid going through the buffer so many times.
That said, the simplicity and robustness of the HATEOAS approach were the main goals. I wouldn't use it for something like high-frequency trading where every byte matters.
I actually can't find a source for the acronym's origin. The full phrase comes from Roy Fielding's PhD Thesis, "Architectural Styles and the Design of Network-based Software Architectures":
https://ics.uci.edu/~fielding/pubs/dissertation/fielding_dis...
I'd love a source on the acronym if someone has it.
"Actually needing to update the controllers to update CSS for the main app is kind of crazy." The controllers don't return CSS: they return HTML fragments. I chose not to include CSS in the response because of the reasons you're thinking, plus the servers shouldn't really care about how their state looks.
The admin app styles the custom tags. I also figured this would make it easier for them to contract out changes to that app.
"the hard parts are the limited resources of the controllers and a need for high versatility for the rooms." Yep! I didn't cover it in the article because it didn't fit the theme, but another challenge was the single execution thread. When you have a bunch of rooms on the same controller, you want to avoid blocking that loop, which is what the built-in Arduino delay function does. I came up with a timer system for non-blocking time-based triggers.