well then u should send him this `Please keep the discussion here friendly, if you want help.`
well then u should send him this
Please keep the discussion here friendly, if you want help.
FAgain. If you want help, stop fussing. If you think something needs moderation, call @Community Champion
0you are the one fussing right here
0whats wrong
DMind your language
0because i can?
ILet's stop this entire discussion here, it's not productive and is getting to be uncivil.
0or because you can?
0smh
BDo you guys know what to make of “error:netdev is not set”
JIn what context? Can you share any more info and where you’re seeing this error?
SHi everyone. I'm evaluating Cloudflare Workers for my next project. I built a simple PoC using Hono, connecting to TursoDB and deployed to Cloudflare Workers using Smart placement.
I'm observing a very long TTFB on cold boots (up to 8s) and warm boots (up to 800ms, kinda deal breaker to me). Considering this is a very simple API that has no other logics other than querying a data with 1 row, is there is any way I can speed up the my workers? After they are warm, I can get around ~21ms latency.
Thanks in advance
I'm observing a very long TTFB on cold boots (up to 8s) and warm boots (up to 800ms, kinda deal breaker to me). Considering this is a very simple API that has no other logics other than querying a data with 1 row, is there is any way I can speed up the my workers? After they are warm, I can get around ~21ms latency.
Thanks in advance
BI’ll probably make a post if I’m gonna give context.
BHard to say without seeing the project, but to eat up 8s it must be doing some initialisation with external API calls? Or is there some cold start or Turso's side related to accessing Turso from different regions (I haven't used Turso so I don't know how it operates).
From all my experience, I can reach workers on the far side of the world consistently around ~200ms, cold start or not.
So it could be related to doing some expensive (long running API request) initialisation on each worker request? If so, you could try firstly "caching" that initialisation in global variables so it is shared between requests to the same worker instance. And secondly caching initialisation responses locally in the datacentre using the Cache API so it can be retrieve very quickly even for a new worker instance.
However if your code is indeed just a "simple POC" with no such long running initialisation then I've got a feeling that the delay may be on Turso's API?
From all my experience, I can reach workers on the far side of the world consistently around ~200ms, cold start or not.
So it could be related to doing some expensive (long running API request) initialisation on each worker request? If so, you could try firstly "caching" that initialisation in global variables so it is shared between requests to the same worker instance. And secondly caching initialisation responses locally in the datacentre using the Cache API so it can be retrieve very quickly even for a new worker instance.
However if your code is indeed just a "simple POC" with no such long running initialisation then I've got a feeling that the delay may be on Turso's API?
MDoes anyone have a recommended “pattern” for updating API shield schema validation during the deployment process of a Worker? Do you just upload a new version of the OpenAPI schema each time via API?
Interested to know what process (if any) others might use
Interested to know what process (if any) others might use
Janyone familiar with creating Dynamic image with honojs. I tried with svgs but on storing it on db it gets as a HTML Document (.svg) I want it directly as a png or jpg not any html document.
Sharp is one option for converting it but its not compatible with honojs. Any ideas on this?
Sharp is one option for converting it but its not compatible with honojs. Any ideas on this?
Si guess you're right. i quickly instrumented my app and saw Turso DB was slow for the first few initial requests. thanks @Brett Willis !
ISharp would be compatible with Hono, it just might not be compatible with Workers. Have you tried the Sharp WASM version?
JI found one wasm based lib @resvg/resvg-wasm to convert from svg to png. but the issue with that is its not rendering the text. gettign a full empty image with just background
<svg width="600" height="400" xmlns="http://www.w3.org/2000/svg">
<style>
.text { font: 24px Arial; fill: black; }
</style>
<rect width="100%" height="100%" fill="white"/>
<text x="50" y="100" class="text">${text}</text>
</svg>
import { Resvg, ResvgRenderOptions, initWasm } from '@resvg/resvg-wasm';
import wasmModule from '@resvg/resvg-wasm/index_bg.wasm';
export const generateImage = async (text: string) => {
console.log(text, "this is the text");
const svg = <svg width="600" height="400" xmlns="http://www.w3.org/2000/svg">
<style>
.text { font: 24px Arial; fill: black; }
</style>
<rect width="100%" height="100%" fill="white"/>
<text x="50" y="100" class="text">${text}</text>
</svg>
;
try {
await initWasm(wasmModule);
} catch (error) {
console.error('Resvg wasm not initialized');
throw error;
}
const opts: ResvgRenderOptions = {
background: "white", // Optional: set background color
fitTo: {
mode: "width",
value: 600, // Adjust based on your needs
},
font: {
loadSystemFonts: true, // Disable system fonts if you're using custom fonts
},
};
const resvg = new Resvg(svg, opts);
console.log(resvg, "this is the resvg");
const pngData = resvg.render();
const pngBuffer = pngData.asPng();
return pngBuffer;
};JI would guess that the fonts being missing are your issue. You may need to bundle the fonts up yourself and then pass them in via
where
where
fontBuffer is a raw ttfJExample from their tests: https://github.com/thx/resvg-js/blob/97944eb0117f3d2135abe4d18be6c467103e2caa/__test__/wasm.spec.ts#L229
J(you won't be able to use
fs
Eu can store it as blobs
Jyeah it worked. Stored the font in the cloudflare storage and fetched it from there and converted to ArrayBuffer and used it.
SHow do you handle multiple workers running on localhost when you want to make requests from the front end using a single URL (localhost:8787)? Once deployed, it’s possible to set up a route for each worker, but how do you manage this setup locally?
JThe resvg package is big And now I have issue with deployment
JI am on free plan
Mhi, is it a performance problem if I use a "Cloudflare Snippet" to route requests to my worker instead of directly using worker routes? The problem I have is that I'd need so many different worker routes to get it to match everything it needs to match on /mypath because /mypath has to support various cultures in front: /(en|fr|de)/mypath <--- and this regex isn't allowed in worker routes
Jwhat's the recommended way to run a one off script locally?
Jtsx chokes on this import
import { DurableObject } from "cloudflare:workers";Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. Received protocol 'cloudflare:'
SMy image-transforming worker just stopped working. Returnig response ignoring cf: image: {width: 300, height: 300, fit: 'cover', draw: null}.
Is anyone familiar with changes? I had it before with billing issues but all looks normal.
Is anyone familiar with changes? I had it before with billing issues but all looks normal.
FOpen a ticket?
F?support
FTo contact Cloudflare Support about an issue, please visit the Support Portal and fill in the form on the portal. After submission, you will receive confirmation over email.
Some issues, such as Account or Billing related issues, cannot be solved by the community.
Any plan level (including Free plans) can open tickets for Account, Billing or Registrar ticket categories. Make sure to select the correct category to ensure it goes to the right place.
For more information on the methods by which you can contact Support for your plan level, see Contacting Cloudflare Support - Cloudflare Docs
Some issues, such as Account or Billing related issues, cannot be solved by the community.
Any plan level (including Free plans) can open tickets for Account, Billing or Registrar ticket categories. Make sure to select the correct category to ensure it goes to the right place.
For more information on the methods by which you can contact Support for your plan level, see Contacting Cloudflare Support - Cloudflare Docs
SAre you aware is support ticket login would be the same as account login?
.Does
@cloudflare/workers work?
Chey there, do you have any snappy suggestion for generating pdfs with a worker?
Coh, found the lazyinvoice one
森I think I might have found a bug with miniflare, can someone also confirm this is also a issue?
Reproduction step:
Passing a ReadableStream through a service binding RPC call
Reproduction step:
Passing a ReadableStream through a service binding RPC call
森this is what it throws
森and if you attempt to pass a Request with a body as a RPC call, you will get:
森i feel like RPC with miniflare is exteremely buggy and I hope I'm not the one feeling about this
森i think i figured out what might be happening, i'm trying to upload a file via rpc binding by passing readable stream; while the document says it supports passing readable stream / writable stream, the source code of miniflare seems to only support the case where we pass in readable stream and the rpc code expects a writable stream (or the other way around) to be returned by the code
森i'm not sure if this is a bug, or a documentation error
森can anyone confirm this?
森(i'm leaning towards as a bug as it's an assertion error and not a explicit error being thrown)
DI recommend checking if there's a github issue for this, and if not, opening one - I also don't see a reason why it shouldn't work, and even if that is the case, the team can confirm
森closest thing i could find is:
https://github.com/cloudflare/workers-sdk/issues/6047
which is never really fixed (this really hurts the dev experience btw)
but this is related to the second issue with RPC calls and not the first
https://github.com/cloudflare/workers-sdk/issues/6047
which is never really fixed (this really hurts the dev experience btw)
but this is related to the second issue with RPC calls and not the first
GitHub
Which Cloudflare product(s) does this pertain to? R2, Miniflare What version(s) of the tool(s) are you using? 3.60.3 [wrangler], 3.20240610.0 [miniflare] What version of Node are you using? 18.18.2...
LHow do you call the bolt thing kind of communication?
LThat's not true RPC right? Because RPC would generally involve a network boundary. A request going from microservice X to microservice Y through a service mesh. But in this case the two services are colocated in the same workspace so there's no actual network request.