On Sun, Feb 24, 2019 at 3:20 PM Pubudu Gunatilaka <pubu...@wso2.com> wrote:
> Hi, > > On Sat, Feb 23, 2019 at 1:01 PM Viraj Gamage <vir...@wso2.com> 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 >> Architecture@wso2.org >> 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) nuw...@wso2.com [image: Signature.jpg]
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
