On Feb 7, 2017, at 11:09 AM, Amila Jayasekara <[email protected]<mailto:[email protected]>> wrote:
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 <[email protected]<mailto:[email protected]>> wrote: 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 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) 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 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. 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. [4] https://news.ycombinator.com/item?id=4076834 Thanks, Marcus
