Re: [Dev] [Architecture] [Intern Project] Integrating API gateway with AWS Lambda

[Binod Karunanayake]

Yes, that's right.
If a user selects lambda as the endpoint, he'll be shown only the ARN
mapping in the resources page.
If a user first goes to the resources page without setting endpoint type,
he'll be shown normal http resources.


On Mon, Sep 2, 2019 at 12:14 PM Dushan Silva  wrote:

> i'm +1 for it,
>
> One thing I want to clarify is, when we follow this approach when a user
> first visits the resources page (without adding lambda endpoint) he will be
> shown the normal http resources right ? and when the user adds the endpoint
> he will be shown the ARN stuff in the resources page? is my understanding
> correct?
>
> On Mon, Sep 2, 2019 at 11:05 AM Binod Karunanayake  wrote:
>
>> Hi all,
>>
>> Considering suggested ideas I'm +1 for adding user role details in
>> endpoints page and ARNs in the resources page. Also, +1 for adding a wizard
>> for the first time users.
>>
>> As @Kasun Thennakoon  mentioned it'll be better if we
>> could list down the ARNs when the user sets user role details(endpoint).
>> Hence I have to add a new operation to API-M REST API to get ARNs using
>> user role details.
>>
>> Thanks
>>
>> On Mon, Sep 2, 2019 at 9:40 AM Kasun Thennakoon  wrote:
>>
>>> Hi All,
>>>
>>> While I'm +1 to add a wizard for onboarding users to AWS backend APIs,
>>> but I don't think we should add a separate menu for AWS backends, IMHO we
>>> can have AWS related configurations in the endpoints section. and have the
>>> ARN selection in resources page?
>>> I think it will be convenient for the user when we provide one place to
>>> manage the resource-related attributes.
>>> So in summary:
>>>
>>>
>>>- Keep the backend related (AWS key/secret configurations) in the
>>>endpoints page
>>>- Provide the ARN selection option in resources page per operation,
>>>So users will recognize that their API operations will be mapped to there
>>>ARNs using the configurations in endpoints(backend configs).
>>>
>>> We could introduce a wizard for the first time users when the choose AWS
>>> endpoint and walk through them in the process.
>>>
>>> Regards
>>> ~KasunTe
>>>
>>
>>
>> --
>> *Binod Karunanayake* | Software Engineering Intern | WSO2 Inc.
>> (m) +94716611642 | (e) bi...@wso2.com
>> [image: http://wso2.com/signature] 
>>
>
>
> --
> Best Regards
> Dushan Silva
> Software Engineer
>
> *WSO2, Inc. *
>
> lean . enterprise . middleware
> Mob: +94 774 979042
>


-- 
*Binod Karunanayake* | Software Engineering Intern | WSO2 Inc.
(m) +94716611642 | (e) bi...@wso2.com
[image: http://wso2.com/signature] 
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Intern Project] Integrating API gateway with AWS Lambda

[Dushan Silva]

i'm +1 for it,

One thing I want to clarify is, when we follow this approach when a user
first visits the resources page (without adding lambda endpoint) he will be
shown the normal http resources right ? and when the user adds the endpoint
he will be shown the ARN stuff in the resources page? is my understanding
correct?

On Mon, Sep 2, 2019 at 11:05 AM Binod Karunanayake  wrote:

> Hi all,
>
> Considering suggested ideas I'm +1 for adding user role details in
> endpoints page and ARNs in the resources page. Also, +1 for adding a wizard
> for the first time users.
>
> As @Kasun Thennakoon  mentioned it'll be better if we
> could list down the ARNs when the user sets user role details(endpoint).
> Hence I have to add a new operation to API-M REST API to get ARNs using
> user role details.
>
> Thanks
>
> On Mon, Sep 2, 2019 at 9:40 AM Kasun Thennakoon  wrote:
>
>> Hi All,
>>
>> While I'm +1 to add a wizard for onboarding users to AWS backend APIs,
>> but I don't think we should add a separate menu for AWS backends, IMHO we
>> can have AWS related configurations in the endpoints section. and have the
>> ARN selection in resources page?
>> I think it will be convenient for the user when we provide one place to
>> manage the resource-related attributes.
>> So in summary:
>>
>>
>>- Keep the backend related (AWS key/secret configurations) in the
>>endpoints page
>>- Provide the ARN selection option in resources page per operation,
>>So users will recognize that their API operations will be mapped to there
>>ARNs using the configurations in endpoints(backend configs).
>>
>> We could introduce a wizard for the first time users when the choose AWS
>> endpoint and walk through them in the process.
>>
>> Regards
>> ~KasunTe
>>
>
>
> --
> *Binod Karunanayake* | Software Engineering Intern | WSO2 Inc.
> (m) +94716611642 | (e) bi...@wso2.com
> [image: http://wso2.com/signature] 
>


-- 
Best Regards
Dushan Silva
Software Engineer

*WSO2, Inc. *

lean . enterprise . middleware
Mob: +94 774 979042
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Intern Project] Integrating API gateway with AWS Lambda

[Binod Karunanayake]

Hi all,

Considering suggested ideas I'm +1 for adding user role details in
endpoints page and ARNs in the resources page. Also, +1 for adding a wizard
for the first time users.

As @Kasun Thennakoon  mentioned it'll be better if we
could list down the ARNs when the user sets user role details(endpoint).
Hence I have to add a new operation to API-M REST API to get ARNs using
user role details.

Thanks

On Mon, Sep 2, 2019 at 9:40 AM Kasun Thennakoon  wrote:

> Hi All,
>
> While I'm +1 to add a wizard for onboarding users to AWS backend APIs, but
> I don't think we should add a separate menu for AWS backends, IMHO we can
> have AWS related configurations in the endpoints section. and have the ARN
> selection in resources page?
> I think it will be convenient for the user when we provide one place to
> manage the resource-related attributes.
> So in summary:
>
>
>- Keep the backend related (AWS key/secret configurations) in the
>endpoints page
>- Provide the ARN selection option in resources page per operation, So
>users will recognize that their API operations will be mapped to there ARNs
>using the configurations in endpoints(backend configs).
>
> We could introduce a wizard for the first time users when the choose AWS
> endpoint and walk through them in the process.
>
> Regards
> ~KasunTe
>


-- 
*Binod Karunanayake* | Software Engineering Intern | WSO2 Inc.
(m) +94716611642 | (e) bi...@wso2.com
[image: http://wso2.com/signature] 
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Intern Project] Integrating API gateway with AWS Lambda

[Kasun Thennakoon]

Hi All,

While I'm +1 to add a wizard for onboarding users to AWS backend APIs, but
I don't think we should add a separate menu for AWS backends, IMHO we can
have AWS related configurations in the endpoints section. and have the ARN
selection in resources page?
I think it will be convenient for the user when we provide one place to
manage the resource-related attributes.
So in summary:


   - Keep the backend related (AWS key/secret configurations) in the
   endpoints page
   - Provide the ARN selection option in resources page per operation, So
   users will recognize that their API operations will be mapped to there ARNs
   using the configurations in endpoints(backend configs).

We could introduce a wizard for the first time users when the choose AWS
endpoint and walk through them in the process.

Regards
~KasunTe
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Intern Project] Integrating API gateway with AWS Lambda

[Praminda Jayawardana]

Hi Binod,

Please create a feature request in [1] if your are planning make this
available on MGW.

[1]: https://github.com/wso2/product-microgateway/issues/new/choose

Thanks,
Praminda

On Fri, Aug 30, 2019 at 2:20 PM Binod Karunanayake  wrote:

> Hi,
>
> @Himasha Guruge 
>
> 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?
>
> 1. Yes, this feature will be available in the micro gateway
> 2. I have introduced new extensions for aws lambda in the swagger
>
> Thanks
>
> On Fri, Aug 30, 2019 at 1:25 PM Dushan Silva  wrote:
>
>> 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 
>> 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 
>>> 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 
 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 
> 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.

Re: [Dev] [Architecture] [Intern Project] Integrating API gateway with AWS Lambda

[Rajith Roshan]

Hi Binod

On Fri, Aug 30, 2019 at 2:20 PM Binod Karunanayake  wrote:

> Hi,
>
> @Himasha Guruge 
>
> 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?
>
> 1. Yes, this feature will be available in the micro gateway
> 2. I have introduced new extensions for aws lambda in the swagger
>
Could you please explain the approach used to support this in the
microgateway. How the swagger extension is used and etc.

>
> Thanks
>
> On Fri, Aug 30, 2019 at 1:25 PM Dushan Silva  wrote:
>
>> 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 
>> 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 
>>> 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 
 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 
> 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 

Re: [Dev] [Architecture] [Intern Project] Integrating API gateway with AWS Lambda

[Binod Karunanayake]

Hi,

@Himasha Guruge 

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?

1. Yes, this feature will be available in the micro gateway
2. I have introduced new extensions for aws lambda in the swagger

Thanks

On Fri, Aug 30, 2019 at 1:25 PM Dushan Silva  wrote:

> 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  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 
>> 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 
>>> 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 
 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, 

Re: [Dev] [Architecture] [Intern Project] Integrating API gateway with AWS Lambda

[Dushan Silva]

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  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 
> 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 
>> 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 
>>> 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 
 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 

Re: [Dev] [Architecture] [Intern Project] Integrating API gateway with AWS Lambda

[Himasha Guruge]

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  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 
> 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 
>> 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 
>>> 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) bi...@wso2.com
 [image: http://wso2.com/signature] 

>>>
>>>
>>> --
>>> *Binod Karunanayake* | Software Engineering Intern | WSO2 Inc.
>>> (m) +94716611642 | (e) bi...@wso2.com
>>> [image: http://wso2.com/signature] 
>>>
>>
>>
>> --
>> *Chanaka Jayasena* | Technical Lead | WSO2 Inc.
>> (m) +94 77 44 64 00 6 | (w) 0112 145 345 | (e) chan...@wso2.com
>> 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) chan...@wso2.com
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Himasha Guruge
Associate Lead Solutions Engineer
WS*O2* *Inc.*
Mobile: +94 777459299
himas...@wso2.com

___
Dev mailing list
Dev@wso2.org