philcockfield
commented
2 years ago Note: "Clouds" and "Vendors"
This Vercel API wrapper is a "vendor" but is based on open-standards, and so is a clean abstraction above this, which buffers us from the "Cloud Vendor" (eg. AWS, Azuere, Google Cloud et al) upstream providers.
Current cost: $20 per month (single developer). I actually don't think we should need to scale that at all much - so capping cloud costs, or at the very least, starting with a hypothesis that we've rounded them down, essentially to 0 ("zero")
Task: Write up Documentation: Vercel
Source file (containing sketched out working sample code): tmp.mts
Above usage sample/example code for making a deployment into Vercel (globally cached, public internet addressable) to the "public Web":
Docs: Vercel API https://vercel.com/docs/rest-api
This sample:
Initialize's a client into the running machines filesystem (in this case using our sys.fs.node module that provides a driver to the core sys.fs.
That plugs in an EventBus/Controller set to the code is un-coupled from needing to run in any particular place (ie. can be called from anywhere over an event-bus, even remotely over the network, using the "distributed event-bus". The provides us flexible "remotely addressable" state management.
That FS (the abstract/works everywhere "file system" module return from sys.fs) is then passed in the Vercel API wrapper (concept "vendor")
The vendor in turn spins up an sys.net.HTTP (network) client, and reads/writes of the provided fs:filesystem and manipulates the REST/API of the Vercel cloud endpoint, reading and writing to the API, essentially "syncing" a filesystem into the cloud "deployment object/crate".
That, is the "turing complete" surface area of Vercel's API now wrapped and controlled by us, within our vendor.cloud.vercel module.