Closed maslennikov closed 1 year ago
Hi Alexey,
I think that, with hindsight, you might be right :-)
Unfortunately it is rather a breaking change to rename options as nearly every current user would need to change their code :-(
If you really feel bothered by the name you can provide your own operationResolver
;-)
Kind regards,
Hans
ps. service
is also not too bad of a name as the initial idea was that you would have a service that you would front with an fastifiy api layer ;-)
Hi,
Looking at it again I think that:
const options = {
serviceHandlers: ...,
securityHandlers: ...
...rest
}
Might even be more appropriate as securityHandlers
are also a type of handler ;-)
We could add an alias of serviceHandlers
to service
e.g. with a deprecated note.
What do you think ?
Kind regards, Hans
Hi @seriousme, I think that adding an alias with a deprecation note is a a good idea.
Also, regarding serviceHandlers
naming I think it is even more appropriate, since they differ from native fastify handlers in regard of incompatible this
context, so the name will at least give a hint that it is an entity of some other nature.
I can prepare a PR. Is it okay with you?
FYI: released as 4.3.0 on NPM
Thanks for the feedback ! Hans
Hello and thank you for this plugin! I am its recent user, and what I noticed is somewhat unfortunate naming of options fields. Both
service
andsecurityHandlers
serve their sole purpose of defining fastify http route handlers. In other MVC-ish frameworks they could also be called controllers, while services are some injected or global entities comprising business logic on top of data models.My proposal would be to rename
service
tohandlers
, so that naming stays consistent:What do you think?