bcgov / nr-forests-access-management

Authorization solution for BC natural resource sector
Apache License 2.0
8 stars 2 forks source link

Remove code for unused endpoints #365

Closed gormless87 closed 1 year ago

gormless87 commented 1 year ago

Describe the task Code for unused API endpoints (not part of MVP, not currently secured) has been commented out. This task is to remove the unused endpoint code completely (best practices, avoid Sonar Cloud smell complaints).

Acceptance Criteria

Additional context

gormless87 commented 1 year ago

@MCatherine1994, @ianliuwk1019 -Can you confirm whether or not this issue is still relevant?

ianliuwk1019 commented 1 year ago

This ticket is still relevant. Commented out endpoints are still in code and can be removed. For example "FAM Users" and "FAM Roles" on OpenAPI UI. image

Ticket should be limited to only remove endpoints from "router" code (not CRUD code). And recreate api-client for frontend.

ianliuwk1019 commented 1 year ago

There was a problem during recreation of the api-client (under **client-code-gen**). It is an unexpected tricky issue resulting from some libraries not having well supported openapi(swagger) version (spec version 3.1.0). The main error due to the openapi spec V3.1.0 with the generator produced below error during api-client generation (although client code is generated):

[main] WARN  o.o.codegen.DefaultCodegen - Parameter name not defined properly. Default to UNKNOWN_PARAMETER_NAME
[main] ERROR o.o.codegen.DefaultCodegen - Not handling class PathParameter {
    class Parameter {
        name: application_id
        in: null
        description: null
        required: null
        deprecated: null
        allowEmptyValue: null
        style: simple
        explode: false
        allowReserved: null
        schema: null
        examples: null
        example: null
        content: null
        $ref: null
    }
    in: path
    required: true
} as Body Parameter at the moment

The generated api-client will contains this UNKNOWN_PARAMETER_NAME.

Secondly, in the past, due to some problem, we needed to upgrade backend FastAPI to fastapi==0.100.0. With this upgrade, FastAPI produced openapi(swagger) with default spec version V3.1.0; and this V3.1.0 is not well-supported yet from the openapi generator. Downgrade FastAPI might work, but we can't do that. I was able to find a temporary solution based on this reference (see the answer from FastAPI author Tiangolo): https://github.com/tiangolo/fastapi/discussions/9789#discussioncomment-6355603

Adding this app.openapi_version = "3.0.3" at the FastAPI main.py FastAPI app to indicate this openapi spec is with "3.0.3" will let openapi generator generate working code for our frontend. However, this is temporary to "fake" the spec, it is not actually produce 3.0.3 spec, it is still 3.1.0. Based on the author, this app.openapi_version is only "hardcode" the version as: Private Zenhub Image

We can't solve this problem correctly for now but using this temporary solution. We will need to check back the openapi generator to see if it resolve their bug: https://github.com/OpenAPITools/openapi-generator. And then remove this code in main.py: Private Zenhub Image And then make sure our client-code-gen work as expected again.

ianliuwk1019 commented 1 year ago

Current FastAPI (under version 0.100.0) also is producing strange incorrect swagger spec when it is being used for api-client code generation (at repo's client-code-gen folder). Basically few of the endpoints are missing "type" for the swagger schema, and thus the generated api client code is of any type. Although have tried downgrade and upgrade version to attempt to resolve this issue, it is not successful. Temporary manual fix is in place and a note section is added in README for the client-code-gen.