Closed netsensei closed 1 year ago
@netsensei I cannot do this separately from #24. e.g. as soon as I remove v1.Person
from the model models.Person
all grpc code stops working because that expects v1.Person
@nicolasfranck Okay. Let's close this issue and move your code under #24. Removing the gRPC code means you'll need to create a model.Person anyways.
Story
Currently, the models in
models/
are embedding the structs generated from the protobuf definition e.g.This creates a tight coupling between the proto generated
Person
struct used in gRPC context, and thePerson
model as used by the repository.So, the goal of this story is to de-couple the model used in the repository from these protobuf generated structs.
Success criteria
v1.Organisation
,v1.Person
, etc. structs from the models inmodels/
directory.models/
directorycmd/import_students.go
)Implementation suggestion
Turn the models into a first class citizen by giving them the same properties as defined in the
openapi.yaml
e.g.In the implementation of the methods
Service
struct inapi/v1/service.go
you need to convert from themodels.Person
toapi.Person
. You could leverage type conversions for this. If the underlying type of both types is identical (having identical properties) it should be possible to do this: (Assuming you have an ogen / OpenAPI generatedtype ResponsePerson struct
)By using type conversions provided by the compilers, you don't have to explicitly map properties like this:
You will also have to check for all references to
v1.Organization
andv1.Person
across the codebase.Automatic testing scenario
n/a
Additional information