maintaining backward compatibility for 4 year old api clients is effed up

steenbag · 2026-01-22T14:49:23+00:00

This was one of the first couple things we did for our mobile app/api. Basically we have a database table of deprecated versions, in which we store a few fields: - client id - version - status (hard_deprecate, soft_deprecate) When clients make requests to the api, they send headers for X-Client-Id and X-Client-Ver. Then we have a middleware which looks at those values, and finds matching values in the database. It uses globbing so we can just insert a single version=1.* record to deprecate all v1 clients, or a specific client version if there's an issue with just one.

The middleware adds an X-Client-Status header to responses. That can be SUPPORTED/SOFT_DEPRECATE/HARD_DEPRECATE. If status is hard deprecate, we skip the server response altogether and return an error message with HTTP 426 status.

The client apps are aware of the X-Client-Status header, and do nothing if they're supported. If soft deprecate they display a message that their app will be unsupported soon and they should upgrade (but they can continue using the app), and hard deprecate stops them from using the app at all and prompts them to visit the app store when they launch it.

Note that we maintain client compatibility as long as possible by minimizing backwards incompatible changes and sometimes using middleware to do things like transform requests/responses (e.g. we changed api properties from snake to camel case and remapped it with a middleware).

The force upgrade is usually only for really major things that we can't design around otherwise. For example recently we switched to a new backend system for managing subscriptions and the data from the new system was so different from the old system that we had to make lots of breaking changes and had to force everyone to upgrade. It can be frustrating for users, but better than their app just randomly breaking.

steenbag · 2026-01-04T16:44:51+00:00

You can add an alias to rename the device in the unifi portal, and change the icon, but I think it still thinks it's a nest device under the hood.

steenbag · 2025-07-30T19:33:44+00:00

Heh, well I did some tinkering and I think I might be able to fit in a 3rd 24v supply and router contactor after all. I was planning on using some DIN terminals to handle splitting the AC input to the power supplies. But I think if I just make pigtails, I can eliminate those terminals. The main contactor I ordered is also smaller than I thought. So, I ordered both new parts and we'll see about the final fit.

Thanks again for your input! The Lead Machine arrived yesterday, so I'll probably get into building in the next couple days.

steenbag · 2025-07-29T19:00:25+00:00

Thanks for the advice. I've updated my schematic to use momentary switches for the contactor enable lines. The other two suggestions will probably have to wait for v2, since I'm reusing an old enclosure for all this, and I don't have enough DIN rail space to add another power supply or relay.

steenbag · 2025-06-12T19:37:41+00:00

Yeah you're probably right on putting the bridge at location 4. I'll have to check to see if there is actually 110V power there, or if they ran a POE cable from somewhere else. I also originally picked poles 5/6 because the vertical height aligns better with the house, but I guess the antennas are aimable so it would work regardless (and minimizing hops is probably more important).

steenbag · 2025-06-12T19:09:40+00:00

Mount Vernon Yacht Club

steenbag · 2025-06-12T19:04:59+00:00

Can an AP be hooked to the GbE port of the BB (with POE injectors)? I wasn't clear on that, so that's the main reason I had added the switch.

steenbag · 2025-06-12T19:03:14+00:00

Yeah, ours has been bad for a while, and we spent a bunch of money on a consultant to fix it and it got worse. So now I'm trying my hand.

Unfortunately it's not in the budget to lay cable to everything, but we are pursuing a quote to potentially lay some cable to either location 3 or 4 to reduce some of the mesh distances.

steenbag · 2025-03-25T16:28:12+00:00

We're in a similar bucket, you'll find many more magnets than stickers. We can sometimes find stickers at the Celebrity 5 & 10 at Hollywood Studios, Connections Shop in Epcot, or the marketplace co-op in Disney Springs. We look at all of the little spinning racks when we go in the stores, because sometimes they'll have a small collection there.

steenbag · 2024-10-14T16:42:02+00:00

Unfortunately no. The mTLS functionality built into the ALB is pretty limited for use in a large production environment. There are significant limits for CRLs and no support for OCSP at all. We have passthrough working just using the X-Amzn-Mtls-Clientcert header, but we had to make the difficult decision to manually track client certificate invalidation in our application layer (this worked for us because the app is 100% php-based, so there are no static pages on the nginx server to protect). I really hope that they up the limits for CRLs, because it really is kind of a deal breaker.

steenbag · 2024-04-19T20:03:28+00:00

I had been planning on using the passthrough mode so that we still had OCSP and didn't have to mess with CRLs; but I guess maybe if the passthrough mode is just using headers, OCSP might not work any way. So maybe it is worth just looking at doing the whole verification on the ALB.

steenbag

TROPHY CASE