https://discord.cloudflare.com logo
Join Discord
Powered by
# functions
  • g
    what got me asking about that was how pages functions works today under the hood.
  • g
    is that a generalizable model, I suppose. 🙂
  • g
    I feel like I'm generating out some big isolates locally, but maybe not.
  • w
    assuming I have a pages function at 
    functions/api/lookup.js
    I could request it from 
    /api/lookup
    , right?
  • g
    Oh, no. Normal Workers are very much their own thing, and they aren't combined in any funky ways whatsoever.
  • g
    đź‘Ť
  • i
    Technically 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.
  • g
    OH 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.
  • w
    Can you write a normal function that adds content to an existing static page or is that purely the domain of an HTMLrewriter
  • w
    Because like this weather endpoint is great, but what if I want to put it into a page
  • i
    The 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.
  • g
    It's what HTMLRewriter was built for, but you can definitely do it yourself if you prefer:
    Copy code
    js
response = await fetch()
text = await response.text()
text += '<h1>Hello</h1>'
return new Response(text)
  • i
    -> HTMLRewriter.
  • g
    HTMLRewriter will give you better performance.
  • i
    Also, note to everyone. The employee here is @User, I'm not 🙂
  • w
    That makes sense, so do I basically just create a tag with a name and some filler content that gets replaced basically.
  • g
    I'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 🙂
  • w
  • g
    totally, 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)
  • m
    I wasn’t aware that was needed… back to the docs I go! Thanks for the advice.
  • g
    the 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.
  • w
    So the content that is currently in the weather.JS file, I would like to put it onto a specific page of my website (index.html): https://www.chrisfnicholson.com
  • g
    @User form submitted (among many others), thank you for answering on your weekend.
  • g
    If your site has static assets, and you're wanting to deploy everything together, then full-stack Pages is what I'd recommend going with. If it makes sense for your application, stick with the 
    functions
    dir handlers. 
    _worker.js
    is a primarily an escape-hatch for either people with existing Workers, or framework authors.
  • w
    So that at the bottom there it would just say the temperature in Denver is 51 degrees.
  • g
    @User that makes sense, thank you.
  • i
    The docs for 
    wrangler@beta
    aren't great, but it's 
    beta
    after all. Look at @User's stream at https://twitch.tv/gregbrimble
  • g
    If you need stability though, Workers have been around since (I think) 2017, so are a lot more mature than the beta Pages functions 🙂
  • g
    npx wrangler pages dev --help
    should give you all the options you have available 🙂
  • g
    oh yeah, that I'm familiar with! just for the first time this has all come together in a way I think we can fully put something together and drop a crap ton of tools. nice work.
1...789...392Latest