feat(pubsublite): Types for resource paths and topic/subscription configs#3026
feat(pubsublite): Types for resource paths and topic/subscription configs#3026gcf-merge-on-green[bot] merged 5 commits intogoogleapis:masterfrom
Conversation
google-cla
bot
added
the
cla: yes
|
I also wanted to add manuelmenzella-google as reviewer, but the account didn't appear in the list. Also, should we set owners for pubsublite? For the smaller future clean ups, we probably don't need yoshi-go-admins. |
product-auto-label
bot
added
the
api: pubsublite
hongalex
left a comment
hongalex
left a comment
There was a problem hiding this comment.
Left some minor nits and comments, but otherwise LGTM
|
Thanks Alex, comments addressed. |
tmdiep
added
the
automerge
gcf-merge-on-green
bot
removed
the
automerge
codyoss
left a comment
codyoss
left a comment
There was a problem hiding this comment.
Sorry for not getting to this sooner. I thought I would just leave some things to consider if there is still flexibility in the API.
| // about how topics are configured. | ||
| type TopicConfig struct { | ||
| // The full path of a topic. | ||
| Name TopicPath |
There was a problem hiding this comment.
I wonder if it worth inlining all of these structs that are facades of resource names would be useful?
There was a problem hiding this comment.
Hmm... Unlike most other services, Pub/Sub Lite resources are zonal, hence topics are globally uniquely identified by {project, zone, id} and it's common to have to copy all components across to different objects, function args, etc. I think keeping the fields together as a full path is convenient and less error prone.
|
|
||
| // TopicPath stores the full path of a Google Pub/Sub Lite topic. | ||
| // See https://cloud.google.com/pubsub/lite/docs/topics for more information. | ||
| type TopicPath struct { |
There was a problem hiding this comment.
I wonder if this could struct could be refactored out. Maybe the client could take a zone and project in the constructor. Then topic methods could just request an ID. Then there would be no need for TopicPath, SubscriptionPath, and LocationPath.
There was a problem hiding this comment.
We can have cross-project subscriptions, where the topic and subscription resources are not necessarily owned by the same project. So having a default project set for the client could cause some confusion for, e.g. Create/Update Subscription.
I also saw that pubsub.Client had evolved to support variants Topic/TopicInProject, Subscription/SubscriptionInProject, so wanted to avoid this, as it seems multi-project admin does occur.
Similar remarks for zone, as the admin server is regional. Users can use the same client to manage all resources within the region.
For these reasons, I thought it would be best to give the client more flexibility with projects and zones.
|
Thanks Cody, I'll address most of your comments in #3036. |
3 participants
{Topic|Subscription}ConfigToUpdate are really just a subset of {Topic|Subscription}Config, but I adopted the *ToUpdate pattern of some of the other client libraries and for future flexibility and to provide clearer documentation.
The config fields were flattened for simplicity.
Type and field names were chosen to match Cloud Pub/Sub, where there is overlap.
See http://go/pubsublite-go-clientlib-interface.