I know that Azure Function Apps supports using the SendGrid binding out of the box to send emails using SendGrid. But what I can't seem to find is any information on the architecture/advantages/purposes of this as opposed to just calling the SendGrid API directly.
So at the moment I have a python function app and a function for an HTTP request/response (i.e. 2 output bindings, the HTTP Response and the SendGrid output binding). Is there any disadvantage if instead I'd rather just call the SendGrid API directly through python HTTP requests and not by setting the output binding?
I cannot figure out what is happening under the hood - does Azure wait to make the Sendgrid request (from the output binding) before making the HTTP response? That doesn't seem to be the case, as the HTTP request errors if something goes wrong on the sendgrid part. So is there any time/network advantage to using the output binding?
Or is it that the output binding exists simply to provide a language-independent "client" (JSON-string) to sendgrid emails and the main client to sendgrid can be maintained in a C# extension?
I almost feel like it is advantageous to make the calls directly to Sendgrid. If I am attempting to send an email earlier on in my function, and that function is written as async, then it could return as soon as the rest of it is done (if sendgrid has already returned). I just want to make sure I am not missing something and not taking advantage of something the output binding offers.