> On Apr 13, 2020, at 2:49 PM, Dinuka Desilva <[email protected]> wrote: > > Hi Marcus, > > > > On Sat, Apr 11, 2020 at 1:41 AM Christie, Marcus Aaron <[email protected] > <mailto:[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] >> <mailto:[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?
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.
smime.p7s
Description: S/MIME cryptographic signature
