When to choose edge computing and when not to
Edge computing is marketed as speed. The speed is real, and it comes from one thing: your code runs close to the user, with no server you operate.
When it works in your favour
The ideal case is a site or system with many reads and a reasonable volume of writes, which describes most business systems. It also suits you if you do not want to run servers at all: upgrades and security patches stop being your job, and there is no capacity to reserve ahead of demand. A geographically spread audience strengthens the case further.
The constraints I actually hit
The first was the missing filesystem. You cannot write a temporary file; everything lives in memory or in external storage.
Then the execution time limit. Long tasks do not fit, so I split them and pushed them into scheduled jobs.
The runtime is also not a full Node environment, and many libraries do not work in it. Check before you build, not after.
Even scaling is measured differently. Instead of asking how many servers you need, you count requests and the milliseconds each one takes.
The trap that cost me time
Purging the cache is not always yours to do. In my setup, cache purge permission is deliberately withheld, so after a deploy you may get the old version twice and the new one on the third try.
That pattern nearly convinced me, twice, that a deployment had failed. The correct procedure: add a random query parameter when checking, and never judge from a single attempt.
When not to choose it
Keep heavy long processing away from it: video encoding, training, large analysis. A core library that will not run in the environment is a signal to change the choice, and to do it early; working around it costs more than it saves. Very heavy concurrent writes to the same row are also a poor fit.
Related reading
Tell me what you want to build. Your first 15 minutes of consulting are free.
Book a consultation