airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christie, Marcus Aaron" <>
Subject Re: Requirements for an updated portal architecture
Date Wed, 08 Feb 2017 14:19:56 GMT

On Feb 7, 2017, at 11:09 AM, Amila Jayasekara <<>>

Sorry, mistakenly pressed "Send" button before I finish typing :-).

Oops I answered your first question in the other email :) Further replies below.

On Tue, Feb 7, 2017 at 11:01 AM, Amila Jayasekara <<>>
Hi Marcus,

Nice summary of requirements.

Some questions inline.

2. Have the ability to make calls to Identity Server (SOAP) and Airavata (Thrift).  Would
be good if there is support for interacting with other remote computing protocols and HPC

I was under the impression that IS has a REST interface also. Anyhow I am not sure about this.
Also, what you meant by "support for interacting with other remote computing protocols and
HPC resources" ? Can you give few examples ?
IMO, if Portal need any information from the HPC resource it should go through Airavata for
security reasons and also for communication reasons. If resource host a web server to extract
information, it is find get information directly from resource (without going through Airavata)

I think you are right that in general those requests should go through Airavata.  Here are
some examples I was thinking of:
* remote filesystem explorer over SFTP, GridFTP, Dropbox, etc. using the user’s own credentials
* pull in and display public catalogs of datasets

3. Be themable/skinnable and modular. Gateways should be able to customize the look and feel
and make the portal their own. Gateways should be able to customize the functionality available
in the portal, removing and adding just the functionality tailored for that specific gateway.

4. The backend framework should support different modes of web development: server-side rendered
views as well as REST API for client side views.

5. The backend framework should be able to easily integrate with existing scientific codes
for visualization and analysis. This would allow developing lightweight domain specific functionality
within the portal itself.

6. The backend and frontend frameworks should have active communities and some longevity,
helping to ensure continued support in the future.

7. The backend and frontend frameworks should have a gentle learning curve to promote onboarding
new contributors. Setting up a local development environment should be relatively easy.

8. The frontend framework should allow the development of more sophisticated client side views:
        • Domain specific and interactive views for configuring applications and viewing
        • Domain specific and interactive views for browsing, filtering and managing remote
and personal data collections
        • More up front validation of application configurations

Proposed solution

With these requirements I feel like Django as a backend framework and React as a frontend
framework are the best fit. Here are the benefits I see of adopting Django:
* Django has a builtin concept of modularity, the application [1].  This would allow the independent
development of new views for new funtionality (req 1) as well as making it possible to tailor
a portal to a gateway’s needs (req 3).
* Django has a very active community and lots of off the shelf applications [2] that can be
used to either quickly develop common portal functionality or to add gateway specific features
* Being written in Python means that the backend can easily integrate with Python scientific
codes for quick data analysis and visualization tasks
* A side benefit of a Python based portal is the opportunity to develop a first class Airavata
client in Python. This could enable scripts to take advantage of the Airavata API or Juptyer
like interactions with the API.
* Django is well-documented and relatively straightforward to work with, easing on-boarding
of new developers

Regarding React, I see these benefits:
* React is a much more powerful and scalable approach to web UI development than just using
jQuery, which is what the current PGA uses. With React we can build UIs with a higher degree
of interactivity. And we can build richer, more domain-specific interfaces.
* Unlike other JS frameworks that have a very large API to learn, the concepts and API surface
of React is fairly small. The main challenge is learning to “think in React” [3]

Again, feedback on this is much appreciated.

Its kind of hard to evaluate any product without actually prototyping. Django seems promising.
However, I found this [4], on Django. Not sure whether those are really valid arguments.

Yeah, I think prototyping is important.  I’m currently working with Jun on just such a prototype
for the GeoGateway.

I’ve seen similar complaints about Django in the past, but I’m not sure how much they
still hold. That link you posted is almost 5 years old.  A lot of the complaints I’ve seen
are about Django’s ORM, but the PGA would for the most part not be using that since data
is persisted through the Airavata API.




View raw message