airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Jayasekara <>
Subject Re: Requirements for an updated portal architecture
Date Tue, 07 Feb 2017 16:09:13 GMT
Sorry, mistakenly pressed "Send" button before I finish typing :-).

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

> Hi Marcus,
> Nice summary of requirements.
> Some questions inline.
> On Fri, Feb 3, 2017 at 4:31 PM, Christie, Marcus Aaron <>
> wrote:
>> Dev,
>> I’ve been taking feedback from other Airavata developers and working on
>> requirements for a next generation architecture for the PGA.  First I’ll
>> list out the requirements as I see them. Then I will propose what I feel is
>> a best fit for these requirements. Feedback on all of this is much
>> appreciated.
>> Requirements
>> The following is a list of problems we would like to solve by adopting a
>> new web framework.  A new web framework here means both the backend
>> framework for server side code as well as the frontend framework for client
>> side code.
> I am little confused about the overall organization of the PGA. Isnt
> backend means Airavata ? (sorry i am outdated on most of the things).
>> 1. Have the ability to independently add new views to the portal.
>> Framework should have some concept of modularity so new functionality can
>> be added without having to make changes to other parts of the portal. This
>> would facilitate new features moving into production faster.
>> 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 resources.
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)

>> 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 results
>>         • 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.


>> Thanks,
>> Marcus
>> [1]
>> [2]
>> [3]
> [4]

View raw message