Hi, I think the commands *micro-gw setup <project_name> , * *and * *micro-gw setup <project_name> -a <API_name> -oa <path_to_swagger_file> -e <endpoint>*
should be a single command when user already has a swagger. When we use the second command it should create project structure as well as API details as well. We don't need initial setup command to create project structure. This will make automation processes difficult. +1. If the user already has the swagger, he needs to execute only the second command. But the user can create project even without a swagger file, and add a swagger file later. That is the purpose of having two commands to setup the project. On Tue, Feb 26, 2019 at 12:31 PM Rajith Roshan <[email protected]> wrote: > I think the commands > *micro-gw setup <project_name> , * > *and * > *micro-gw setup <project_name> -a <API_name> -oa <path_to_swagger_file> -e > <endpoint>* > > should be a single command when user already has a swagger. When we use > the second command it should create project structure as well as API > details as well. We don't need initial setup command to create project > structure. This will make automation processes difficult. > > On Mon, Feb 25, 2019 at 5:03 PM Ishara Cooray <[email protected]> wrote: > >> Hi, >> >> On Mon, Feb 25, 2019 at 3:41 PM Ishara Cooray <[email protected]> wrote: >> >>> >>> *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>* >>> >> >> Yes, we can do that in this case. But if you want to switch between >> different projects, we can't use the setup command again and again. The >> setup command will work with the command -f. I don't think we can ask the >> user to use -f for switching between projects. >> Hence, we would need another command to set the project. >> >> Make sense.. >> Having s separate command would be good in that case. However if *micro-gw >> setup command also able to do that, then set-project command will have to >> use only if needed.* >> *I think switching between projects may not be a frequent task.* >> >> >>> 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. >>> >> >> API Name or any other configs can be specified in the meta-data file. And >> that file get the precedence over the swagger. >> Bit confused. Are there 3 different places that we can provide the >> API_name? >> If we give the option to provide API_name(or some parameter) regardless >> of it is optional or mandatory, we will have to clearly define which one is >> eventually be used in the underline logic. >> Could you please clarify? >> >> >>> 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. >>> >> >> In the microgateway approach there won't be many APIs and micro-gw >> add-api support should be able to handle. >> >> What is the expected max no of APIs per project? >> I think we can simply have a command that accepts APIs data as a file to >> cater this? >> >> 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 4:03 PM Pubudu Gunatilaka <[email protected]> >> wrote: >> >>> Hi, >>> >>> On Mon, Feb 25, 2019 at 3:41 PM Ishara Cooray <[email protected]> wrote: >>> >>>> >>>> *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>* >>>> >>> >>> Yes, we can do that in this case. But if you want to switch between >>> different projects, we can't use the setup command again and again. The >>> setup command will work with the command -f. I don't think we can ask the >>> user to use -f for switching between projects. >>> >>> Hence, we would need another command to set the project. >>> >>>> >>>> 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. >>>> >>> >>> API Name or any other configs can be specified in the meta-data file. >>> And that file get the precedence over the swagger. >>> >>> >>>> >>>> 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. >>>> >>> >>> In the microgateway approach there won't be many APIs and micro-gw >>> add-api support should be able to handle. >>> >>> Thank you! >>> -- >>> *Pubudu Gunatilaka* >>> Committer and PMC Member - Apache Stratos >>> Associate Technical Lead >>> WSO2, Inc.: http://wso2.com >>> mobile : +94774078049 <%2B94772207163> >>> >>> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > *Rajith Roshan* | Senior Software Engineer | WSO2 Inc. > (m) +94-717-064-214 | (e) [email protected] <[email protected]> > > <https://wso2.com/signature> > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *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
