thanks so much, please mention me in the

thanks so much, please mention me in the message so I'll get notified and don't risk missing it 🙂 🙏

21 Replies

Creating a thread here cos otherwise I'm gonna get lost too! 😂 so I found a tool to analyse the nextjs bundle - @next/bundle-analyzer on npm. This is the result...

mr nooli•14mo ago

for the client - gzipped size is 543kb

mr nooli•14mo ago

the nodejs, gzipped size is -70kb

mr nooli•14mo ago

and where I'm assuming the problem is, the edge. Edge.js is coming from prisma's edge client and I'd assume that's what's causing the biggest issue as the gzipped size for the edge is 17mb 😭

mr nooli•14mo ago

I'm gonna chuck this question on the prisma github too. Tagging @dario_p and @Better James if either of you have any ideas?

DarioOP•14mo ago

mh.... from the looks of it it looks like edge.js is repeated once per route? maybe the problem is that we're indeed failing to dedupe it... which could be an issue with next-on-pages or upstream 🤔 mh... no I am probably misreading the output or better... I think that your output is showing the whole application (with the routes each separated, so pre processing and deduping by next-on-pages) I think this is getting confusing.... me and James thought of a small improvement in our built log file so that we could include file sizes, that should help us here to understand things a bit better 🤔 (@Better James will you have any time to implement the thing soon-ish? otherwise I can look into it 🙂) without that things are quite unclear to me.... I don't imagine that you could share your app's source code or _worker.js folder?

James•14mo ago

yeah im not sure what that diagram is generated with but it seems pretty irrelevant to whatever is actually ended up built and makes up the final worker. In an ideal world, you would be able to provide some sort of reproduction so it can be investigated if there are further opportunities for deduping and minification with the dependencies and setup you use, but i would be surprised if there is anything left that we could do. Although I would strongly advise against using Prisma on edge deployments, and instead use something like Kysely or Drizzle. i was planning on doing it tomorrow evening, but i want to look and see if there is any other info that we could extract and include with it at the same time that would also help

DarioOP•14mo ago

ah, that sounds awesome! 😄

mr nooli•14mo ago

Hey! Sorry for some reason I didn't get notifications from this thread 🤦‍♂️ defeats the point of threads 😂 - yep I'm happy to share the source code - altho not publicly as we are looking to get this commercially ready. I've also reached out to the prisma team and they've created an issue here although they're incredibly slow! Issue - https://github.com/prisma/prisma/issues/21628

GitHub

edge.js: Unexpected (Duplicate) Large Edge Files · Issue #21628 ·...

Bug description A user switched to Cloudfare Workers and noticed that they have two edge files whose sizes are very large. They are wondering why they have two edge files instead of one. They also ...

mr nooli•14mo ago

oh really? Honestly I wanted to switch to Drizzle but it's such a hassle switching all the queries (a LOT of them) into something drizzle compatible. Queries are alright but the inserts/updates/deletes etc. mean that I'd need to restructure a lot of the app :/ Also in terms of DX I much prefer the way I interact with data in prisma. Either way I think switching isn't something that I can realistically consider at this stage anymore without hiring a bunch of devs. If it's possible to get the sizes of the files when I use the next-on-pages build command that'd be absolutely fantastic. One thing that I think might be worth me mentioning is I've created a singleton pattern with the following code:

import { PrismaClient } from '@prisma/client/edge';
import { withAccelerate } from '@prisma/extension-accelerate'


const prismaClientSingleton = () => {
    return new PrismaClient().$extends(withAccelerate())
}

type PrismaClientSingleton = ReturnType<typeof prismaClientSingleton>

const globalForPrisma = globalThis as unknown as {
    prisma: PrismaClientSingleton | undefined
}

const prisma = globalForPrisma.prisma ?? prismaClientSingleton()

export default prisma



globalForPrisma.prisma = prisma

import { PrismaClient } from '@prisma/client/edge';
import { withAccelerate } from '@prisma/extension-accelerate'


const prismaClientSingleton = () => {
    return new PrismaClient().$extends(withAccelerate())
}

type PrismaClientSingleton = ReturnType<typeof prismaClientSingleton>

const globalForPrisma = globalThis as unknown as {
    prisma: PrismaClientSingleton | undefined
}

const prisma = globalForPrisma.prisma ?? prismaClientSingleton()

export default prisma



globalForPrisma.prisma = prisma

I think it was originally intended for the 'normal' prisma (not the edge client) so idk if that'd cause any issues? Sorry the package here was generated with @next/bundle-analyzer

DarioOP•14mo ago

@mrnooli James added the size info to the nop-build-log.json file (which is inside .vercel/output/static/_worker.js), you can get that with the latest next-on-pages beta version, could you try to build your app with that (npx @cloudflare/next-on-pages@beta) and share the file? maybe that could show us shomething 🤔

mr nooli•14mo ago

Oh awesome thanks a tonne lemme do that now

mr nooli•14mo ago

message.txt

DarioOP•14mo ago

I can't see anything clearly wrong there by having a quick look 😓 it seems like quite a sizable application, I wonder if 6 mb is simply due to its size do you import from many libraries? I wonder if something like optimizePackageImports could be of help 😓

mr nooli•14mo ago

Hmm it is quite a chunky application but I hope it’s something that can be trimmed down. Other than prisma and supabase auth helpers don’t think so

DarioOP•14mo ago

by the way, the limit size of the worker in the paid tear is 10mb after gzip, if you're at 6 mb (hopefully pre-gzip?) then you shouldn't be getting dangerously close to the limit (unless you're trying to fit the free limit? 😓) I see... so the sheer number of routes and API routes could be what's causing it to be big 😓 from the log it kind of feels like things are getting generated correctly if you want you can share the source code or build output and we could try to have a look, but since you said you this is intended for commercial purposes it's not a must, also again I am not sure if there's anything we can do about it or if it's just how next-on-pages apps scale 😓 one thing I would suggest you to do, which I'd hope should not be too difficult to do is to try to take the application and gradually remove routes/API routes and monitor how their removal effects the size, what I imagine that you should see is that removing routes has a linear effect on the app size (meaning that there are no big jumps down), if that's the case then I would really assume that the size is simply due to the number or routes in the app 🤔 (PS: sorry for the not too helpful suggestions, we haven't really looked too much in depth/experimented with large applications with next-on-pages, as it's difficult to find realisticly big/complex applications in the wild to apply next-on-pages on 😓)

mr nooli•14mo ago

yep so the original goal was to get it to fit inside the free tier but I feel like that's not going to happen 😭 either way I think I recall someone mentioning that if it's >1mb in size it reintroduces cold starts - which is my biggest issue with the likes of vercel/amplify - both of which were much slower with SSR than I found with CF potentially - btw how does size change with Server Actions? Is it more efficient size wise cos I think it's something I'm looking to do - convert the API routes (that I don't plan on using in an app later down the line) into server actions. Absolutely no worries! The suggestions are absoltultey incredible and if you'd like access to the project - I'm more than happy to share it with a small set of devs 🙂 if I could get some CF credits in return (jk)

DarioOP•14mo ago

yeah sorry about that I think staying under 1 mb for decently sized apps is pretty much impossible 😓 I can look into that but I don't think that's a real thing... I mean, if there code were all loaded up front yes, just parsing it would slow things down, but we do lazily load only the necessary code so I don't really think that going over the 1mb would really slow things down

mr nooli•14mo ago

Oh right! Well in which case that's fab, that was really my biggest concern using CF I think it'd be good to find a way to trim down the _worker.js file either way so if there is any way I can help with that then please let me know 🙂 My stack is - NextJS Supabase Prisma and a bunch of third party services such as Sendgrid, Pusher, Stripe and I'm sure there is more that aren't coming to my mind at the moment

DarioOP•14mo ago

sorry I am not really sure 😅 , I think that a server action basically generates an edge function the same as an api route does, so it should be pretty much 1-to-1 (that's my guess!) unless vercel can bundle multiple actions into a single function, I'm not really sure, we'd need to experiment a bit more 😅 since it's commercial stuff I wouldn't like to take it lightly and just play with it for the fun of it 😅, let's monitor how things go and it gets out of hand and you'll need help then we can maybe gets more hands on with it 🙂 thanks a lot! I'll have a think about it! 🙂👍

mr nooli•14mo ago

Okay cool haha no stress. Appreciate the help 🙂

Gaming

Programming

thanks so much, please mention me in the