Closed blackeuler closed 5 years ago
Hello @miller365, thanks for raising this issue. I agree with these points and appreciated our recent in-person conversation about this idea. I wanted to quickly write down that one of our main ideas for this feature is to implement this as a web application using Django or Flask and then deploy to Amazon Elastic Beanstalk. As the command-line interface and the API for this tool stabilizes further, we should keep thinking about how to add a web interface. One quick question: is it possible to upload files to the Amazon server that is hosting the Django/Flask application? I ask because we might want to support a person's ability to upload a CSV file that contains the data about the different people in the team.
That is a great question. It should be possible to handle file uploads in Flask/Django for Amazon. I do not know much about the Beanstalk technology but I do know that AmazonS3 is used to handle file storage in AWS. There are packages that set this interface up for you with Flask/Django. I think that would be a great feature to have. Just from thinking about it though what if their was a feature that converts CSV file into a data model already used by the app. That way the only storage setup could be handled in a Database? Just an idea.
Cool idea! I would be willing to help out with this, either on the back-end or front-end.
Seems like it would be pretty quick to get a prototype web server running as a Flask app --- would just need to design a JSON API around the existing command line interface, and then that could be used for front-end development. Long-term, I agree with Chris that it would be best to have a database model, as it would be easier to work with and to modify data. AWS has lots of different database solutions, such as Amazon Aurora for MySQL / PostgreSQL.
There is a tool for Django called import-export that allows you to upload csv, json, and other spreadsheet files to your app. The uploaded file will populate the database.
If we go down this path, I'm wondering whether we might want to rethink the whole process of making and connecting the Google form & spreadsheet. Having the option for CSV uploading is one thing, but if we want to deploy this as a public web app it seems like it would be more streamlined if we make our own replacement for the Google form, where info about the teams can be gathered directly on the site. In terms of the user experience, this would skip all the steps of importing/exporting data and switching between different websites --- this also exposes less information about the implementation to the users.
I agree with Aubrey this doesn't really make the project very scalable or streamlined. I think we should start drafting a database model to design and start thinking about implementation.
Hello @miller365 and @aubreypc and @sutterj, I think that your suggestions are great ideas. We should plan to have a complete web-based interface that would allow for the completion of tasks like:
What is the best way forward for this task? How will this web-based interface actually interact with the tool itself? For instance, might it be possible for the command-line version of the tool to still focus exclusively on the acceptance of a CSV file and then let the web interface to the following:
Also, should we plan for the completion of this feature by the deadline for this project?
I believe many faculty at Allegheny would find this software useful but may find the process of pulling the repo, downloading the proper dependencies challenging thus dissuading them from using it. I propose building a simple web application that uses gator grouper on a python server in background. This implementation could be done in a micro framework like flask or pyramid. The front-end design could be done in a Vue, or just plain old Vanilla JS, HTML, CSS. The hosting of this app could be on a free heroku app or on Allegheny's Server for internal use.