Yeah, not sure how ENT is handled for Pages... there's no set values on the pricing docs. So maybe t
Yeah, not sure how ENT is handled for Pages... there's no set values on the pricing docs. So maybe talk to your account manager? 
IIf I had one ahah it's the MVP account!
GWe can probably do something for you there. Definitely seen concurrent builds on my magical employee account, so there's probably some setting somewhere we can flick for you if you've got enterprise.
WCloonan should be able to do it :p
GI'll chat to Nevi next week.
Jmagical employee account?
Wgreg while you're at it, feel free to increase mine 
II'm gonna try, but I'm gonna give @gregbrimble a chance ahah
WFree plan but I'd like 3 concurrent builds, it would be helpful 
GIHey, buy the Enterprise plan first.
WAh yeah let me just spend 5k 
WFor my site which has saved me like 9 grams of carbon
Jdang it
JPhiladelphia is a few hours away
WWhy is that my 3rd best reply...
GWe are now hiring remote roles in countries across North America, Europe, and Asia
Joh cool, seems like the site doesn't support filtering for remote roles
Joh my eyes
Ji didnt see it
J
J
GEhh, feel free to apply to any job and just start the conversation about location with the recruiter or your hiring manager.
GIf it works with the team (and they're legally able to), they'll consider remote for all roles.
Jthis all sounds cool but I'm not looking for a job any time soon
Jbut ill be looking soon enough
GAh, sorry, just add the
asyncexport const onRequestGet = async ({ request, next }) => {
KThat is if you use the cache api on a function/worker
IAm I correct in saying that
@sveltejs/adapter-cloudflare for cloudflare pages generates a _worker.js file, which means every page request is caught by the worker and counts towards my function requests which will eventually be billed?
Kafaik, yes
IYes. Note that, as was said above, currently every method to add functions boils down to creating the
_worker.js file, so it’s the same behaviour regardless.IAhh I see, thanks!
GonRequestGet will only respond to GET requests whereas onRequest will respond to all requests. Rest of it is just down to personal preference though. Should be functionally identical.Ki imagine so
GThere is no non-local
wrangler pages dev at the moment.GWe’re still thinking about it. What would you expect
npx wrangler pages dev --remote to do?Kjust to be clear, it's local only atm, right?
GYes.
Gwrangler pages dev is entirely local. No builds are used when you’re testing with wrangler pages dev.Wrangler let’s you test Workers locally or remotely. We don’t have a remote equivalent for Pages yet.
I was just wondering what you thought a remote version might look like. No biggie if you don’t have any thoughts on that. I was just curious
