Re: Current view about airavata-django-portal. Should it be redesigned

["Christie, Marcus Aaron" <ma...@iu.edu>]

Hi Dinuka,

My comments below. I'm also CCing the dev list and I suggest we take this discussion there.

> On Apr 10, 2020, at 11:40 AM, Dinuka Desilva <l....@gmail.com> wrote:
> 
> Dear community,
> 
> I started look in and dig in to airavata-django-portal to start work on the desktop application for airavata. But, my current understanding about the airavata django portal is, it's a good idea to redesign it. Few point to say like that is,
> REST api
> There's improvements needed on the auth flow.
> Endpoints are only session based and does not support token based authentication or authorization.
> Some of the endpoints are redundant and I would say the design can be better.

This all sounds good and would be good contributions. Long-long term, we're looking at moving to gRPC on the Airavata API backend so eventually the REST api as a separate bridge may go away if the Django portal can make calls to the Airavata API server directly.
> Front end
> I feel it's better to have the front end application as a separate application connected to the rest api. So, that it can be managed separately plus customisations can be done irrespective of the api.

Yeah, specifically, I think we might want to move to client-side routing, which is used in the admin app, but not in all of the apps.
> Considering the components reusability between desktop application and web application, the architecture can be redesigned.

Absolutely.

> Considering the project I would say, it's better to think of the long term approach rather adding up some more code which means for refactoring. Few more additional points I would like to add are,
> Storage management is a common requirement not only for airavata portal but also in general. For an example, the election project i'm currently working is also having such requirements and actually we also have built something on our side. But, if we could generalise it to a common component, it could be reused.

What do you mean by storage management? I'm not familiar with your election project, what did you do regarding storage management there?
> Since this api is meant for the clients to consume directly, it'll be better to have some kind of more documentation as in like open api spec for an example. So, that they could play around with it.

There is a browseable API, if you go to localhost:8000/api. However, to be user friendly it does require some more work. There are plugins to django-rest-framework that can generate an open api spec or interoperate with one. Those might be worth investigating.

> Actually this is my understanding for few weeks and I would like to have your thoughts and advices.

This all sounds good. I encourage to post your specific ideas, as detailed as possible, to get the discussion going.

Re: Current view about airavata-django-portal. Should it be redesigned

["Christie, Marcus Aaron" <ma...@iu.edu>]

> On Apr 13, 2020, at 2:49 PM, Dinuka Desilva <l....@gmail.com> wrote:
> 
> Hi Marcus,
> 
> 
> 
> On Sat, Apr 11, 2020 at 1:41 AM Christie, Marcus Aaron <machrist@iu.edu <ma...@iu.edu>> wrote:
> Hi Dinuka,
> 
> My comments below. I'm also CCing the dev list and I suggest we take this discussion there.
> 
>> On Apr 10, 2020, at 11:40 AM, Dinuka Desilva <l.dinukadesilva@gmail.com <ma...@gmail.com>> wrote:
>> 
>> Dear community,
>> 
>> I started look in and dig in to airavata-django-portal to start work on the desktop application for airavata. But, my current understanding about the airavata django portal is, it's a good idea to redesign it. Few point to say like that is,
>> REST api
>> There's improvements needed on the auth flow.
>> Endpoints are only session based and does not support token based authentication or authorization.
>> Some of the endpoints are redundant and I would say the design can be better.
> 
> This all sounds good and would be good contributions. Long-long term, we're looking at moving to gRPC on the Airavata API backend so eventually the REST api as a separate bridge may go away if the Django portal can make calls to the Airavata API server directly.
> 
> Is this happening already? If so, any timelines? Otherwise is this something we could start off with?

No timelines, but something to be aware of.

> 
> I believe the front-end work has to wait for it. And what about authentication after moving to gRPC? Are we gonna use google authentication or have our own. I would vote for google auth. :)

I imagine it will still be OAuth2 based. When you say google auth do you mean OAuth2 or something else?
>> Front end
>> I feel it's better to have the front end application as a separate application connected to the rest api. So, that it can be managed separately plus customisations can be done irrespective of the api.
> 
> Yeah, specifically, I think we might want to move to client-side routing, which is used in the admin app, but not in all of the apps.
>> Considering the components reusability between desktop application and web application, the architecture can be redesigned.
> 
> Absolutely.
> 
>> Considering the project I would say, it's better to think of the long term approach rather adding up some more code which means for refactoring. Few more additional points I would like to add are,
>> Storage management is a common requirement not only for airavata portal but also in general. For an example, the election project i'm currently working is also having such requirements and actually we also have built something on our side. But, if we could generalise it to a common component, it could be reused.
> 
> What do you mean by storage management?
> What I meant was user file storage available in the portal.
>  
> I'm not familiar with your election project, what did you do regarding storage management there?
> The sri lanka election project <https://github.com/ECLK/results-tabulation-api> is an initiative from Lanka Software Foundation. It has a requirement of keeping file and folder storage. I was just thinking whether both of us could come to a generic component.
>  

Yes, sounds good.
>> 
>> Since this api is meant for the clients to consume directly, it'll be better to have some kind of more documentation as in like open api spec for an example. So, that they could play around with it.
> 
> There is a browseable API, if you go to localhost:8000/api. However, to be user friendly it does require some more work. There are plugins to django-rest-framework that can generate an open api spec or interoperate with one. Those might be worth investigating.
> 
>> Actually this is my understanding for few weeks and I would like to have your thoughts and advices.
> 
> This all sounds good. I encourage to post your specific ideas, as detailed as possible, to get the discussion going.

Re: Current view about airavata-django-portal. Should it be redesigned

["Christie, Marcus Aaron" <ma...@iu.edu>]

> On Apr 13, 2020, at 2:49 PM, Dinuka Desilva <l....@gmail.com> wrote:
> 
> Hi Marcus,
> 
> 
> 
> On Sat, Apr 11, 2020 at 1:41 AM Christie, Marcus Aaron <machrist@iu.edu <ma...@iu.edu>> wrote:
> Hi Dinuka,
> 
> My comments below. I'm also CCing the dev list and I suggest we take this discussion there.
> 
>> On Apr 10, 2020, at 11:40 AM, Dinuka Desilva <l.dinukadesilva@gmail.com <ma...@gmail.com>> wrote:
>> 
>> Dear community,
>> 
>> I started look in and dig in to airavata-django-portal to start work on the desktop application for airavata. But, my current understanding about the airavata django portal is, it's a good idea to redesign it. Few point to say like that is,
>> REST api
>> There's improvements needed on the auth flow.
>> Endpoints are only session based and does not support token based authentication or authorization.
>> Some of the endpoints are redundant and I would say the design can be better.
> 
> This all sounds good and would be good contributions. Long-long term, we're looking at moving to gRPC on the Airavata API backend so eventually the REST api as a separate bridge may go away if the Django portal can make calls to the Airavata API server directly.
> 
> Is this happening already? If so, any timelines? Otherwise is this something we could start off with?

No timelines, but something to be aware of.

> 
> I believe the front-end work has to wait for it. And what about authentication after moving to gRPC? Are we gonna use google authentication or have our own. I would vote for google auth. :)

I imagine it will still be OAuth2 based. When you say google auth do you mean OAuth2 or something else?
>> Front end
>> I feel it's better to have the front end application as a separate application connected to the rest api. So, that it can be managed separately plus customisations can be done irrespective of the api.
> 
> Yeah, specifically, I think we might want to move to client-side routing, which is used in the admin app, but not in all of the apps.
>> Considering the components reusability between desktop application and web application, the architecture can be redesigned.
> 
> Absolutely.
> 
>> Considering the project I would say, it's better to think of the long term approach rather adding up some more code which means for refactoring. Few more additional points I would like to add are,
>> Storage management is a common requirement not only for airavata portal but also in general. For an example, the election project i'm currently working is also having such requirements and actually we also have built something on our side. But, if we could generalise it to a common component, it could be reused.
> 
> What do you mean by storage management?
> What I meant was user file storage available in the portal.
>  
> I'm not familiar with your election project, what did you do regarding storage management there?
> The sri lanka election project <https://github.com/ECLK/results-tabulation-api> is an initiative from Lanka Software Foundation. It has a requirement of keeping file and folder storage. I was just thinking whether both of us could come to a generic component.
>  

Yes, sounds good.
>> 
>> Since this api is meant for the clients to consume directly, it'll be better to have some kind of more documentation as in like open api spec for an example. So, that they could play around with it.
> 
> There is a browseable API, if you go to localhost:8000/api. However, to be user friendly it does require some more work. There are plugins to django-rest-framework that can generate an open api spec or interoperate with one. Those might be worth investigating.
> 
>> Actually this is my understanding for few weeks and I would like to have your thoughts and advices.
> 
> This all sounds good. I encourage to post your specific ideas, as detailed as possible, to get the discussion going.

Re: Current view about airavata-django-portal. Should it be redesigned

[Dinuka Desilva <l....@gmail.com>]

Hi Marcus,



On Sat, Apr 11, 2020 at 1:41 AM Christie, Marcus Aaron <ma...@iu.edu>
wrote:

> Hi Dinuka,
>
> My comments below. I'm also CCing the dev list and I suggest we take this
> discussion there.
>
> On Apr 10, 2020, at 11:40 AM, Dinuka Desilva <l....@gmail.com>
> wrote:
>
> Dear community,
>
> I started look in and dig in to airavata-django-portal to start work on
> the desktop application for airavata. But, my current understanding about
> the airavata django portal is, it's a good idea to redesign it. Few point
> to say like that is,
>
>    - REST api
>       - There's improvements needed on the auth flow.
>       - Endpoints are only session based and does not support token based
>       authentication or authorization.
>       - Some of the endpoints are redundant and I would say the design
>       can be better.
>
>
> This all sounds good and would be good contributions. Long-long term,
> we're looking at moving to gRPC on the Airavata API backend so eventually
> the REST api as a separate bridge may go away if the Django portal can make
> calls to the Airavata API server directly.
>

Is this happening already? If so, any timelines? Otherwise is this
something we could start off with?

I believe the front-end work has to wait for it. And what about
authentication after moving to gRPC? Are we gonna use google authentication
or have our own. I would vote for google auth. :)

>
>    - Front end
>       - I feel it's better to have the front end application as a
>       separate application connected to the rest api. So, that it can be managed
>       separately plus customisations can be done irrespective of the api.
>
>
> Yeah, specifically, I think we might want to move to client-side routing,
> which is used in the admin app, but not in all of the apps.
>
>
>    - Considering the components reusability between desktop application
>       and web application, the architecture can be redesigned.
>
>
> Absolutely.
>
> Considering the project I would say, it's better to think of the long term
> approach rather adding up some more code which means for refactoring. Few
> more additional points I would like to add are,
>
>    - Storage management is a common requirement not only for airavata
>    portal but also in general. For an example, the election project i'm
>    currently working is also having such requirements and actually we also
>    have built something on our side. But, if we could generalise it to a
>    common component, it could be reused.
>
>
> What do you mean by storage management?
>
What I meant was user file storage available in the portal.


> I'm not familiar with your election project, what did you do regarding
> storage management there?
>
The sri lanka election project
<https://github.com/ECLK/results-tabulation-api> is an initiative from
Lanka Software Foundation. It has a requirement of keeping file and folder
storage. I was just thinking whether both of us could come to a generic
component.


>
>    - Since this api is meant for the clients to consume directly, it'll
>    be better to have some kind of more documentation as in like open api spec
>    for an example. So, that they could play around with it.
>
>
> There is a browseable API, if you go to localhost:8000/api. However, to be
> user friendly it does require some more work. There are plugins to
> django-rest-framework that can generate an open api spec or interoperate
> with one. Those might be worth investigating.
>
> Actually this is my understanding for few weeks and I would like to have
> your thoughts and advices.
>
>
> This all sounds good. I encourage to post your specific ideas, as detailed
> as possible, to get the discussion going.
>
>

Re: Current view about airavata-django-portal. Should it be redesigned

[Dinuka Desilva <l....@gmail.com>]

Hi Marcus,



On Sat, Apr 11, 2020 at 1:41 AM Christie, Marcus Aaron <ma...@iu.edu>
wrote:

> Hi Dinuka,
>
> My comments below. I'm also CCing the dev list and I suggest we take this
> discussion there.
>
> On Apr 10, 2020, at 11:40 AM, Dinuka Desilva <l....@gmail.com>
> wrote:
>
> Dear community,
>
> I started look in and dig in to airavata-django-portal to start work on
> the desktop application for airavata. But, my current understanding about
> the airavata django portal is, it's a good idea to redesign it. Few point
> to say like that is,
>
>    - REST api
>       - There's improvements needed on the auth flow.
>       - Endpoints are only session based and does not support token based
>       authentication or authorization.
>       - Some of the endpoints are redundant and I would say the design
>       can be better.
>
>
> This all sounds good and would be good contributions. Long-long term,
> we're looking at moving to gRPC on the Airavata API backend so eventually
> the REST api as a separate bridge may go away if the Django portal can make
> calls to the Airavata API server directly.
>

Is this happening already? If so, any timelines? Otherwise is this
something we could start off with?

I believe the front-end work has to wait for it. And what about
authentication after moving to gRPC? Are we gonna use google authentication
or have our own. I would vote for google auth. :)

>
>    - Front end
>       - I feel it's better to have the front end application as a
>       separate application connected to the rest api. So, that it can be managed
>       separately plus customisations can be done irrespective of the api.
>
>
> Yeah, specifically, I think we might want to move to client-side routing,
> which is used in the admin app, but not in all of the apps.
>
>
>    - Considering the components reusability between desktop application
>       and web application, the architecture can be redesigned.
>
>
> Absolutely.
>
> Considering the project I would say, it's better to think of the long term
> approach rather adding up some more code which means for refactoring. Few
> more additional points I would like to add are,
>
>    - Storage management is a common requirement not only for airavata
>    portal but also in general. For an example, the election project i'm
>    currently working is also having such requirements and actually we also
>    have built something on our side. But, if we could generalise it to a
>    common component, it could be reused.
>
>
> What do you mean by storage management?
>
What I meant was user file storage available in the portal.


> I'm not familiar with your election project, what did you do regarding
> storage management there?
>
The sri lanka election project
<https://github.com/ECLK/results-tabulation-api> is an initiative from
Lanka Software Foundation. It has a requirement of keeping file and folder
storage. I was just thinking whether both of us could come to a generic
component.


>
>    - Since this api is meant for the clients to consume directly, it'll
>    be better to have some kind of more documentation as in like open api spec
>    for an example. So, that they could play around with it.
>
>
> There is a browseable API, if you go to localhost:8000/api. However, to be
> user friendly it does require some more work. There are plugins to
> django-rest-framework that can generate an open api spec or interoperate
> with one. Those might be worth investigating.
>
> Actually this is my understanding for few weeks and I would like to have
> your thoughts and advices.
>
>
> This all sounds good. I encourage to post your specific ideas, as detailed
> as possible, to get the discussion going.
>
>