Hi Marcus,


On Sat, Apr 11, 2020 at 1:41 AM Christie, Marcus Aaron <[email protected]>
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 <[email protected]>
> 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.
>
>

Reply via email to