The RIT School of Photographic Arts and Sciences (SPAS) holds an annual art exhibition highlighting the top works of RIT student artists. Students can submit works for consideration during an open call, and a panel of RIT faculty jurors vote on which art will be displayed in the gallery at this show. Currently, SPAS has been paying for and using a software as a service product, CaFÉ, to facilitate this process; however, frustrations with CaFÉ’s difficult-to-use interface and poor user-experience for both administrative and student workflows has led them to seek custom replacement software which better fits their use case and work process.
Gallery Gateway is this custom replacement software.
In addition to it's use for art showcases, Gallery Gateway has also been employed to facilitate in the scholarship selection process. In the current process, scholarship applications are reviewed by judges manually inspecting art pieces, which must be printed out by the students themselves. Gallery Gateway will facilitate this process by condensing all of the scholarship pieces into a single place, allowing for easier judging while also saving students the cost of printing.
Gallery Gateway was built as a Senior Project for RIT's Software Engineering Undergraduate Program.
This iteration of the project was forked from the original Gallery Gateway Repository, built by Team A B S T R A C T I O N during the Fall 2017 and Spring 2018 semesters.
The second iteration of the project was built during the Fall 2019 and Spring 2020 semesters by The Curators under supervision of sponsor Nanette Salvaggio and faculty coach Mohamed Wiem Mkaouer
- Iteration 1: https://github.com/abstractionhq/gallery-gateway
- Iteration 2: https://github.com/johnbyrne727rit/gallery-gateway
- Iteration 3: https://github.com/Third-Time-s-the-Charm/gallery-gateway
- Iteration 4: https://github.com/RIT-GG/gallery-gateway
- Iteration 5: https://github.com/CooperMist/gallery-gateway
Both the frontend and backend are written in JavaScript.
Frontend:
- React for view rendering
- Redux for state management
- React Router v4 for page routing
- Apollo Client for GraphQL querying and data caching
- Boostrap v4 (via reactstrap) & styled-components for styling
- Formik w/ yup for forms
- Webpack for compiling our app and bundling assets together
Backend:
- Express as our web framework w/ Apollo Server as our GraphQL server
- Sequelize as our ORM w/ MySQL (>= 5.7) as our database
- Passport w/ Passport SAML for external user authentication
- JWT for API authentication & short lived tokens
- Multer for file uploads
See each of their package.json files for the other tools we used (eg. transpiling, linting, testing).
Here are some useful resources on these tools and our architecture:
- The Beginner's Guide to ReactJS by Kent C. Dodds
- the Road to learn React
- React Express
- awesome-react
- react-redux-links by Mark Erikson
- Presentational and Container Components by Dan Abramov
- Simple React Patterns by Lucas Reis
- Fullstack React
- React for Beginners by Wes Bos
- Advanced React by Ryan Florence
- Getting Started with Redux by Dan Abramov
- Building React Applications with Idiomatic Redux by Dan Abramov
- A cartoon intro to Redux by Lin Clark
- Live React: Hot Reloading with Time Travel by Dan Abramov
- 10 Tips for Better Redux Architecture by Eric Elliott
- Learn Redux by Wes Bos
- Redux Developer Tools
- GraphQL
- Apollo GraphQL
- Apollo Developers Blog
- How to GraphQL
- The GitHub GraphQL API
- From REST to GraphQL by Jacob Gillespie
- awesome-graphql
- Apollo Client Developer Tools
You'll need to be running both the frontend and backend for development. Check out each of their README's for further instructions.
These are instructions for deployment to a production environment, which is assumed to be hosted at http://gallerygateway.rit.edu/. For more information on deploying
for testing and development, see the README files gound in gallerygateway/backend and gallerygateway/frontend
We deploy our application on Ubuntu 16.04.
NOTE: Since this repository is a fork of the original github repository used to deploy gallery gateway, it needs to be pulled into the gallery gateway server as a fork
git pull https://github.com/johnbyrne727rit/gallery-gateway.git master
curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash -
sudo apt-get install -y nodejscurl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
sudo apt-get update
sudo apt-get install yarnsudo apt-get update
sudo apt-get install mysql-serverTo configure password and other settings run
sudo mysql_secure_installation utilityTo start MySQL run
sudo systemctl start mysqlInstall Nginx
sudo apt update
sudo apt install nginxThen start Nginx with
sudo systemctl start nginxInstall Supervisor
sudo apt-get install supervisorSupervisor should automatically be running after installation, but you can double check by running
service supervisor restartThis can be done using Let's Encrypt.
-
There must be a user in the sql database named 'gallerygateway'
-
To create a new user, start a mysql session with
sudo /usr/bin/mysql -u root -p
-
You can then check if the user already exists with
SELECT User, Host FROM mysql.user; -
Create a new user in the database named gallerygateway (if one does not already exist)
CREATE USER 'gallerygateway' IDENTIFIED BY '<password>';
Replacing <password> with your user password
-
-
In the top level directory, you must add a file called
mysql_password.txtcontaining, on the first line, the password for the gallerygateway sql user that was just created -
Provide the MySQL database password, RSA keys used for JWT authentication (see below)
cd /opt/node/gallerygateway/keys sudo openssl genrsa -out private.key 4096 sudo openssl rsa -in private.key -outform PEM -pubout -out public.key -
Add the the Identity Provider Certificate (idp_cert.pem) to /opt/node/gallerygateway/keys. Instructions on creating a self signed certificate can be found here
Run the deploy script from the top level directory
deploy/deploy.sh <git url>where <git url> is the url link to the zip download of the target git repository. If left blank, this will default to https://github.com/abstractionhq/gallery-gateway/archive/master.zip
The script will:
- Create a MySQL database if one does not exist (and set the character encoding to UTF-8)
- Download this project's source from GitHub
- Install and build the frontend
- Install and build the backend
- Migrate the database tables
- Start the backend using Supervisor
If the backend fails to start, the script will still complete, you can check if it is running by entering the command
sudo supervisorctl status allThis may mean that mysql has already been added to the path. In this case, try the command.
mysql -u root -pThe shell deploy script will still function properly in this case.
If this does not work, mysql may be installed somewhere else, or may not be installed at all.
You are likely missing one of the required keys. You can check the
supervisor logs found in /opt/node/gallerygateway/log.txt for more information
Because the JavaScript community tends to move faster than other language communities, this app will require regular maintenance to make sure it can run on the current LTS Node.js runtime. Additionally, npm packages this app depends on should be periodically monitored, including updating to their latest stable versions (possibly even switching packages if the current maintainer abandons support).
Package dependencies will generally only need to be updated if packages contain security vulnerabilities or you will be developing additional features or upgrading Node versions. When running npm install or yarn install, you generally will be warned of deprecated package versions. It is recommended to also install npm-check-updates and run ncu to check which packages are out-of-date. Then, read through the CHANGELOGs of each out-dated package (they're usually found on the package's npm page or GitHub repo) to see if there are any breaking changes. If there are, update any of this project's code impacted by the breaking changes and update the version of the package in the corresponding package.json file. Double check that the upgrade is compatible by making sure that all existing tests pass (Note: frontend updates that impact styling will likely need to be manually tested).
Determining the health of a package is subjective but usually involves identifying when its most recent commits were, how active the maintainers are in responding to Issues and Pull Requests, and the number of Issues and Pull Requests the project has. Additionally, new packages may be developed which offer similar features to a package we use, but because of non-functional characteristics (e.g. performance, user experience), the JavaScript community may collectively favor this new package over the old and recommend switching. A word of caution; though, beware of hype-driven development – it plagues the JavaScript community.
Node.js LTS releases are cut every year in April. Upgrading Node versions involves updating any uses of deprecated Node API calls and making sure that all npm dependencies are compatible with the new Node version.
Changes to ECMAScript are generally backwards compatible, so it is unlikely that the language syntax will need maintenance. However, since we currently rely on Babel to transpile down to what's supported in major browsers and Node, Babel may need to be periodically updated. Ideally, Babel could be removed when the language features we're using are supported natively in all major browsers and Node.