Compute Lifecycle

Probably a stupid question but is there any description of the lifecycle of a compute service? Specifically (I’m using Go) when does the main() func get called?

The question relates to how can I reduce my reads to Secret Store and Config store - could I only call them during the main fun and not within the fsthttp.ServeFunc handler. If I can, then what would happen if the secret (For example) was updated?

Additionally, is there any way of limiting where Compute runs, particularly if I don’t want it to run outside of my country for compliance reasons or would I need to front it with a CDN ?

Hope that makes sense

The Compute platform instantiates an instance of your service when a request arrives for the service; as a result, the main function is invoked to handle that service, and when it exits the instance is destroyed. There is no way at this time to persist data in memory across requests, each request gets a fresh copy of the service (and in fact this is part of the design of the platform, to ensure that no data can ‘leak’ from request to request).

As far as controlling where the service runs, one option is to use Fastly Deliver with shielding (choosing a shield in the necessary location) and then have that Deliver service forward the request to Compute; it will (in almost all cases) be handled by the Compute platform in the same POP that is handling the Deliver request. If you need something more secure than that (for legal compliance reasons like GDPR or similar things), talk to the Fastly sales team about your needs, as we may be able to offer a solution intended specifically for that purpose.

@kevin.fleming brilliant, thanks for the detailed response, this makes sense. I just wanted to make sure I wasn’t missing a “trick”, although persisting would have presented me with other issues in terms of updates to config.

thanks also for the details on location, as it happens we currently use your CDN and Shield for other traffic so I think can easily create a new service to “front” the compute.

thanks again for the fast(ly) response