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.dinukadesi...@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.
smime.p7s
Description: S/MIME cryptographic signature
