*Hi,* *micro-gw set-project <project_name>* I think setting the project name we can do within the *micro-gw setup* command itself rather having another command. *micro-gw setup <project_name> -a <API_name> -oa <path_to_swagger_file> -e <endpoint>*
Can we have API_name different from the title in the swagger file? I think if a different name is provided in the command, precedence will be given to that API_name. Current Micro gateway is immutable so that if we want to update an api, we will need to re-create the container/instance. When we support multiple apis how are we going to handle this? In that case i think we may need to have *micro-gw add-api *support for bulk of apis. wdyt? Thanks & Regards, Ishara Cooray Associate Technical Lead Mobile : +9477 262 9512 WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware On Mon, Feb 25, 2019 at 10:15 AM Nuwan Dias <[email protected]> wrote: > > > On Sun, Feb 24, 2019 at 3:20 PM Pubudu Gunatilaka <[email protected]> > wrote: > >> Hi, >> >> On Sat, Feb 23, 2019 at 1:01 PM Viraj Gamage <[email protected]> wrote: >> >>> Hi all, >>> >>> There is a requirement to add the following features to the Microgateway >>> in Future. >>> >>> 1. >>> >>> Add multiple APIs to a project >>> 2. >>> >>> Publish APIs from Microgateway to Store >>> 3. >>> >>> Support fine-grained endpoint configurations based on resource level. >>> - >>> >>> Ex. GET menu - <IP_1> >>> POST order - <IP_2> >>> >>> >>> Currently, when the “micro-gw setup” command is executed, it fails if >>> the project already exists and therefore we have no mechanism to add >>> another API to the same project. >>> >> >> We have the label concept in APIM to group APIs and use that label to >> generate the microgateway. But when moving with dev first approach, we >> can't use this approach. >> > > I wonder whether if its even required in this case. The labels are > attached to APIs on "API Manager". And all APIs with the same label are put > into the same project anyway. In the developer first approach you have a > native way of putting APIs into the same project, so labels become > obsolete. > >> >>> Considering the developer first approach, the current folder structure >>> of the project is as follows. >>> >>> Command: >>> >>> *micro-gw setup <project_name> -oa <path_to_swagger_file> -e <endpoint>* >>> >>> Folder Structure: >>> >>> . >>> >>> ├── conf >>> >>> │ └── deployment-config.toml >>> >>> ├── src >>> >>> │ ├── PizzaShackAPI_1_0_0.bal >>> >>> │ ├── extension_filter.bal >>> >>> │ ├── listeners.bal >>> >>> │ └── policies >>> >>> │ ├── application_10PerMin.bal >>> >>> │ ├── application_20PerMin.bal >>> >>> │ ├── application_50PerMin.bal >>> >>> │ ├── subscription_Bronze.bal >>> >>> │ ├── subscription_Gold.bal >>> >>> │ ├── subscription_Silver.bal >>> >>> │ ├── subscription_Unauthenticated.bal >>> >>> │ └── throttle_policy_initializer.bal >>> >>> └── target >>> >>> *Proposed Flow of the Process:* >>> >>> *1. setup command* >>> >>> *micro-gw setup <project_name> * >>> This is allowed and it will create the following folder structure >>> >>> ├── conf >>> >>> │ └── deployment-config.toml >>> >>> ├── routes.yaml >>> >>> ├── src >>> >>> │ └── policies >>> >>> └── target >>> >>> *micro-gw setup <project_name> -a <API_name> -oa <path_to_swagger_file> >>> -e <endpoint>* >>> >>> >> How do we handle functions? We may need a mechanism to provide a set of >> functions for mediations and match those with the relevant resources. There >> can be instances where we need to define multiple endpoints. Then we would >> need a way to define those multiple endpoints. >> > > Yes, we would need something like micro-gw add route -e "endpoint" -f > "function_name". > >> In this case, another field is added called API_name. But it is possible >>> to identify the API name from the swagger file, but when the developer >>> needs to automate the process (using a shell script) it would be hard to >>> continue with. >>> >>> Folder structure will look like this, >>> >>> >>> ├── API_files >>> >>> │ └── PizzaAPI >>> >>> │ └── v_1.0.0 >>> >>> │ ├── meta_data.dat >>> >>> │ └── pizzashackAPI.yaml >>> >>> ├── conf >>> >>> │ └── deployment-config.toml >>> >>> ├── routes.yaml >>> >> >> I guess we are validating the routes.yaml as we cannot have the same >> context for multiple APIs. >> > > In this case the routes are added by the micro-gw developer toolkit (not > by hand). So ideally it won't have any errors. > > >> ├── src >>> >>> │ └── policies >>> >>> └── target >>> >>> As you can see there is another folder added API_files. Inside that, >>> there is a folder called PizzaAPI which is provided by the developer using >>> “-a” flag. If the “-a” flag is not provided, We will read the swagger and >>> name accordingly. The version number is identified by reading the swagger >>> file. >>> >>> “pizzashackAPI.yaml” is the swagger definition of PizzaShackAPI. The >>> purpose behind saving the swagger is to publish the API to the store from >>> microgateway. Metadata file holds the metadata related to API. Other than >>> that the endpoint will be added to the routes.yaml with the corresponding >>> api_name and the version number. This endpoint is the basic endpoint for >>> the API. ( compare the difference with add-route command) >>> >>> >>> More importantly, there will not be a code generation operation at the >>> “setup” phase. In other words, there won’t be a “pizzashackAPI_1.0.0.bal” >>> file during this phase. >>> >>> >>> 2. add-api command >>> >>> As mentioned earlier, A project can either be “setup” with just one API >>> definition or without any API definition. To add more APIs, we need to >>> introduce the add command. >>> >>> *micro-gw add-api -a <user_provided_API_name> -oa <path_to_swagger_file> >>> -e <endpoint*> >>> >>> >> I think in all the cases we have to specifically provide the project name >> when executing the tool kit commands. If you look at the below commands, >> you will need the relevant project. Shall we come up with a command like >> below? >> >> micro-gw set-project <project_name> >> > > Yes, +1. > >> >> Then we don't need to provide the project name every time. >> >>> >>> As mentioned in the setup command, the user can define his own api_name. >>> This is to add the capability to automate the execution (shell scripts). >>> For more details see the “add_route” command in the below section. But in >>> all the other operations, we will be continuing with api_name provided in >>> the swagger. >>> >>> consider the following command, >>> >>> micro-gw add-api -a DrinksAPI -oa drinks_swagger.json -e some_endpoint >>> >>> ├── API_files >>> >>> │ ├── DrinksAPI >>> >>> │ │ └── v_1.0.0 >>> >>> │ │ ├── drinksAPI.yaml >>> >>> │ │ └── meta_data.dat >>> >>> │ └── PizzaAPI >>> >>> │ └── v_1.0.0 >>> >>> │ ├── meta_data.dat >>> >>> │ └── pizzashackAPI.yaml >>> >>> ├── conf >>> >>> │ └── deployment-config.toml >>> >>> ├── routes.yaml >>> >>> ├── src >>> >>> │ └── policies >>> >>> └── target >>> >>> It can be observed that still there is no code generation (bal file >>> generation) has happened. >>> >>> 3. add-route command >>> >>> >>> * micro-gw add-route -a <user_provided_api_name> -v <version> >>> <http_method> <resource_name> -e <endpoint>* >>> >>> >>> We have added a basic endpoint while setting up the API. This command is >>> to provide separate endpoints based on resource level. <http_method> would >>> be something like “GET”, “POST” etc. and resource_name would be something >>> like “menu”. These details would be added to the routes.yaml as well. >>> >>> >>> 4. build command >>> >>> >>> micro-gw build <project_name> >>> >>> >>> This is the same existing command. The difference is that code >>> generation and compilation both happen at this phase. (Previously code >>> generation happened at the “setup” phase.) In this case, >>> pizzashackAPI_1.0.0.bal file and drinksAPI_1.0.0.bal both will be saved in >>> the src directory. Target directory will have all the components which will >>> be required to run the microgateway. >>> >>> >>> 5. delete_api command >>> >>> >>> micro-gw delete-api -a <API_name> -v <API_version> >>> >> >>> Since we are supporting add_api command, we need to support delete_api >>> command as well. >>> >>> 6. list_apis command >>> >>> >>> micro-gw list_apis >>> >>> >>> This will list down all the APIs with their available versions. (API >>> name would be the name of that folder corresponding to the API) >>> >>> 7. register command >>> >>> micro-gw register -a <API_name> -v <API_version> >>> >>> >>> This command will publish the API in Store. Since we have the swagger >>> file saved in the directory, we can use the Publisher API. >>> >>> >>> >>> Please consider that the command names and the arguments are not >>> finalized yet. But this is the expected way to accomplish the task. >>> >>> As the initial step, the setup command and build command will be changed >>> as mentioned. In addition, the register command will be implemented. >>> >>> Regards, >>> Viraj >>> -- >>> *Viraj Salaka Gamage* | Software Engineer | WSO2 Inc. >>> +94 710 618 178 >>> GET INTEGRATION AGILE >>> Integration Agility for Digitally Driven Business >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> >> Thank you! >> -- >> *Pubudu Gunatilaka* >> Committer and PMC Member - Apache Stratos >> Associate Technical Lead >> WSO2, Inc.: http://wso2.com >> mobile : +94774078049 <%2B94772207163> >> >> > > -- > *Nuwan Dias* | Director | WSO2 Inc. > (m) +94 777 775 729 | (e) [email protected] > [image: Signature.jpg] > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
