@Leo Thanks Leo. Is there pricing available for using the Cache API in a worker? I can't find it.
@Leo Thanks Leo. Is there pricing available for using the Cache API in a worker? I can't find it.
HIt is free. Max size for cached objects is cached by plan
YHi, after discovering JSRPC I have a few questions. I have a few unclear points about it. Is the simple fact of putting functions that extend WorkerEntrypoint enough to create a kind of "sub-function"? In the RPC documentation on Cloudflare, there is mention of Worker A and Worker B with a configuration in wrangler.toml. I don't quite understand how to set this up. Does this mean that I have to recreate a project to create another worker that I associate with my main worker (my API), or have I misunderstood the usage? Another quick question: is it good practice to put all my controllers used for route logic after validating the query format, or do I really need to set aside more demanding functions using RPC?
Dlet me try and answer all your questions in one go haha
- yes, check the docs for how to import and link stuff, should be pretty simple
- yes, jsrpc is between multiple workers - although you can bind a worker to itself, and use a different entrypoint, but that usually has other usecases (that require recursion or another 1000 subrequests)
- I don't actually think there are many best practices around it yet, it's so new; the way I'd structure it is to have a few entrypoints (with route patterns) that do similar stuff (like one worker for main api, and a few more for any special functions such as webhooks if you have them), and pass them through a few other workers that handle CORS, auth, rate limiting, etc, and then business logic; you should be able to use jsrpc for all these, light and heavy tasks alike
YSorry for the complex question ( or rather questions ), it's true that rereading it wasn't easy to understand so gg.
Okay I'm starting to understand in this case. So yeah, if I start with a monorepo with one worker per API function, the repository will start to be titanic with each time the nodes modules to replicate for each worker.
It's actually quite new for Cloudflare but also for me, so I'm trying to figure out what would be the most optimized use case, knowing that reading the documentation, inter-worker requests look really fast, so I'm going to have to find a good use case.
Okay I'm starting to understand in this case. So yeah, if I start with a monorepo with one worker per API function, the repository will start to be titanic with each time the nodes modules to replicate for each worker.
It's actually quite new for Cloudflare but also for me, so I'm trying to figure out what would be the most optimized use case, knowing that reading the documentation, inter-worker requests look really fast, so I'm going to have to find a good use case.
DI wouldn't really go that far as to deploy a worker for each api endpoint - you can also get multiple entrypoints per worker, which might be faster.
From optimization perspective, today, you're still charged for subrequests, which multiply your bill (there was a tweet but I couldn't find it now saying that those would be gone :soontm:), and loading workers into memory might take time, so at one end of the spectrum, you have DX, at the other end you have low cost (today) and tiny speed improvement
From optimization perspective, today, you're still charged for subrequests, which multiply your bill (there was a tweet but I couldn't find it now saying that those would be gone :soontm:), and loading workers into memory might take time, so at one end of the spectrum, you have DX, at the other end you have low cost (today) and tiny speed improvement
YOkay I see, so it would be more for the use of functions that are least used, such as authentication. I'll have to figure out how to do it, but it looks really nice.
Dyeah I think it makes most sense to separate out bits of your application that you want to update independently
YSo we should see more use of JSRPC to make reusable, easy-to-update "micro-components".
Dexactly!
MI am having issues using crypto with pg (hyperdrive)
wrangler.toml
compatibility_flags = [ "nodejs_compat" ]
error attached in the file. As soon as i enable crypto doesnt work
wrangler.toml
compatibility_flags = [ "nodejs_compat" ]
error attached in the file. As soon as i enable crypto doesnt work
message.txt9.81KB
Many help?
MI need crypto function for implement cache aside pattern using kv
Mexample
Dyou can use that just fine with the flag too
Mits not working
Mwhen node_compat = true
MCan i use crypto and pg together?
Mnode_compat = true
compatibility_flags = [ "nodejs_compat" ]
so confused between these two
compatibility_flags = [ "nodejs_compat" ]
so confused between these two
MCloudflare Docs
This example shows you how to connect Hyperdrive to an Amazon Relational Database Service (Amazon RDS) Postgres or Amazon Aurora database instance.
MAs per documentation it says I need node_compat = true
MWhich is not working with crypto
JSadly you can't use
nodejs_compat and node_compatnode_compatnodejs_compat is actually real node.js support for various modules, straight from the runtime. It's the recommended way to do things nowadays.JSadly Hyperdrive requires
node_compatpgpostgres.js with nodejs_compat, but it doesn't have full support with hyperdrive yet, mainly for things like caching.MI just want to use crypto module
MThere is no other way I can do with pg?
MI need that for generating hash and use that for caching the queries using kv
MI appreciate your help.
IIf this is for non-cryptographic purposes you can use
crypto.subtleJust do a
digest using SHA-1
Iexactly this
Ii use these functions to create SHA-256 hash from a string:
MThanks guys!
MI will give it a try
HHey are you sure about this? I'm using the flag and postgres.js with hyperdrive and caching appears to be working (altough there is some other performance issues)
SDoes a call to a RPC function count as an additional request? Or is it "free" to use RPC function within Workers? The docs don't mention this, so I assume it's not being billed. But want to be sure.
HIIRC, a call to function on an RPC Stub is free. A call to a function on a DO/Service Binding Stub is billed
YHi, I have a little problem but I think it's a bug so I'd rather share it. In a dev environment, with one worker communicating with another using RPC, and with an environment variable configuration for dev and prod like this :
My Worker A calling Worker B can't find a worker with the name I assigned to Worker B.
Command that works:
npx wrangler dev -c authentification/wrangler.toml --port 9002
Command that doesn't work:
npx wrangler dev -c authentification/wrangler.toml --env dev --port 9002
By adding the "env" property, it no longer finds the Worker
My Worker A calling Worker B can't find a worker with the name I assigned to Worker B.
Command that works:
npx wrangler dev -c authentification/wrangler.toml --port 9002
Command that doesn't work:
npx wrangler dev -c authentification/wrangler.toml --env dev --port 9002
By adding the "env" property, it no longer finds the Worker
KEnvironments change the name of the Worker
KIf you have
name = "foo" and don't specify a name specifically under env.dev, then that Worker when ran with --env dev is now called foo-dev.K
YOh okay
YMake sense now, thanks
LIs it possible to have a scheduled worker call to a HTTP worker via a binding? All the examples I see mention passing on the
request.url when calling fetch(), which wouldn't exist within the context of a scheduled worker?LAh okay, thanks!
Lis there an expected delay from a request happening to it showing up on the metrics page? 
Ldo tail workers only work for fetch requests?
KShould work for everything - it's the same stuff that powers
wrangler tail