For a little behind-the-scenes, what we’re doing at the moment is just compiling the functions direc
For a little behind-the-scenes, what we’re doing at the moment is just compiling the functions directory into an _worker.js.
GAnd that gets invoked for all incoming requests.
G@gregbrimble I sent a support req, we're about 99% sure of migrating almost all of our backend over to CF + CF pages and moving a bunch more into durable objects, we're super thrilled but getting hit hard by that req limit at the moment. looking at doing some more clever things with setting up another service, but need service bindings too. no worries today, but I'm working on machinery.
GAH!
JI'd think that only requests to matching routes would count as an invocation, would this behavior change when pages functions leaves beta?
Gso there's no functional difference between _worker.js and all of the functions
IYeah, you can see the file when building locally 
IDX wise yeah, but functionality apparently not.
Gthat's good to know, I was trying to automatically strip out our SSR into individual functions.
Gcloth?
Jah didnt see that message
GThis Google form is the best place for requests to raise that limit: https://docs.google.com/forms/d/e/1FAIpQLSe4N0BjIxu9AuissCAtYjXUovViXmdx2zopjzASaJi_SImJsw/viewform?usp=send_form
Appreciate you trying out Pages and functions!
Appreciate you trying out Pages and functions!
Google Docs
If you have hit your limit for invocation requests while deploying your functions on Cloudflare Pages, you can submit this form to our team to learn more about your use case. Please provide the information below in case we need to chat with you more about raising the limit.
Please note: this limit increase is only applied to Functions deployed...
Please note: this limit increase is only applied to Functions deployed...
G@gregbrimble perfect, one form I hadn't filled out yet. 
GWe might change it, so don't rely on this behavior, but yeah, they're pretty functionally similar at the moment.
functions gives you simple routing behavior and an arguably easier API, but they boil down to the same thing at the moment.G@gregbrimble Does the separated Routes -> workers feature do the same thing functionally as well?
Gi.e. is there an optimization path to be had today on my end?
GAbsolutely. But bear in mind folks, that this is no worse than what Workers Sites does today. We'll absolutely be trying to figure out when we can know the request isn't anything functions-y, but we just don't have the answers right now.
Jmakes sense
IYou mean deploying a separate Worker?
GNormal Workers will only be invoked if the incoming request matches the route you set.
GBut seriously, if you're trying to use functions and are concerned about that limit, we'll just raise it for you!
GDefinitely don't want that being a concern for you trying out functions and giving us vital feedback
Ger, to be a little more specific (thank you for answering on your weekend!) - with regular workers Routes, do all of those, from a "total size of isolate" perspective get compiled down the same way? and even with the goal to shrink cold starts, is there a benefit today to, with multiple routes, splitting out those workers?
Gwhat got me asking about that was how pages functions works today under the hood.
Gis that a generalizable model, I suppose.
GI feel like I'm generating out some big isolates locally, but maybe not.
Jassuming I have a pages function at
functions/api/lookup.js I could request it from /api/lookup, right?GOh, no. Normal Workers are very much their own thing, and they aren't combined in any funky ways whatsoever.
G
ITechnically it's the opposite, the more you combine, the less chances the Worker is cold. But cold starts aren't really that big of an issue on paid plans, if at all.
GOH that's a fair point. and yeah, but as we're looking at moving over, we're pulling in some large WASM bits - hopefully eventually we can drag those out from R2, but we're early in this process.
IThe optimization is, the bigger it gets, the more time it takes to parse and execute (not much, it's still V8 and it's very fast), but a 1kB worker vs. a 1MB worker has different parse times.
GIt's what HTMLRewriter was built for, but you can definitely do it yourself if you prefer:
I-> HTMLRewriter.
GHTMLRewriter will give you better performance.
IAlso, note to everyone. The employee here is @gregbrimble, I'm not
GI'd be happy to chat about how best to use HTMLRewriter if you've got a specific example of problem you're trying to solve
Gtotally, I'm trying not to use the embedding of v8 we've written at my startup unless it's on our clients' hardware (so basically, move our backend over to workers if we can), i've been deep in this "hell" (not really hell, but it's intricate obviously)
Gthe clarification there suggests though for us I should have a separate API set of workers from what we would do with pages for the auth/etc parts of the service.
G@gregbrimble form submitted (among many others), thank you for answering on your weekend.
