TLDR: This PR introduces several changes to further align with fresh, but the idea of dropping Netzo() was dropped.
Reasoning
After doing each change, it was becoming more and more evident that netzo was losing too much when moving back to having a dev.ts, main.ts and netzo.config.ts instead of a single netzo.ts. And it does not have to do much with going from 3 required files to 1, but more with the fact that we were losing the notion of having a SINGLE place where you configure the entire full-stack app (namely the netzo.ts entrypoint file). This gives great visibility (e.g. all API resources are registered/instantiated in a single place) and allows importing the netzo instance from a single place from everywhere in the app (e.g. to access resources via netzo.resource('users'). This is one thing, the second minor thing (since this can be resolved by exposing a single fresh plugin netzo()) is that the user is now required to register plugins in a certain order, rather than simply configuring them. More importantly, certain plugins depend on others (despite best efforts to avoid coupling, it makes sense that e.g. the auth plugin uses the ui plugin to style the /auth page).
In summary, I believe netzo is much easier to reason about when everything is consolidated under a single Netzo() function, rather than having everything explicit, increasing boilerplatte but also affecting newcomers.
That being said, I do believe that netzo should adhere and align to fresh (which it really already does since NetzoConfig extends FreshConfig) but exposing extra complexity to users is undesired in our case. When upstream fresh updates land, they will be easy to adapt to, since as mentioned, Netzo() is essentially a thin wrapper over fresh server.
TLDR: This PR introduces several changes to further align with fresh, but the idea of dropping
Netzo()was dropped.Reasoning
After doing each change, it was becoming more and more evident that netzo was losing too much when moving back to having a
dev.ts,main.tsandnetzo.config.tsinstead of a singlenetzo.ts. And it does not have to do much with going from 3 required files to 1, but more with the fact that we were losing the notion of having a SINGLE place where you configure the entire full-stack app (namely thenetzo.tsentrypoint file). This gives great visibility (e.g. all API resources are registered/instantiated in a single place) and allows importing thenetzoinstance from a single place from everywhere in the app (e.g. to access resources vianetzo.resource('users'). This is one thing, the second minor thing (since this can be resolved by exposing a single fresh pluginnetzo()) is that the user is now required to register plugins in a certain order, rather than simply configuring them. More importantly, certain plugins depend on others (despite best efforts to avoid coupling, it makes sense that e.g. theauthplugin uses theuiplugin to style the/authpage).In summary, I believe netzo is much easier to reason about when everything is consolidated under a single
Netzo()function, rather than having everything explicit, increasing boilerplatte but also affecting newcomers.That being said, I do believe that netzo should adhere and align to fresh (which it really already does since
NetzoConfigextendsFreshConfig) but exposing extra complexity to users is undesired in our case. When upstream fresh updates land, they will be easy to adapt to, since as mentioned,Netzo()is essentially a thin wrapper over fresh server.