Ben

Set expectations low for the first hour. The small models are noticeably worse at the first suggestion and fine once you've given them a file's worth of context.

It is a node app with a couple of native deps so I suspect it is the much worse case. Timing it now.

That is the most common cause of this exact post. Tutorials age badly and the SDK keeps absorbing things.

i solved this the wrong way first. added a cron to ping the function every few minutes, which kept the function warm all weekend and made no difference at all on monday morning, because the ping did not touch the database. the warmer has to exercise the slow dependency or it is just burning invocations.

Mild pushback on the enthusiasm for dev clients as a lifestyle. If your app genuinely only needs modules that ship in the SDK, staying on Expo Go is faster and simpler and you should not move just because a thread told you to. Check whether the scanning functionality you need exists in the SDK first, because there is a decent chance you added a third party lib for something already supported, and then you have taken on a rebuild cycle for nothing.

The licence thing matters less for a solo dev than people imply, but read it yourself rather than trusting either side of that argument.

Tried Nomad for exactly this situation about a year ago and went back to compose after two months. Getting a job running was genuinely pleasant, the HCL is nicer than YAML, and dev mode meant I was up in an afternoon. What killed it was that everything around it became my problem: secrets, the reverse proxy integration, volume handling for the stateful bits, and an upgrade of the cluster itself that I did on a Sunday for no user visible benefit. Compose plus a fifty line deploy script now does what I need and I have not thought about the infrastructure in months.

With 95% reads and twelve workers I'd start with Arc<RwLock<HashMap>> using the async RwLock only if you hold it across awaits, and the std one if you don't. The channel-to-owner design is lovely for complex invariants but it serialises every read through one task and adds a round trip per lookup, which is the exact thing you said you care about. Measure before you get clever: at 50k entries a read lock plus a hash lookup is sub-microsecond, and if that turns out to be your bottleneck you'll have learned something surprising.

Fair, though you can also express that as a single write-locked method on a wrapper type rather than a message. Same atomicity, no round trip.

Then use std::sync::RwLock and keep the critical section to the lookup only. Async mutexes are slower and you don't need what they offer.

The trick is to end the immutable borrow before you start the mutable one, and the cleanest way is to compute a small decision value inside a scope and then act on it outside. Something like let should_merge = matches!(events.last(), Some(e) if e.can_merge(&item)); then if should_merge { events.last_mut().unwrap().merge(item) } else { events.push(item) }. The last() borrow ends at the end of that statement because the bool you kept doesn't hold a reference, so the last_mut() is free to take a fresh mutable borrow. No clone, no unsafe, and it reads fine.

It moves the same conflict to runtime, where it becomes a panic instead of a compile error, and it costs a check on every access in a hot loop. There's no aliasing need here, so it's strictly worse than restructuring two lines.

Both can be true. Give a band on commodity work to filter fast, and stay quiet on anything where the value is unusual. The mistake is having one rule for both.

Worth noting the licence applies to Docker Desktop, the packaged app, not to the engine or the CLI. Several people on our team moved to alternatives that run the engine in a lightweight VM without Desktop, and that sidesteps the question entirely on Macs. It is not free, it costs you some polish and about an afternoon per developer, and if your team is not comfortable in a terminal it will not be popular. For a twelve person agency that is probably not worth doing purely to avoid a licence you may well not need.

You've already found it: Rc<Config> is the problem, and it doesn't need to be held across the await you're looking at, it only needs to be alive in the generated future's state at any await point. Swap it for Arc<Config> and the error usually vanishes on the spot. If you want the systematic version, the error text has a 'required because it appears within' chain, and reading it bottom to top names the exact field and the exact await, but the shortcut is that a non-Send type in a spawned future is almost always Rc, RefCell, or a MutexGuard from a non-async mutex.

Worth asking whether you want over the air updates at all on an app this size. Four thousand users and one maintainer is exactly the profile where a bad bundle at 11pm is unrecoverable without a store release anyway. I run store releases only on two of my apps now and the reduction in moving parts was worth more than the speed.

Your reading is right and it matters less than you think. The docs are upfront: limits are local to the Cloudflare location your worker runs in, there's a separate limit per key per location, and the whole thing is described as permissive, eventually consistent and deliberately not an accurate accounting system.

So yes, in theory an attacker distributed across twenty locations gets twenty buckets. In practice the person hammering your reset endpoint on a Tuesday evening is coming from one place, and the binding stops them with about six lines of config. The other constraint to know before you design around it: the period must be either 10 or 60 seconds. Nothing longer. If you wanted "5 resets per hour per email," that binding cannot express it.

The follow-up question drill is the one that separates people. Most conversations are two people taking turns to talk about themselves, and being the person who asks a second question about the same subject makes you memorable for no additional charisma.

fn matching(&self, kind: Kind) -> impl Iterator<Item = &Record> + '_ is what you want. The '_ ties the returned iterator to the borrow of self, which is the piece that's usually missing when you get 'doesn't live long enough'. Inside, self.records.iter().filter(move |r| r.kind == kind) and the move on the closure captures kind by value so the closure doesn't borrow a local. Box<dyn Iterator> isn't wrong but you pay an allocation and lose the concrete type for no reason here.

It can see it, it just won't assume it, because for impl Trait in return position the captured lifetimes have to be spelled out or elided explicitly. Newer editions loosened this, which is why half the examples you find online don't have it.

Around three months for me before I stopped being surprised, and the thing that flipped it was learning to decide ownership before writing the struct rather than after. Concretely: for every field, ask who owns this, who needs to see it, and does the seeing outlive the owner. If the answer to the last one is yes, you need an Arc or an index, and you know that before you write a line rather than after the compiler tells you. Once the design carries the answer, the errors mostly stop.

Strongly agree with this as a learning strategy. The compiler is teaching you a real constraint but you don't have to solve it optimally on day one.