Hi Marcus, Nice summary of requirements.
Some questions inline. On Fri, Feb 3, 2017 at 4:31 PM, Christie, Marcus Aaron <[email protected]> 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
