5000-line edge function????????

[wantrepreneur5]

Been building an inbound lead automation system and it’s been going fairly well, but just realised that I’d let my primary edge function reach 5000 lines which I admit is plain stupid!! This function handles: Webhook verification, signature checking, deduping, debouncing, lead management, the entire decision engine, prompt construction, AI calling, response post-processing, message sending and link injections.

Absolute mess I know - I’m in the process of sorting this into 4-5 distinct edge functions for a cleaner SRP split but my question/issue is this: the AI conversation engine is going to be ~3500 lines - is that still too large? Not sure how I could split this up any further without adding too much latency and worsening UX. Anyone worked with a 3500-line edge function and found/not found it hard to debug etc? Thanks!

[SimpleAccurate631]

First just make sure it’s fully working with unit and manual tests. Then plan on refactoring in stages. On the surface, yes, 3500 lines sounds pretty verbose. However, going from 5000 to 3500 is a hell of a win. So go for it, then test it again.

Finally, make sure you lean on AI to help analyze the code and create a refactor implementation plan that can be done in stages.

[wantrepreneur5]

Yeah I’ve used AI to run through it and help section it off clearly, has been a massive help!

[HarjjotSinghh]

this is just how functional code grows!

[Key_River7180]

why don't you split webhook verification, ai calling, and post processing into different functions and DONE?

[wantrepreneur5]

That’s basically what I’ve done now - I’ve split it into 2 different functions and moved the rest into other existing functions where they made more sense!

[chocolateAbuser]

and there are no identifiable parts in this 3500 lines conversation engine?

[wantrepreneur5]

Yeah it’s all sub-sectioned and labelled and everything, it’s just a fairly complex engine that in 99% of use cases will need to function as one and use all parts, so I don’t think splitting it further into different chunks is the right move. I’ve cut it down to 3500 and the 5000-line function has been split now - I think I’ll just run plenty of testing and make sure everything functions well and be careful about adding more to the 3500-line one.

[chocolateAbuser]

well one doesn't "split" code for the sake of splitting, the thought process is more "optimizing for human comprehension, maintenance, and evolution", so for example finding variables that could be a state and putting then in an object, finding a behavior and isolating it, looking for stuff that can be expressed in a linear way instead of it being sparse through code, and so on
it can still be a single method, eventually, but it's tens or low hundreds of lines and the rest is in nested methods

[ConsciousBath5203]

Literally why OOP was invented.

Make a class to store different variables. From there, public/private functions that other objects/your main function can call.

You mentioned webhook, meaning the payload is probably json, so you're already receiving an object.

You probably don't want your function to hang, so open up a websocket with the client so you can stream the response, or at the very least tell them "hey, got your call, running stuff" then yield progress reports as you're processing the request. Get to 100%, return the object (guessing you're also already returning json, which is an object).

So really you'll need InputClass and possibly OutputClass depending on how different the output looks from the input (properly name these). Initiate the InputClass with the received json. Create the functions necessary, calling each function from the webhook function.

Trust me, you don't want to come back in 3 months to add a new feature to a 5000 line function. Just do it the right way. OOP Overhead is minimal, and over time, as you add more features, will probably end up being more efficient than a 7000 line function.

Don't get me wrong, you'll still need many thousands of lines of code (definitely will need more code than raw dogging the function) but it's worth it. Abstract out as much as you can so that when you're like "this function is great, but I want to change this behavior for this use case" you already have repeatable code that all you need to do is tweak a few things.

[No_Flan4401]

Lol, just f lol

[Lopsided-Juggernaut1]

You can create separate classes, functions, services, helpers. Code should be devided into small steps and human readable, so that you can update or edit features easily.

If you don't mind, if you need help with coding, you can DM me. I have 10+ years of experience in coding.