Building a backend API with workers

Hi,

I feel I should have managed with the docs but I have been unable to implement the scenario I have in mind so I turn here and see if someone can help me.

I want try out building a backend API on top of workers. For example to support a mobile application or similar.

I’m a bit worried that as the functionality grows I might not be able to fit everything in one worker which has a standard limitation of 1 MB.

I have an idea of how to design this (might not be the optimal one, please feel free point me in other directions if you like but I also want to try this one out).
Here is what I want to achieve.

Requests:
GET api.mydomain.com/customer
GET api.mydomain.com/customer/1
POST api.mydomain.com/customer
goes to worker1 where I have internal routing with Hono/Itty, similar.

Requests:
GET api.mydomain.com/product
GET api.mydomain.com/product/1
POST api.mydomain.com/product
goes to worker2 where I have internal routing with Hono/Itty, similar.

On top of this I want →
Requests:
GET api.staging.mydomain.com/customer
GET api.staging.mydomain.com/customer/1
POST api.staging.mydomain.com/customer
goes to worker1-staging instead

I have already registered a domain here at Cloudflare.
I’m still experimenting in the free plan.

This is what I think I need to utilise but I haven’t found out how.
https://developers.cloudflare.com/workers/platform/routing/routes/

Any help appreciated.

This looks very much like what I try to do:
https://developers.cloudflare.com/workers/platform/environments/#introducing-environments

So in essence I have deployed this with a few things replaced with dummy values in my example.

name="my-worker-dev"
main="src/index.ts"
account_id="123456"
route = "api.dev.mydomain.com/*"
vars = { ENVIRONMENT = "dev" }

compatibility_date = "2022-10-12"

[env.staging]
name = "my-worker-staging"
route = "api.staging.mydomain.com/*"
vars = { ENVIRONMENT = "staging" }

[env.production]
name = "my-worker"
route = "api.mydomain.com/*"
vars = { ENVIRONMENT = "production" }

This results in having this table in Workers Routes section:

Route	                    Service	            Environment	
api.dev.mydomain.com/*	    my-worker-dev	    production
api.mydomain.com/*	        my-worker	        production
api.staging.mydomain.com/*	my-worker-staging	production

Still if I make a GET to api.mydomain.com/hello I get nothing in return even though it should respond with Hello world to any request.

Instead I get a Error: getaddrinfo EAI_AGAIN api.mydomain.com which indicates some DNS issue I assume.

In the end this might not be related to worker routes but instead my domain?
I haven’t configured anything in there and something tells me I need to setup an A record for root domain?
If so, what IP should go into the value? My workers are not running on a dedicated IP address, are they? As you can tell, DNS and routing is not my strong skill.

Ok. I think I managed to get it to work now.

For any future reference, if someone else is struggling with the same problem.
I setup A records in the DNS configuration for root and all subdomains.
I went with one level subdomains only since that seemed to play best with TLS certificates out of the box.

A api 192.0.2.1 proxy
A api-staging 192.0.2.1 proxy
A api-dev 192.0.2.1 proxy
A @ 192.0.2.1 proxy

That seems to work well and solves my current use case.
I’m not sure what 192.0.2.1 really means in this context but that seemed to be best practice.
https://community.cloudflare.com/t/setup-workers-on-personal-domain/88012/5

You seem to have got it working so you might not need this, but yes how Workers originally worked was they were not the origin. They would always run before the origin (the A record or CNAME). And hence yes, you needed to add a DNS record (orange cloud/proxied). Its value could be presumably anything (e.g your 192.x), as it did not matter. Since your Worker would handle the request to /*.

Cloudflare have since added custom domains and the Worker can be the origin. So they add the DNS records for you. So this may be of interest: