I actually agree with a lot of what they said here but the last half or so of the blog post was incredibly hard to follow. The gray blocks were what he was refu

I actually agree with a lot of what they said here but the last half or so of the blog post was incredibly hard to follow. The gray blocks were what he was refuting/replying to? The X/check emojis meant he agreed or disagreed I guess? It made me think that emoji applied to the paragraph it was part of, as in "I agree with this ->" or "I disagree with this ->" when I think it meant I agree/disagree with the gray block _above_. It was hard to keep reading and so I stopped > Now the big one, reusing code is by far easier in a monolith. > Consider the scenario for patching an error in a library that is used in all your single-purpose functions: > You have to publish shared code into packages that need to be used by all of your routes > You would have to context switch, make the change in the library, merge, publish the package > Then context switch again and update the version in each of your 100’s of routes to use the new version > Then you need to test and deploy all the 100’s of routes I don't use a monolith mainly due to size. I had enough problems packaging all my functions in 1 archive and hitting size limits that I can't imagine a monolith would do anything but lock me into that issue with no solution other than splitting it up into smaller services. Currently I package all my functions individually so they only contain the code/deps that that specific function needs. This works very well and keeps my function sizes small (except for the Prisma engine, stay away from this if you can). Also I have shared code that multiple function use (wrapping code for catching errors, DB access, various other reusable services), it all works just fine and I don't package/publish my shared code, my packaging grabs what each function needs and includes it. Everything else he says, especially about getter /more/ warm starts and being able to really take advantage of PC is true, but the size issue steered me away from a monolith. If size wasn't a problem I'd probably be running express in my lambda but instead I have a 1 function per endpoint and that seems to work pretty well for my company.