[event-grid][corev2] Convert EventGrid to use new core packages#12774
[event-grid][corev2] Convert EventGrid to use new core packages#12774xirzec merged 7 commits intoAzure:masterfrom
Conversation
I feel like this is the correct strategy. Both the portal and and az cli say the entire URL (including the |
|
FWIW, @xirzec, after looking over the diff, I really love the new client API. The places where things have changed make the code feel much more JS/TS like than before. |
772b891 to
00b0461
Compare
|
Marking this PR as ready to review, as we'd like to get this out on the new core beta packages for February. /cc @ramya-rao-a |
|
I think this will need a rebase because of #13361. I think they should be disjoint enough that the merge should not be too bad. Could you let me know what if anything major changed between early December and now or any thing to look at in detail when I make another pass? Excited to get our Feb beta out on this new model! |
|
@ellismg I think we covered everything offline (mostly just |
ellismg
left a comment
There was a problem hiding this comment.
LGTM, Thanks for doing this, Jeff!
Here is a quick and dirty port over to the new core packages.
The only strange issue I ran into was the OperationSpec specifies a path of
/api/events, butsample.envlists the endpoints as fully qualified:This results in URLs getting the path double-appended, so you have to redact
/api/eventsin order for the client to work. I had a similar issue with the default template beinghttps://{topicHostname}instead of just{topicHostname}.Digging into this, it seems that our old URLBuilder class in core-http did a bunch of magic to save you from double-setting URL components (it would effectively reparse whatever component you gave it and try to set all discovered pieces individually.)
I think it's OK for us to not be quite so robust, but I'm curious what @ellismg thinks our story should be here. Perhaps we should drop the path from the OperationSpecs and allow the endpoint to be fully qualified instead?