airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Jayasekara <thejaka.am...@gmail.com>
Subject Re: Requirements for an updated portal architecture
Date Tue, 07 Feb 2017 16:01:31 GMT
Hi Marcus,

Nice summary of requirements.

Some questions inline.

On Fri, Feb 3, 2017 at 4:31 PM, Christie, Marcus Aaron <machrist@iu.edu>
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.
>
> 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.
>
>
> Thanks,
>
> Marcus
>
> [1] https://docs.djangoproject.com/en/1.10/ref/applications/
> [2] https://djangopackages.org/
> [3] https://facebook.github.io/react/docs/thinking-in-react.html

Mime
View raw message