-
Notifications
You must be signed in to change notification settings - Fork 1
Initial sketch for subscribing to azure functions off of triggers. #1
Conversation
@lukehoban Take a look. Untested, but i think this should work properly. It basically takes Matt's work, but tries to library-fy it. It also tries to provide a pattern we can take for all the rest of the serverless azure stuff. I'll comment the particular points i thought were salient in this PR. Note: i tried to keep this similar to aws-serverless, just matching more of the azure concepts where appropriate. |
nodejs/azure-serverless/blob.ts
Outdated
@@ -0,0 +1,156 @@ | |||
// Copyright 2016-2018, Pulumi Corporation. |
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.
Start with subscription.ts first.
* return nothing, and should signal that it is done by calling `context.Done()`. Errors can be | ||
* signified by calling `context.Done(err)` | ||
*/ | ||
export type Callback<C extends Context, Data> = (context: C, data: Data) => void; |
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.
Unfortunately:
- this can't have a Promise return type afaict (unless azure has added support for that). We could consider providing separate entrypoints to allow someone to pass an async callback. We'd then ".then" that, calling context.Done(...).
- As we talked about, this can't be a callback or lambda. We can't make a trigger with a preexisting function. So we only support the callback form here.
*/ | ||
export type Callback<C extends Context, Data> = (context: C, data: Data) => void; | ||
|
||
export interface EventSubscriptionArgs { |
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.
We talkd today about being opinionated here. But it turned out to just be trivial to let the caller supply these sorts of values if they did want to control the FunctionApp they were creating. I figured it was reaosnable to just have this. As you can see, it's all optional. So there is an easy path to make FunctionApps. But you can provide these values if you want.
}); | ||
} | ||
|
||
function signedBlobReadUrl( |
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.
Copied directly from the example. I assume this works...
import * as azurestorage from "azure-storage"; | ||
|
||
const config = new pulumi.Config("azure"); | ||
const region = config.require("region"); |
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.
opinionated way to specify the region.
readonly resourceGroup: azure.core.ResourceGroup; | ||
readonly storageAccount: azure.storage.Account; | ||
readonly storageContainer: azure.storage.Container; | ||
readonly appServicePlan: azure.appservice.Plan; |
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.
these four values are the ones we may end up creating ourself. So i thought it was sensible to expose off of the subscription.
storageConnectionString: this.storageAccount.primaryConnectionString, | ||
|
||
appSettings: { | ||
"WEBSITE_RUN_FROM_ZIP": codeBlobUrl, |
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.
later you'll see the storage connection string injected directly into the Binding. I think the azury way to do things is to put a setting here and map it to the connection string. then the binding just references the appsetting key.
I could make that work. it just makes things a bit more complex as the caller has to pass along those extra appsettings. But if you think i should do this, i can!
nodejs/azure-serverless/blob.ts
Outdated
|
||
import * as subscription from "./subscription"; | ||
|
||
interface BlobBinding extends subscription.Binding { |
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.
note: this is an internal type. so it exists mostly just to document certain properties and to make it clear that the values we're passing are intentional.
nodejs/azure-serverless/blob.ts
Outdated
"uri": string; | ||
"properties": { | ||
"cacheControl": any, | ||
"contentDisposition": any, |
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.
things that are 'any' in this list basically got passed to me as 'null', so i didn't know how to determine what the type actually is easily. effectively, i'm lazy and didn't want to go hunt these down (yet).
I've been trying this out, and hit a few issues. Curious - was this working as-is for you? Summarizing a few of the things I hit:
Would be great to have something working E2E with an example so we can discuss the API design and some of the cross-cutting parameterization questions relative to that. |
We can use the built-in `azure.storage.getAccountSAS` to compute SAS URLs instead of making calls out to the Azure SDK at deployment time.
Indeed :) |
@ellismg Can you help here. It looks like something isn't setup properly with travis here:
|
52c7f6d
to
1a49488
Compare
No description provided.