Thow do I do that in next-on-pages?
Nseem like the lib isnt compatible so dont need to test
Nyou can use D1 as a DB if you want SQL database
Tactually I use AWS Lambda for fetching data cause I test the the backend with aws lambda and worker and found that server is close to database is better then server is close to user when you fetch database. the response time of aws lambda is two times faster than workers when fetching data from the database.
Nhave you enabled smart placement ?
Ti try but it said that my worker does not make enough subrequest.
HYou should only be using node_compat or nodejs_compat, not both
Tyes. next-on-pages use nodejs compact and pg use node compact. so maybe they dont like each other
NI only use nodejs_compat
Dyes nodejs_compat and node_compat are indeed incompatible 
(there's some work being made to make them compatible soon-ish)
(there's some work being made to make them compatible soon-ish)
HOh, I thought it was to remove the need for node_compat at all?
HSo that everything would be under nodejs_compat
Tbut I think the issue pg doesnot work with next-on-pages is because of the build time with webpack. I use the pg lib for Workers and it works really good.
D@Hello, Iām Allie! yeah I thought that too, but my current understanding is that we don't really want to put everything under nodejs_compat as that would introduce those modules/polyfills in the runtime, forcing us to basically support them forever and handle their updates/deprecation accordingly... so a bit of a burden 
So the solution is, I believe, to put under nodejs_compat as much as it makes sense but still have node_compat for the less stable polyfills, and make nodejs_compat and node_compat compabile
So the solution is, I believe, to put under nodejs_compat as much as it makes sense but still have node_compat for the less stable polyfills, and make nodejs_compat and node_compat compabile
Nwhy not separating nodejs_compat in multiples flags
Nso you only add what functions you use
Nlike ["nodejs_asset", "nodejs_Crypto", etc]
Npg lib should use node:module but its not in the screen you sent
N
Nmaybe you can configure webpack to change these imports
HThat would just make it more confusing for people using a framework, if said framework needs ten different modules
Nor some static analysis on your code that guess what you are using (gonna be nightmare)
HIsn't that what
nodejs_compatI guess that would be possible, but what would be the benefit of it? 
Nperformance, idk if there is some performance gain if we dont use nodejs_compat but probably
HNot really. All of
nodejs_compatYou could make an argument for having the flags as a way to pressure a framework to use less of them(making them more compliant with cross-platform standards), but not sure whether that would actually work
Ntry adding this into the nextjs config
NDyes that's true, what I was saying is that for some modules (the most used and the ones with the most stable polyfills), shipping them with the runtime makes sense, but for others no (like rarely used modules or ones with polyfills that are not stable/well maintained)
so I think the runtime team wants to strike the right balance there
so I think the runtime team wants to strike the right balance there
Dnah, I did ask the runtime team some time ago, it sounds like enabling or not the nodejs_compat flag does not have any performance downside, the only current real downside is the incompatibility with node_compat
HWouldn't another solution be to pressure the packages people use that require those modules to switch to something runtime agnostic? Or finding an alternative that doesn't require
node_compatIt just seems kind of confusing to have
node_compatnodejs_compatWouldn't another solution be to pressure the packages people use that require those modules to switch to something runtime agnostic?yes, for sure, but there's a lot of such packages, also many are not properly maintained and the maintainers are not interested in switching to something else (and aren't even willing to accept contributions from us)
Ni did not know it was 2 different things x)
DOr finding an alternative that doesn't require node_compat?that's practically the current situation, isn't it?
JThis is a Next.js build error and is completely out of our control
Dyes... I can't agree more, the two flags confused me for a while 
but hey... technical limitations are technical limitations
but hey... technical limitations are technical limitations
NI have a question, is it a good idea to have link prefetch enabled by default ?
NI get like 30 worker executions per page just because nextjs like to prefetch everything
JI would say no personally, simply because of the amount of unnecessary requests it causes
Ni created a custom link component that set prefetch=false automatically, idk why nextjs enabled it by default
Nand I dont see a big difference in load time
Jthe cynical view would be more requests = more money
JI understand the benefits behind prefetching, but I don't understand the need to prefetch everything in the viewpoint. on hover, sure, but not the viewport.
Nyes but in nextjs you can either disable it completly (not even on hover) or enable for viewport
NI think they do that because they will get more money from vercel
JI never realised you couldn't have hover only. that sounds like a worthwhile feature to add
ZDoes that not go against the backwards compatibility philosophy of workers? Putting it somewhere other than the runtime because that allows for breaking changes seems to me like trying to exploit a "loophole" in the rules around backwards compatibility.
