Hi all, I feel like there two approaches we can take to this, If we are going with disabling endpoints and resources, and only enabling the aws lambda section then I think we might need to take the endpoint type (either http or lambda at api creation time) so when the initial api is created it can hide the endpoints and resources sections and only show the lambda section. Currently we only have api name, context, version as mandatory fields and endpoint and plan is optional. But will this be ok?
On the other hand if we leave the creation as it is, we can display all 3 tabs (endpoints , resources , lambda) and when he creates a lambda type using the lambda we can hide the other two tabs. Same can be done if he creates a http endpoint. I'm definitely +1 for having a separate tab and what chanaka mentioned "having a wizard" will also be something nice to have and it can be easily achieved using react. Another approach is adding an endpoint type as lambda then it will show only the access key and secret details tab in the endpoints page, and in the resource page we can have a small dropdown to select lambda resource type then he can enter lambda type resources there. I'm more inclined towards the first approach but this also works. Thanks On Fri, Aug 30, 2019 at 12:52 PM Himasha Guruge <[email protected]> wrote: > Hi Binod, > > Is this capability going to be available in the micro gateway as well? In > such a case could we introduce extensions to add lambda endpoints in the > swagger too? > > Thanks, > Himasha > > On Fri, Aug 30, 2019 at 12:21 PM Chanaka Jayasena <[email protected]> > wrote: > >> Also +1 to disable both Endpoints section and Resources while enabling >> the LAMBDA section as you suggested. Wizard is something you can do >> optionally. But you can reuse the components from Resource and Endpoints to >> build the LAMDA component. >> >> thanks, >> Chanaka >> >> On Fri, Aug 30, 2019 at 12:07 PM Chanaka Jayasena <[email protected]> >> wrote: >> >>> I would suggest to add them separately and provide them a wizard to set >>> AWS Lambda starting from the BIG overview page. >>> >>> The wizard will take the user through necessary steps and guide him >>> through the different sections. >>> >>> With old UI tech, it's difficult to do something like this without >>> duplicating the code hear and there. But now we can reuse the components in >>> different sections and build a wizard out of them just to make the UX nice. >>> >>> We have done a similar thing with subscriptions in Store. It guides the >>> user up to key generation but the application creation subscriptions and >>> key generation are still keeps it's own location on the content tree. You >>> can get more info from Dushan. He has nicely architecture the >>> implementation of the same in store. >>> >>> thanks, >>> Chanaka >>> >>> On Fri, Aug 30, 2019 at 11:46 AM Binod Karunanayake <[email protected]> >>> wrote: >>> >>>> Hi all, >>>> >>>> So far, I have developed the code for creating apis to invoke Lambda >>>> functions through REST API. *Still the above issue (set ByteBuffer >>>> response to response path directly) is not resolved*. However, I'm >>>> planning to start developing UI for this feature. Before that, I want to >>>> clarify some things I noticed with the suggested UI. >>>> >>>> As we discussed in the design review, following widget will be added to >>>> ENDPOINTS section. >>>> >>>> [image: image.png] >>>> But I have some UX issues adding this kind of widget to ENDPOINTS page >>>> in APIM 3.0. >>>> >>>> 1. A typical user will confuse by seeing resources in ENDPOINTS section. >>>> 2. What will happen to RESOURCES section (whether it has to be disabled >>>> after he selected the endpoint type as AWS Lambda)? >>>> 3. What if the user adds resources first and then goes to ENDPOINTS >>>> section to set AWS LAMBDA? >>>> >>>> To outcome these problems one can suggest to add AWS user role details >>>> (access key & secret key) in ENDPOINTS section and map resources to ARNs in >>>> RESOURCES section which raise following issues. >>>> >>>> 1. User has to first selects the endpoint type as AWS LAMBDA before set >>>> the resources. >>>> 2. Have to add optional interface for mapping ARNs in RESOURCES section. >>>> >>>> I'm suggesting to add separate section for LAMBDA configuration which >>>> will disable ENDPOINTS and RESOURCES sections when an user enables LAMBDA >>>> functions. >>>> >>>> [image: image.png] >>>> What will be the best way to add this feature in APIM-Publisher? >>>> >>>> >>>> On Tue, Aug 6, 2019 at 5:52 PM Binod Karunanayake <[email protected]> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I'm doing the above project which is a new feature in WSO2 API-M to >>>>> invoke AWS Lambda functions through WSO2 API gateway. You can find the >>>>> detailed document attached below. >>>>> >>>>> There will be no backend endpoints for APIs. Instead, an API invokes >>>>> Lambda functions as shown below. >>>>> [image: 1*ucaFQnPaYgniRfOHbBpgwA.png] >>>>> Calling Lambda is done by a class mediator. However, Lambda response >>>>> is a *byteBuffer* which have to be set to the *messageContext*. I'm >>>>> looking for a solution to set the Lambda response to messageContext >>>>> without >>>>> converting it to *String*. >>>>> >>>>> Best Regards. >>>>> >>>>> -- >>>>> *Binod Karunanayake* | Software Engineering Intern | WSO2 Inc. >>>>> (m) +94716611642 | (e) [email protected] >>>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>>> >>>> >>>> >>>> -- >>>> *Binod Karunanayake* | Software Engineering Intern | WSO2 Inc. >>>> (m) +94716611642 | (e) [email protected] >>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>> >>> >>> >>> -- >>> *Chanaka Jayasena* | Technical Lead | WSO2 Inc. >>> (m) +94 77 44 64 00 6 | (w) 0112 145 345 | (e) [email protected] >>> GET INTEGRATION AGILE >>> Integration Agility for Digitally Driven Business >>> >> >> >> -- >> *Chanaka Jayasena* | Technical Lead | WSO2 Inc. >> (m) +94 77 44 64 00 6 | (w) 0112 145 345 | (e) [email protected] >> GET INTEGRATION AGILE >> Integration Agility for Digitally Driven Business >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > Himasha Guruge > Associate Lead Solutions Engineer > WS*O2* *Inc.* > Mobile: +94 777459299 > [email protected] > <http://wso2.com/signature> > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > -- Best Regards Dushan Silva Software Engineer *WSO2, Inc. * lean . enterprise . middleware Mob: +94 774 979042
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
