-
Notifications
You must be signed in to change notification settings - Fork 189
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
Discuss the specs for bundled cloud functions #176
Comments
Good points, so maybe we can add another parameter before the event itself that will give us the type. Or the event can be an object with a type and then the internal event? |
The event type would be known when the developer writes the wing code, for example: // user-defined-events-example.w
use cloud
let bucket = new cloud.Bucket
// User defined event
proc putObject(event: { key: string, value: string }) {
bucket.putObject(event.key, event.value)
}
let fn = new cloud.Function(putObject)
// Must pass the user defined event above
fn.invoke({ key: "hello", value: "world" }) // endpoint-example.w
use cloud
// This event will have HTTP method, headers, etc.
proc putObject(event: cloud.EndpointEvent) {
bucket.putObject(event.key, event.value)
}
let fn = new cloud.Function(putObject)
let endpoint = new cloud.Endpoint(fn) From wing-local, we just need to know what shape do those events have. |
Looks good to me. I agree, for wing local the function exports has to be part of the contract of the produced .wx file. We could say for example "If the sourceCodeLanguage of the function .wx is "javascript", then the referenced asset file must have an exported function named handler, and ...."
Yeah, this is a great callout. If that's the case, maybe the definitions should go in the From a user perspective, we also need these types to be exported in the Wing SDK so that they can referenced by the user in Wing, as shown in your code example. If (I don't think these types should be defined in the wingsdk repo, since that would mean wing-local takes a dependency on wingsdk... which I believe we want to avoid?) BTW - from the compiler side, I think Wing's type checker should require that the let fn = cloud.Function(putObject); // type: cloud.Function<fn(cloud.EndpointEvent) -> nil> Maybe we can skip this for MVP though. cc @yoav-steinberg |
I think the issue is that wing-local needs to know how to generate events of these types. For example, when a queue receives a message, in order to invoke a cloud function with a QueueEvent, it must first construct an object complying with the QueueEvent interface. So I think this type/schema needs be known to the simulator implementation at compile time |
We ended up having it in the We could have a separate repository ( So, it'd look like this...:
This is what /**
* The name of the JavaScript handler exported in a WingSDK Cloud Function.
*/
export const HANDLER_NAME = "handler"
/**
* The shape of an event that a Cloud Function will receive when called via a Cloud Endpoint.
*/
export interface EndpointEvent {
method: string;
body: string | undefined;
// TODO
}
// TODO: Other resource-specific events... Shared ownership, too! |
Got it - I'm cool with either ways of packaging things. I was trying to think about this and I started trying to categorize all of the types of information that need to be defined, thought I'd share in case anyone else finds it useful: Types of data:
Constraints:
BTW - this is a random idea, but what would happen if we had the local simulator as part of the wingsdk package? // From the wing-console (main process)
import { WingLocal } from "wingsdk";
const app = WingLocal.createServer("demo.wx", { port: 5000 });
class MyWatchConfig implements IWatchConfig {
public onChange() {
app.reload();
}
}
app.watch("demo.wx", new MyWatchConfig()); |
Nice job, Chris :) I have nothing to add at the moment. I just wanted to point out a small perf change: we can provide |
Just for the sake of convenience, or is there any other reason to do so? |
Sure, sounds good.
Yeah, a little bit - I thought maybe this could eliminate some of the complexity of sharing types/interfaces between these packages. For example, the ".wx" format types (like |
Nice discussion @skyrpex and @Chriscbr !
From a Monada developer perspective it makes sense, but if I look at it from a contributor's perspective it makes it very difficult to contribute new resources because you need to contribute to 5 different repos, which means that you can't contribute a new resource with one PR, and also a lot of learning to do before you are able to do so.. |
@ShaiBer which type of contributors are you referring to? while the sdk project is designed to be an open source project, the wing-local project (server and console) isn't. If we are talking about "in-house" contributors developing "in-house" resources (pre defined resources that supported by Monada) - you are right, in order to add a full supported resources to all relevant projects, there are many repositories to be familiar with (wing-dev-console is another one :)). - although, a contributor could just add the sdk impl. without being familiar with the local server (only the schema). Regarding external contributors adding "external" resources - they will only have access to the sdk projects.
{
"app.cloud.Kuku": {
"id": "app.cloud.Kuku",
"path": "app-cloud/app.cloud.Kuku",
"type": "cloud.Kuku",
"props": {
// will be required and used by the wing server and wing-console
"externalLib": "com.external.lib.kuku",
"constructionFunction": "create" // can be defined as default
"renderFunction": "render" // can be defined as default
},
"callers": [],
"callees": ["ImageStore.cloud.Bucket"]
}
}
}
|
nice :) also have nothing to add at the moment...
Since the sdk is an open source project and wing-local isn't (and should be monetised) I don't think it will be possible |
I was referring to external contributors.
For them, even if we add support for dynamic external resources, which is
great!, they will still have 3 different open source repos to work with in
order to add a single resource.
BTW, I understand why the wing local console can't be open source, but are
we sure the server is also commercial?
…On Sun, Aug 28, 2022, 08:09 Ainvoner ***@***.***> wrote:
@ShaiBer <https://github.com/ShaiBer> which type of contributors are you
referring to?
while the sdk project is designed to be an open source project, the
wing-local project (server and console) isn't.
If we are talking about "in-house" contributors developing "in-house"
resources (pre defined resources that supported by Monada) - you are right,
in order to add a full supported resources to all relevant projects, there
are many repositories to be familiar with (wing-dev-console is another one
:)). - although, a contributor could just add the sdk impl. without being
familiar with the local server (only the schema).
Regarding external contributors adding "external" resources - they will
only have access to the sdk projects.
Post MVP we will need to add wing-local (server and console) support for
"external" resources dynamically.
for example:
- add to the schema properties like:
{
"app.cloud.Kuku": {
"id": "app.cloud.Kuku",
"path": "app-cloud/app.cloud.Kuku",
"type": "cloud.Kuku",
"props": {
// will be required and used by the wing server and wing-console
"externalLib": "com.external.lib.kuku",
"constructionFunction": "create" // can be defined as default
"renderFunction": "render" // can be defined as default
},
"callers": [],
"callees": ["ImageStore.cloud.Bucket"]
}
} }
- local-server: create resource object and route
- dev-console: render the resource data UI
—
Reply to this email directly, view it on GitHub
<#176>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANGGYBVXSVWLFAM7HVTCV3V3LYBZANCNFSM57TKUMYQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Shall we continue the discussion around contributor experience on a different issue? |
Seems like this issue diverged into two separate topics. Maybe we can create a new issue to reflect what's still open and close this one? |
@staycoolcall911 I created a few issues based on some remaining threads in the discussion above:
I think the other issues about the simulator has been addressed (we've moved it into the SDK package) or are captured elsewhere like here: #214 - so I'll close this. |
Upgrades project dependencies. See details in [workflow run]. [Workflow Run]: https://github.com/winglang/console/actions/runs/3466523671 ------ *Automatically created by projen via the "upgrade-main" workflow* Signed-off-by: monabot <monabot@monada.co> Co-authored-by: Cristian Pallarés <cristianp@monada.co>
The exports for functions bundled by wingsdk
We need to define the format of the functions bundled by wingsdk and put it in common with wing-local. More specifically, we need to define what's the entry name that will be exported, and what kind of object will it expect when being called.
We currently assume that a wingsdk-bundled function will look like this:
Does it make sense?
Different event types for functions
Depending on where does the function gets called from, the event object will be different. For example:
That's what happens in AWS lambdas, at least. Here's some inspiration:
The wing-local implementation must know this format to comply with it. We need to be in sync with this, too!
The text was updated successfully, but these errors were encountered: