Both CloudFlare and CloudFront use the same principles during deploy and undeploy, and there are some differences between them:
· Cloudfront uses the path pattern (e.g. /login); CloudFlare uses full URL as route, e.g. example.com/login
· One Cloudfront lambda is only associated with one path pattern; one CloudFlare worker might be assigned to multiple routes, e.g. www.example.com/login and example.com/login, since one worker is still built from one Darwinium journey step, so the URL path part keeps the same between the routes.
Undeploy can be taken as a special deployment in that the journey is empty, thus all Darwinium workers will be removed.
Here let’s take Cloudflare as an example.
Darwinium edge deployment read the following from Cloudflare to get all the scripts and routes.
· scripts, and in case it is a Darwinium worker, read the current service binding
· routes
Darwinium analyzes all the routes and associated workers and sets the service binding accordingly. Please note:
· the customer worker can be from the route list (e.g. first-time deployment) or service binding of existing Darwinium workers (e.g. redeploy)
· Darwinium edge deployment won’t read whether there is another service binding on customer_worker_signup because the service binding chain still is kept.
there are following cases with routes between routes of one Darwinium worker and routes of customer worker that have inter-set.
Exact Matching
This includes whether the Darwinium worker has only one route or multiple routes.
· Customer worker customer_worker_signup running on route: login.example.com/signup
· Darwinium worker dwn_worker_signup running on route login.example.com/signup
Deploy
Darwinium edge deployment will set customer_worker_signup as the service binding of dwn_worker_signup, and also move the route login.example.com/signup from customer_worker_signup to dwn_worker_signup. If you check the route of customer_worker_signup, the route part is empty.
Undeploy
Darwinium will move the route login.example.com/signup from dwn_worker_signup to customer_worker_signup and then delete worker customer_worker_signup.
Inherit Matching
· Customer worker customer_worker running on route: login.example.com/*
· Darwinium worker dwn_worker_signup running on route login.example.com/signup
Deploy
Darwinium edge deployment makes it as follows:
· login.example.com/signup dwn_worker_signup set service binding as customer_worker_signup
· login.example.com/* customer_worker_signup, no other changes
with this, customer worker still behave all route matching, e.g.
· a request coming with login.example.com/signup, both the Darwinium worker and customer worker will be processed
· a request coming with login.example.com/hello, the customer worker will be triggered
Undeploy
The darwinium worker will be removed including the route login.example.com/signup.
Combination of Exact Matching and Inherit Matching
Since one worker might have multiple routes, it is possible to have:
· Customer worker customer_worker running on routes: login.example.com/anything/* and www.example.com/anything/foo
· Darwinium worker dwn_worker planned to run on routes login.example.com/anything/foo and www.example.com/anything/foo
Deploy
will analyze the route and match based on the route one by one, the result would be:
· Customer worker customer_worker running on routes: login.example.com/anything/*, route www.example.com/anything/foo is moved to Darwinium worker
· Darwinium worker dwn_worker runs on routes login.example.com/anything/foo and www.example.com/anything/foo
with this, the behavior of the customer worker is kept after the deployment, and the Darwinium worker runs on expected routes too.
Undeploy
it moves route www.example.com/anything/foo back to the customer worker and deletes the Darwinium worker, and thus route login.example.com/anything/foo is removed, but it was covered by login.example.com/anything/foo as before the Darwinium worker was deployed.
One principle of Darwinium deployment archives is that: it keeps the customer’s worker behavior (as per worker route mapping) unchanged, while the Darwinium worker covers the route that is defined in the journey. If Darwinium deployment finds it is unable to do it, it’ll report an error.
The following cases are most because Darwinium workers want to be deployed on a route that has a bigger scope, and the Customer’s worker is part of them.
Darwinium Worker is skipped
· Customer worker customer_worker running on routes: login.example.com/anything/foo
· Darwinium worker dwn_worker planned to run on routes login.example.com/anything/*
In this case, Darwinium edge deployment cannot put customer_worker as service binding of dwn_worker because it’ll put customer worker triggered on an unexpected route, e.g. login.example.com/anything/another
The customer can define a step on /anything/foo to cover it and this becomes an exact matching case.
Route conflicted
· Customer worker customer_worker running on routes: login.example.com/anything
· Darwinium worker dwn_worker planned to run on routes login.example.com/anything and www.example.com/anything
Similar to the previous case, Darwinium edge deployment cannot put customer_worker as service binding of dwn_worker, because it’ll put the customer worker on an expected route www.example.com/anything
Information
If you deploy your worker with other tools, e.g. wrangler. they might cannot use the original routes because that route might be moved from customer worker to Darwinium worker.
Wrangler reports an error when trying to move a route from another worker (e.g. dwn_worker) to a new customer worker (e.g. customer_worker, it’s a different worker name), they should check the current routes for that worker and just assign that routes, the current route may be empty (because of exact matching).
The service binding itself is a reference, so when the customer updates the service binding worker, it’ll take effect.
If you add a new route to an existing or a new customer worker, it is suggested to redeploy the Darwinium journey to detect any possible risk.