[Bug?]: Developer UX for large applications is poor about redwood HOT 3 OPEN

Hi @jtoar - I am not sure I can help much with the internals, but hope that some of the findings when trying to optimise our application will help others. Honestly - I was hoping there were other examples of large(r) applications using RedwoodJS to learn from.

I'll start with at least having a look at what specifically impacts the performance this badly, whether it's the LOC, type generation from GraphQL etc. Our application is not what I would call "very" large, pretty typical for a service - and I would not expect even a full reload of the API to take this long.

from redwood.

FWIW, the puzzmo.com codebase is about the same size as yours API: ~68k LOC, GraphQL schema is ~2.2k LOC and it takes 2s to rebuild a change to the API file (then maybe a second to fully boot up) - this is the slowest part of my dev cycle though, so I'm also interested in where this goes

It'd be good if the incremental build system was something we could hook into from userland too, I have a lot of code which relies on a separate watchman server to ensure other changes propogate and if I can move that into the dev server its a win IMO

from redwood.

Hey @jwwisgerhof thanks for taking the time to make an issue! The project statistics will be useful in making a reproduction. I was probably the last one to look at code behind the api dev server in #9270. The problem was apparent there too. It feels like a real solution here involves introducing incremental builds which isn't a small change, but is a solved problem in some sense.

Has anyone done any real profiling of the API? Tips to increase loading times?

I don't have anything off the top of my head unfortunately.

I know one startup using Redwood has implemented incremental builds internally. They indicated they may be wiling to help. What would you be up for in terms of contributing?

from redwood.