Please Lichter, talk about multi tenancy in NuxtJs. Its key in SaaS applications. How to build them, have custom domains and deployment considerations or recommandations. There is a surprisingly low amount of resources on it from official sources
I think if the task is to create a generic function to define project-specific event handlers which automatically apply cross-cutting concerns (authorization, authentication, logging, tracing, etc.), then the better name is defineEventHandler, not eventHandler, because this function **returns** event handler. It is not an event handler itself. And NOW it is a good example when auto-imports sucks, @TheAlexLichter. ;) Any new developer in the team (or even the developer who actually written this code, but 6 months later) will see defineEventHandler and will automatically think, that it is the standard Nitro's function. Of course we have mouse-over, CTRL-click and other helpers, but it doesn't always work correctly (e.g. I just tried to do this and while in runtime my custom defineEventHandler is used, CTRL-click on it leads to nitro-imports.d.ts and h3/dist/index.d.ts instead of my function from utils, so VS Code just misleads and there is no easy way to know that it is actually NOT standard H3 function that will be called in runtime) and it will definitely not work if you just looking at the file on Github, for example.
The decorator pattern is powerful for sure, but we are still missing the powerful and flexible way to *apply* decorators. Like AOP in Java. But maybe it is for better. :) It is too easy to use AOP incorrectly and make code paths unexpected.
@@Gaijin101 fair point. Yet, I have to ask, where / why are wrapped event handlers faster than middlewares? The dispatch parts of either are very slim, and performance is lost in the execution of the middlewares / handlers themselves.
@@stephan553 i meant overall performance. in my case ,there were plenty of routes that dont need a certain middware. im not sure on how it works exactly internally, just tested on a high level using autocannon
Still wrapping presents or already wrapping your event handlers?
Very impressive, keep up the great teaching.
Love this pattern! Thanks for the great Video!
Please Lichter, talk about multi tenancy in NuxtJs. Its key in SaaS applications. How to build them, have custom domains and deployment considerations or recommandations. There is a surprisingly low amount of resources on it from official sources
This was super informative! Thanks :)
Glad it was 🙏🏻
I'm using object syntax for event handler, onRequest array to validate stuff
The only part I did not like was the TypeScript gymnastics that you need to do which seems complex for the average user.
I still think middlewares are easier to code/grasp/maintain/enforce etc. Thanks for introducing anyway.
Let's not forget we can also call it eventHandler, short and sweet. Just make sure you are consistent throughout the app.
True! Though I think this might be consolidated at some point
I think if the task is to create a generic function to define project-specific event handlers which automatically apply cross-cutting concerns (authorization, authentication, logging, tracing, etc.), then the better name is defineEventHandler, not eventHandler, because this function **returns** event handler. It is not an event handler itself.
And NOW it is a good example when auto-imports sucks, @TheAlexLichter. ;) Any new developer in the team (or even the developer who actually written this code, but 6 months later) will see defineEventHandler and will automatically think, that it is the standard Nitro's function. Of course we have mouse-over, CTRL-click and other helpers, but it doesn't always work correctly (e.g. I just tried to do this and while in runtime my custom defineEventHandler is used, CTRL-click on it leads to nitro-imports.d.ts and h3/dist/index.d.ts instead of my function from utils, so VS Code just misleads and there is no easy way to know that it is actually NOT standard H3 function that will be called in runtime) and it will definitely not work if you just looking at the file on Github, for example.
The decorator pattern is powerful for sure, but we are still missing the powerful and flexible way to *apply* decorators. Like AOP in Java. But maybe it is for better. :) It is too easy to use AOP incorrectly and make code paths unexpected.
Super Cool, do you mind the share the codes?
100% better than using middlewares+context
Curious, why do you feel like that?
middlewares hurt performance quite a bit. personally have been refactoring out of middlewares.
but its still useful for some cases.
@@Gaijin101 fair point.
Yet, I have to ask, where / why are wrapped event handlers faster than middlewares?
The dispatch parts of either are very slim, and performance is lost in the execution of the middlewares / handlers themselves.
@@stephan553 i meant overall performance. in my case ,there were plenty of routes that dont need a certain middware.
im not sure on how it works exactly internally, just tested on a high level using autocannon
Nice vid