Skip to content

Follow best practices for proto files #8

@LukBed

Description

@LukBed

Proto files for gRPC API can be improved to follow best practices. The simplest wat to do it is to use Buf tool.

Example of use:

buf build           // check that proto compiles
buf format -w.      // format proto files
buf lint            // lint proto files

Current warnings from vss-vanilla module:

protobuf/password.proto:3:1:Files with package "com.virtuslab.vss.proto" must be within a directory "com/virtuslab/vss/proto" relative to root but were in directory "protobuf".
protobuf/password.proto:3:1:Package name "com.virtuslab.vss.proto" should be suffixed with a correctly formed version, such as "com.virtuslab.vss.proto.v1".
protobuf/password.proto:6:10:Field name "hashType" should be lower_snake_case, such as "hash_type".
protobuf/password.proto:11:10:Field name "hashType" should be lower_snake_case, such as "hash_type".
protobuf/password.proto:17:21:RPC request type "HashPasswordMessage" should be named "HashPasswordRequest" or "HashPasswordServiceHashPasswordRequest".
protobuf/password.proto:17:51:RPC response type "HashedPasswordMessage" should be named "HashPasswordResponse" or "HashPasswordServiceHashPasswordResponse".

Another issue is to decide if we need separate proto files for each module (vanilla, ZIO, Cats). I believe API should be the same for all modules, so the simplest solution would be to put proto into the commons module (as it's done for Tapir endpoints definitions).

The next step could be use Buf linter in builds.

FYI: @liosedhel

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions