I think we have to decide whether we are going to allow users to edit
generated bal files. If so then they can write some custom logic and
generate the balx files. If we are not allowing them to edit bal files then
micro gw will be only pass through with some filters.

On Mon, May 28, 2018 at 5:30 PM Isuru Haththotuwa <[email protected]> wrote:

>
>
> On Mon, May 28, 2018 at 5:03 PM, Sanjeewa Malalgoda <[email protected]>
> wrote:
>
>>
>>
>> On Mon, May 28, 2018 at 3:23 PM, Harsha Kumara <[email protected]> wrote:
>>
>>> Hi All,
>>>
>>> We are working on releasing a ballerina based micro gateway with APIM
>>> 2.5.0. We are providing are Cli Tool which allow users to generate
>>> ballerina executables and runtime archives based on provided configurations.
>>>
>>> High Level Architecture
>>> [image: image.png]
>>>
>>> *Micro gateway distribution structure*
>>>
>>> micro-gw
>>>     ├── bin
>>>     │   ├── micro-gw.bat
>>>     │   └── micro-gw.sh
>>>     ├── lib
>>>     │   └── ballerina-0.970.0
>>>     ├── temp
>>>     │   └── path.txt
>>>     └── templates
>>>         ├── api.mustache
>>>         ├── config.mustache
>>>         └── gateway_config.mustache
>>>         └── policy_template.mustache
>>>
>>>
>>> *Core Cli Commands*
>>>
>>>    - *micro-gw setup/init (with inputs username, label name and
>>>    password(*optional
>>> *)) *
>>>       - This command will create basic project structure. Initially
>>>       consumer key and secret will be generated by taking user inputs and
>>>       retrieve the api definitions of given label type in the argument. If 
>>> user
>>>       provides new label, there will be new directory structure for that 
>>> label
>>>       will be created under projects directory.
>>>       - *projects* directory contains directories for each label and
>>>       ballerina source file will be created for each API under particular 
>>> label
>>>       - *config.yaml* contains configurations related to publisher, key
>>>       manager connections, consumer key and secret which are common across 
>>> all
>>>       labels
>>>       - *gateway_config.yaml* contains configurations specific to
>>>       labels such as docker/kubernetes
>>>
>>> Shouldn't we provide  publisher URL along with this command? If
>> publisher is hosted server and micro gateway runs within local machine then
>> we may need to point to that publisher(something similar to current micro
>> gateway scenario).
>>
> The init/setup command will only create the project structure.
> Communicating with the Publisher, pulling the API definition and building
> the corresponding .balx file & the runnable distribution happens with the
> build command.
>
>>
>>>
>>> *           Generated Project Structure*
>>>
>>> micro-gw-resources
>>>
>>>     ├── conf
>>>
>>>     │   └── config.yaml
>>>
>>>     └── projects (folder name is same as label name)
>>>
>>>         ├── accounts
>>>
>>>         │   ├── src
>>>
>>>         │   │   ├── companyAccounts_v1.0.0.bal
>>>
>>>         │   │   └── salesforce_v1.0.0.bal
>>>
>>>         │   └── target
>>>
>>>         │       ├── accounts.balx
>>>
>>>         │       └── accounts.zip
>>>
>>>         ├── finance
>>>
>>>         │   ├── src
>>>
>>>         │   │   ├── invoices_v2.0.0.bal
>>>
>>>         │   │   └── payments_v2.1.0.bal
>>>
>>>         │   └── target
>>>
>>>         │       ├── finance.balx
>>>
>>>         │       └── finance.zip
>>>
>>>         ├── gateway-config
>>>
>>>         │   └── gateway-config.yaml
>>>
>>>         └── sales
>>>
>>>             ├── src
>>>
>>>             │   ├── customers_v3.0.0.bal
>>>
>>>             │   └── leads_v4.0.0.bal
>>>
>>>             └── target
>>>
>>>                 ├── sales.balx
>>>
>>>                 └── sales.zip
>>>
>>> I think we can directly point this directory to composer and implement
>> some custom mediation logic there. In case synapse API have its own
>> mediation sequence which we cannot directly translate to ballerina.
>>
> This would be a limitation. Running any custom mediation sequences in the
> micro gw will not be supported.
>
>>
>>>    - *micro-gw build (with inputs label name)*
>>>       - This command build single balx out of all APIs belongs to given
>>>       label. If docker/kubernetes configurations specified, then
>>>       archive will be generated. This archive will embeds bre, generated 
>>> balx
>>>       which someone can take and run without configuring anything.
>>>       - This command also outputs APIs which have updated and commands
>>>       which are available to run in target folder
>>>    - *micro-gw run (with label name)*
>>>       - This command will use to run the balx generated for given label.
>>>
>>> Please share your suggestions and improvements.
>>>
>>>
>>> Thanks,
>>> Harsha
>>> --
>>> Harsha Kumara
>>> Associate Technical Lead, WSO2 Inc.
>>> Mobile: +94775505618
>>> Blog:harshcreationz.blogspot.com
>>>
>>
>>
>>
>> --
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94 712933253
>>
>> <http://sanjeewamalalgoda.blogspot.com/>blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> <http://sanjeewamalalgoda.blogspot.com/>
>>
>>
>>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
>

-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 <javascript:void(0);>17-064-214
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to