-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split proto service #850
Split proto service #850
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice, But I'd like to change naming.
Maybe we can create a new dir at protobuf/definition
and have service.proto
and workflow.proto(in future)
there with Service
and Workflow
type names. Because this way they'll feel generic by not having the coreapi
namespace. This is good specially when we create some systemservices and they can use this proto definitions under definition
namespace.
And we can have definition.Service
inside coreapi.Service
this way not coreapi.ServiceDetail
. Which is a better name in my thinking.
Thanks for the feedback, I agree naming was bad. I was able to change few things:
Only problem with that is If anyone knows a better solution i would be really happy :) |
Fixed in b09e24f |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer singular name definition
instead of definitions
other than that lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve the concept of this PR but i would like definitions
to be renamed to definition
.
I already did it in this following PR: #852.
So we can merge in whatever way.
…ice-rename Rename protobuf/definitions to protobuf/definition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
manual tests are ok 👍
A first step to the discussion yesterday about having a proto definition for the service that we use everywhere and that is totally independent of the local environment.
Here I splitted the service into it's own proto definition and update the apis:
They return now a
ServiceDetail
that contains 2 data:I'm not really fan of the naming for the api so feel free to propose something better