On Tue, Jun 16, 2015 at 7:52 PM, Pirinthapan Mahendran <[email protected] > wrote:
> Hi Dimuthu, > > On Tue, Jun 16, 2015 at 6:13 PM, Dimuthu Leelarathne <[email protected]> > wrote: > >> Hi Pirin, >> >> On Tue, Jun 16, 2015 at 3:30 PM, Pirinthapan Mahendran < >> [email protected]> wrote: >> >>> Hi all, >>> >>> I am implementing the UX solution, proposed by Danushka, to improve the >>> performance of Runtime configs page after removing the registry mounts. To >>> implement this, I am saving the resource name and description to the >>> existing runtime database (AF_RESOURCE) and showing these information in >>> the Runtime configs overview page and other config pages (APIs page and >>> Properties page). >>> >> >> Isn't this already done 2.1.0 release. >> > > In the current implementation we are storing only the database, > datasource, database user and database template information to the runtime > database. > > >> >>> >>> In the existing overview page we are showing Name and Authentication for >>> external APIs while all the other resource types are showing Name and >>> Description. Now the problem is when we saving the external api information >>> to the runtime database there is no column to save the authentication type. >>> >> >> In the main overview page, for external APIs we need to show the Name and >> Description only. But when we go into the APIs page we need to show the >> authentication type. Hence you need to have the authentication type stored >> somewhere. >> > > The authentication type is stored in registry. We can load this to the > APIs page when a user press the load values button as proposed by Danushka > above. > The problem is, in the current implementation of overview page, we are > sowing Name and Authentication type for external apis. Not description. If > we are going to change this to show the description instead of > authentication type in the overview page, then we can use the existing > runtime database without any issues. > +1. This is what I meant. For the Main overview page no Auth type. But for the API overview page we need it. Since we need it for API overview page we need to keep it at our side in the DB. thanks, dimuthu > > Thanks, > Pirinthapan. > >> >> >>> To overcome this issue we can choose one of the following solution. >>> >>> 1. We can add another table AF_EXTERNAL_API and store authentication >>> type there. >>> >>> >> +1 >> >> thanks, >> dimuthu >> >> >>> >>> 1. We can stop showing authentication type without retrieving data >>> from remote server. >>> 2. We can add another column to the existing AF_RESOURCE table to >>> store authentication type. >>> 3. Add a description to external apis and show it in UI instead of >>> authentication type (Currently there is no description to external apis). >>> >>> 1 & 3 will need data migration. 1 would be cleaner than 3. >>> >>> If we are going with 2, then it will show only the name of the external >>> apis while others will show name and description. >>> >>> I kindly expect your thoughts on this issue. >>> >>> Thanks. >>> >>> >>> >>> Mahendran Pirinthapan >>> Software Engineer | WSO2 Inc. >>> Mobile +94772378732. >>> >>> On Fri, Jun 12, 2015 at 1:01 PM, Pirinthapan Mahendran < >>> [email protected]> wrote: >>> >>>> Hi all, >>>> >>>> I am working on the above task. I will remove the registry mounts for >>>> Dev, Test, Prod registries and implement the UX solution as explained by >>>> Danushka. >>>> >>>> Thanks. >>>> >>>> >>>> >>>> Mahendran Pirinthapan >>>> Software Engineer | WSO2 Inc. >>>> Mobile +94772378732. >>>> >>>> On Wed, Jun 10, 2015 at 2:31 PM, Danushka Fernando <[email protected]> >>>> wrote: >>>> >>>>> Hi All >>>>> >>>>> Currently we are trying to improve the performance of the App Factory. >>>>> While doing that we identified that having a lot of registry mounts (in AF >>>>> case 3) might be an performance impact. These mounts are used to read >>>>> runtime config values and when we want to add / update we are calling the >>>>> remote service. >>>>> >>>>> Reason for this solution was that runtime config pages are really slow >>>>> due to the service calls we are doing and also because these calls can >>>>> fail >>>>> it was a point of failure. So because of these mounts we are retrieving >>>>> values without remote calls. >>>>> >>>>> But because of these mounts there could be an impact on other >>>>> operations such as Load tenant registry, Load tenant, get artifacts, etc. >>>>> >>>>> So we thought about removing them and come up with an UX solution. We >>>>> will get values from remote calls. But we won't retrieve them in every >>>>> page >>>>> load. There will be a button saying something like load values from remote >>>>> server and we will do the service call only if that button is clicked. We >>>>> will save the names of these runtime configs in runtime database and we >>>>> will list down the names in the UI from the runtime database. >>>>> And with the new Stratos / Private PaaS upgrade we will be moving >>>>> towards the Metadata service, where other PaaS also have similar service. >>>>> So after that we won’t be using these registries any way. So we are going >>>>> to go ahead with the above solution to achieve better user experience, >>>>> stability and performance. >>>>> >>>>> Thanks & Regards >>>>> Danushka Fernando >>>>> Senior Software Engineer >>>>> WSO2 inc. http://wso2.com/ >>>>> Mobile : +94716332729 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>> >> >> >> -- >> Dimuthu Leelarathne >> Director & Product Lead of App Factory >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> Mobile : 0773661935 >> >> Lean . Enterprise . Middleware >> > > -- Dimuthu Leelarathne Director & Product Lead of App Factory WSO2, Inc. (http://wso2.com) email: [email protected] Mobile : 0773661935 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
