👍

And I got this backwards as well. We evaluate top-down for modules and bottom-up for middleware.

Hi, I made a basic function that allows to connect via websocket but I'm actually not sure how billing is handled in this case. Where can I find out what costs I can expects for this? The only thing I could really find was this: https://blog.cloudflare.com/introducing-websockets-in-workers and it doesn't actually say what the costs are nor does it apply to CF Pages Functions

There is no cost model in Functions at the moment since it's still in beta - the only limit is the 100,000 requests per day.

Once Functions are GA, billing will be similar to Unbound Workers

But eventually once Functions billing comes out it will be pricing similar to a Worker.

And Workers bill for the entire time the socket is open in duration.

So if the socket is open 30 seconds you will be billed 7.5GB-seconds of compute time.

Ok new question. I have Cloudflare access in front of my application. Any good way to mock it with miniflare?

Depending on what kind of authentication you are using, you might be able to use

miniflare

to simulate Access with a Worker, but it would take some work.

Not too familiar with Cloudflare Access, how do you usually check the "logged in user" in the worker? Is it a property on the incoming

cf

object or something?

is there an estimate as to when Functions will go out of beta? the 100K invocations limit is a bummer having to ask for increases makes it out of reach for me, needs to scale automatically

if you have more traffic than that already, you could just submit a request now

no, I want billing in place

well you don't want to use it in beta right?

i would say there's a decent amount of time till it goes into ga

the pricing would be, or should be, similar to workers pricing

which is visible rn

I'm okay with beta, as long as I can pay for it, and it scales automatically

ohhh, I see maybe I should look at the workers platform then which is already out

it's the same platform, just functions are more tightly integrated with pages

yeah, I love how functions can be deployed side by side with static assets, and the assets not needing to go into KV

(they do go to KV, just that you don't need to manage it yourself)

Hey guys! Function beta means, for example, that it can be stop working at any time? for simple use cases that works just fine in Workers one might well expect them to work as well in Functions? Im planning to deploy in Pages and would like to have workers code in the same place. What would be recommended? (simple app but in production)

it won't stop working

Beta means they should work (and in fact I've never seen them go down). There are no SLAs of course 😅 and you're limited to 100k requests per day unless you request an increase, but they're production-ready (I use them in prod).

Just won't have billing and a few features yet

Thank you 👍 .... im going to use Functions... nice syntax by the way.. regards

thanks for your clarifications btw, @kavinplays! sorry, I forgot to thank you :' )

Playing with Pages Functions. If I have a simple

onRequestGet

on a route that hits the

index.html

, but I then call

await next()

to retrieve say

test.html

, if I then return the result of that

next

call, I appear to be 301d to

/test

. I think I'm missing something for how this works - I'm essentially trying to get a different

html

file if there's a particular query parameter, but I keep getting weird 301s, at least with

wrangler@beta

0.0.26