Feature: support Fastify

[Kampfmoehre]

All Submissions:

• [x] Have you followed the guidelines in our Contributing document?
• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• [ ] Have you written unit tests?
• [ ] Have you written unit tests that cover the negative cases (i.e.: if bad data is submitted, does the library respond properly)?
• [x] This PR is associated with an existing issue?

Closing issues closes #1217

If this is a new feature submission:

• [x] Has the issue had a maintainer respond to the issue and clarify that the feature is something that aligns with the goals and philosophy of the project?

Potential Problems With The Approach

There are still many things to test, this is initial support only tested with an in house application

Test plan TBD

[Kampfmoehre]

I managed to convert TSOA models to Fastify schemas and reuse them in response schemas. I hadn't had the time yet for extensive testing, but at least my sample Fastify application boots without warnings now. I had to convert some TSOA types to Fastify friendly types but I think there are more of them. I just converted those that prevented Fastify from booting.

For request schemas the situation is a little bit more difficult. TSOA parameters is an array (as far as I have seen) including all types of input (query, route, body) but Fastify would need to specify it separately (see docs for reference). I know TSOA is doing the validation itself so we wouldn't need it for Fastify but they state in their docs that requests can be a lot faster if you specify the schema (at least for body deserialization where the JSON schema helps if it knows what to expect). However I would need to write an extensive handlebar helper function or the template would be bloated up to much.

Of course all of those are optional, the plain Fastify works with the simple template mentioned in #1217

[WoH]

I'd love to use fastify's validation since ajv precompiles these into very efficient code which is indeed a lot faster, but as you mentioned, we can use our validation layer initially. This also retains the same structure for validation errors.

I've thought about deprecating our validations for all supported frameworks, but that means we have to produce HBS templates with JSON schema instead of our format which is quite a bit of work.

[Kampfmoehre]

Maybe we should make a configuration flag for now where users could choose between TSOA and Fastify validation?

[WoH]

Initial thought: I'd rather have 2 independent fastify templates. One with the tsoa validation service as a dependency, one without. But I'm not sure how much die duplication that implies, so I'd rely on your judgement.

[Kampfmoehre]

I don't have that much experience with Fastify but as far as I can see everything related to validation is in the schema parameter in the call to the route handler. So each route would be something like

app.post("/url", {
  schema: {
    query: { // ... },
    body: { // ... },
    params: { // ... },
    headers: { // ... },
});

So to skip validation I think we just have to omit those parts (like it is in the current template). This could be a simple #if in the template.

[github-actions[bot]]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[github-actions[bot]]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[github-actions[bot]]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[Kampfmoehre]

Sorry for the long time, at the moment I have lots of other stuff to do. I hope I will have some time before the year ends to at least make this work for the basic setup.

[Kampfmoehre]

I adapted the changes introduced in 5.0, especially the new RouteGenerator. I added a new FastifyRouteGenerator and I ask myself if I should extract part of the buildContext method to an own (protected) method. Since I modify and add things to the TSOA context object, I am not sure about consequences for other route templates. If there is an own FastifyRouteGenerator anyway, this code could be moved so others are unaffected. But right now I would have to copy the complete method to made these two changes where I add additional fields to the actions object https://github.com/droidsolutions/tsoa/blob/master/packages/cli/src/routeGeneration/routeGenerator.ts#L128

On the other hand, an additional buildControllerActions method could make the code look more complicated. Any thoughts on this?

[WoH]

I'd be fine with copying from the default route generator & template but keeping the FastifyRouteGenerator and moving all the logic there. The reason is this gives the long term flexibility/independence to adapt more closely to fastify-ish philosophy (plugins, json-schema validation etc) with less baggage.

E: To start, just subclass the DefaultRouteGenerator, override the buildContext and call the super.buildContext() and change the result from there?

[github-actions[bot]]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days