northeastern-electric-racing / pm-dashboard-v2 Goto Github PK

Netlify supports having serverless functions deployed along side the React application. This essentially means that we have our back-end together in the same repo as the front-end, and they get deployed on the same platform. Netlify functions are a wrapper around AWS Lambdas. The code for each serverless function is run on its own in a separate environment, making it tricky to share code between all the functions. Research the following links and articles and come up with a folder / file structure that will support having shared code between the serverless functions.

• First Netlify community support question I came across
• Someone who seems to have found a solution
• That person's stack-overflow answer
• That person's repository

Feel free to Google for other answers too, but theoretically the above resources should be enough.

Revisit the subject of creating a utils folder for shared code. See #14.

Because the backend code is deployed on serverless in AWS Lambda, each backend endpoint file has to be isolated and must import from node modules rather than from relative file paths.

Begin the creation of the react front-end with the folder structure of component files.

In an effort to consolidate text-based documentation for the project, let's move this product management document from Google Drive into the GitHub repo.

In order to properly set up an SQL database for use with our application, we need to plan out what data we will store and how the data will be related. Use the current database spreadsheet and the below screenshot for inspiration when building out the ERD in this diagrams.net document. This will be an interactive process, and starting earlier is bound to make things easier for us.

Research Prisma for use as an Object Relational Mapper (ORM). Potentially consider alternatives like TypeORM, Sequelize, or Objection.js to achieve the same goals. Consider benefits, ease of modifying the schema, and compatibility with PostgreSQL and TypeScript.

Put longer notes here in this issue, along with potential sample code and any other thoughts. And then you can put a couple bullets summary / thoughts in this document.

See Northeastern-Electric-Racing/NER-PM-Dashboard#114 as an excellent and thorough example.

just for consistency?

When front-end applications get really large and multiple different pages and/or components need to access the same data, front-end state management can help reduce redundant REST API calls and improve data consistency on the front-end.

Research redux for front-end state management. Consider alternatives such as MobX, Apollo GraphQL, React Context, Pullstate, and RxJS.

Bonus points for researching redux-thunk, redux-saga, or redux-observable.

While it (at first) may be difficult for us to properly test the entire API endpoint, we at least want to get started with a directory for back-end tests. We can also have the back-end code export many items so as to expose them for testing. It should hopefully not interfere with deployment.

React is a Single Page Application (SPA) framework, meaning that the browser page does not reload when navigating to various different pages within the application. While that happens, for the best user experience, we still want the url to change as the user navigates between pages. This also enables linking to pages within the SPA. This is also known as Client-Side Routing (CSR).

Research react router as a primary option to achieve this. Wouter is an alternative. Also consider compatibility with other packages under consideration.

Toss the current README into a new folder called Docs after renaming it. Then create a new README that links to it.

Follow proper steps to implement GitHub Actions in this repo, after research from #22 has been completed.

Create the navbar component that will be used throughout the site. You can create your own navbar with CSS or use one of the Bootstrap navbars as a starter and edit it to fit our design. Refer to the V3 design sketches for what the navbar should look like. As for colors, the background of the navbar should be red. The specific hex code for the red that should be used is here in this document. There aren't any constraints to the colors of the text, so feel free to try out a couple and take some screenshots or implement different colors/styles in separate files.

Create a dummy API endpoint that supplies a single work package data on the /work-package route. See #70 for details on single-data dummy endpoints. A work package must supply: WBS#, Name, Project Lead, Progress (% complete, 25% increments only), Duration in weeks, and a string deliverable.

Here's a quick outline of potential steps for this issue.

• Add file to /backend/functions/
• Add test file to /backend/tests/
• Copy in basic serverless endpoint handler function
• Add dummy data hard-coded into the file (see #74 for example)
• Add proper interface type
• Configure the handler to supply a work package as the return
• Add basic describe() test suite to test file
• Add a couple it() test cases to test suite

Not sure if this will work properly for someone else working on the issue, but it's good to have here either way.

Create a dummy API endpoint similar to #67 for the /change-requests path. Returned data should be an array of change requests. Change requests have at bare minimum an ID, associated WBS#, submitter, and type.

Here's a quick outline of potential steps for this issue.

• Add file to /backend/functions/
• Add test file to /backend/tests/
• Copy in basic serverless endpoint handler function
• Add dummy data hard-coded into the file (see #74 for example)
• Add proper interface type
• Configure the handler to supply a work package as the return
• Add basic describe() test suite to test file
• Add a couple it() test cases to test suite

Not sure if this will work properly for someone else working on the issue, but it's good to have here either way.

Research Cypress for potentially using them for end-to-end (e2e) testing. Potentially consider alternative packages like CodeceptJS to achieve the same goals. Consider compatibility with React or Next.js.

Put longer notes here in this issue, along with potential sample code and any other thoughts. And then you can put a couple bullets summary / thoughts in this document.

See Northeastern-Electric-Racing/NER-PM-Dashboard#114 as an excellent and thorough example.

Create a dummy simple API endpoint for the /projects-single path. It requires a WBS# be supplied to the GET request. Set it up with 3 different projects and make it return an error message 404 not found if the supplied WBS# does not correspond to the ones available. See #67 for potentially helpful details.

Here's a quick outline of potential steps for this issue.

• Add file to /backend/functions/
• Add test file to /backend/tests/
• Copy in basic serverless endpoint handler function
• Add dummy data hard-coded into the file (see #74 for example)
• Add proper interface type
• Configure the handler to supply a project as the return
• Add basic describe() test suite to test file
• Add a couple it() test cases to test suite

Not sure if this will work properly for someone else working on the issue, but it's good to have here either way.

The package.json description details have gotten outdated and need to be updated.

• Update name
• Add a meaningful description
• Add a few keywords
• Update the license

With the growth (both anticipated and actual) of the team working on the NER PM Dashboard project, we want to ensure that all issues coming in are able to be reviewed, revised, and prepared for the team to work on them. From now on, all issues will go through a review process. This means that any issues without the "approved" tag are not to be worked on. Let's add these details to the documentation.

Since we are quite sure we will be using Netlify for deployment, it will be great to do some research on the functionalities it has. Look into functionalities such as severless functions, user authentication, deployment, and consider its compatibility with PostgreSQL.

Put longer notes here in this issue, along with potential sample code and any other thoughts. And then you can put a couple bullets summary / thoughts in this document.

Add more details and improve the readme to prepare it for additional contributors joining the project.

Now that we've got a proper Entity Relationship Diagram for our database to get things started, let's start bringing that into the application. This is done by translating the ERD into the Prisma schema file, located in src > backend > Prisma.

Continuous Integration is an important part of the software development workflow to increase speed of development and confidence in the codebase.

Research GitHub Actions as the primary option for incorporating CI into the application development workflow. You may also want to consider alternatives like Travis CI, Circle CI, and Jenkins. Consider things like ease of use, features, integration with testing (see potentials here), and pricing.

Bonus points for potential configurations like label-based checks and more.

Research the Jest testing package to understand how testing could work, and such like that.

Create a super basic container component for displaying bare minimum data about change requests in a table very similarly to #66. See the design sketch v4 snippet below. See #74 for inspiration and suggestions.

Here's a quick outline of steps for this issue. Check them off and / or suggest edits to them as you make progress on the issue. Existing dummy components may be useful to consult for guidance (see here).

• Create the component folder in /src/containers/
• Create the test file, component file, and ccs module in the component folder
• Add basic TS functional component boilerplate to component file
• Add basic test suite describe() to test file
• Add the component to the main app component (so you can see the component when starting the app in development)
• Configure the react-bootstrap-table-next table with the following:
  • Proper columns data definitions
  • Descriptive empty table note
  • Proper styling
  • On row click
• Get the component to an aesthetically pleasing state that resembles the design sketch snippet below
• Open a PR with a screenshot of the component to get review and feedback
• Iterate and make changes based on feedback
• Once approved for merging, attach a screenshot of the finished component to this issue

Design Sketch v4 Snippet:

Research various options for integrating bootstrap with React to cut down development time. Potentially react-bootstrap (main site) or reactstrap.

Also possibly look into Awesome React Bootstrap Components and react-router-bootstrap.

Create a table of components / technology areas under consideration to track their progress being decided on

Research various options to cut development time with rendering charts in the front-end using a package. The package must include support for Gantt charts. Ideally, the package should offer some decent level of features, but nothing overly complex.

A potentially primary option would be react-google-charts, but there definitely are alternatives to explore.

Research Enzyme for React component testing. Potentially consider alternatives like react-testing-library to achieve the same goals. Consider benefits, complexity, and compatibility with react, jest, and cypress. This is a good article about testing react components.

Put longer notes here in this issue, along with potential sample code and any other thoughts. And then you can put a couple bullets summary / thoughts in this document.

See #7 as an excellent and thorough example.

In v1 of the app, Google handles all sign-in and restricts users to the Northeastern Google Suite domain. In v2, we will need to handle user authentication ourselves. Research various options to help streamline this workflow.

Some options to consider:

• Google OAuth
• react-google-login
• sign-in with apple
• Auth0
• from scratch
• Okta
• JSON Web Tokens (aka JWT)

Consider the relative difficulty of implementing each workflow with our React application, the features provided, the costs, and the potential impact on user experience.

Research ESLint and Prettier for potentially using them in linting and formatting the codebase. See this article as a primer on the differences. Potentially consider alternative packages to achieve the same goals.

Put longer notes here in this issue, along with potential sample code and any other thoughts. And then you can put a couple bullets summary / thoughts in this document.

See Northeastern-Electric-Racing/NER-PM-Dashboard#114 as an excellent and thorough example.

Create the view-only component for displaying work package details. This should cleanly and readably display a set of key value pairs supplied by the work package API endpoint. Refer to the design sketch v4 snippet below for inspiration and context.

Here's a quick outline of steps for this issue. Check them off and / or suggest edits to them as you make progress on the issue. Existing dummy components may be useful to consult for guidance (see here).

• Create the component folder in /src/components/
• Create the test file, component file, and ccs module in the component folder
• Add basic TS functional component boilerplate to component file
• Add basic test suite describe() to test file
• Add the component to the main app component (so you can see the component when starting the app in development)
• Configure component props to take in the proper work package details
• Display all desired component props in the tsx
• Add DOM element division to begin arranging / styling data elements
• Add styling to CSS module file
• Attach CSS styling to proper sections / DOM elements in tsx
• Get the component to an aesthetically pleasing state that resembles the design sketch snippet below
• Open a PR with a screenshot of the component to get review and feedback
• Iterate and make changes based on feedback
• Once approved for merging, attach a screenshot of the finished component to this issue

Design Sketch v4 Snippet:

The current readme now has a bunch of great info, but it can be a little long and cumbersome. Let's split the core pieces into separate docs and place them in the docs folder. Add a quick links section to the readme and update the table of contents too.

To finally prepare the project for more contributors, we'll need to add a license for the project. This is strictly an open source project.

As part of our application infrastructure moving data from the database to the API and finally to the front-end, we need a way to describe and model our API. Where ERDs and Relational Schemas define databases, RAML and OAS are the two most popular formats for describing APIs. Research those two formats.

Go through all steps needed to setup and configure both ESLint (for TypeScript) and Prettier in this repo. See #6 for details about how.

set up prisma to work in the repo, add instructions to the docs, and make it attached to localhost PostgreSQL database.

Now that a license has been added to the project, all code files need to have the license snippet (see below) added to the top. See here for an example.

/*
 * This file is part of NER's PM Dashboard and licensed under GNU AGPLv3.
 * See the LICENSE file in the repository root folder for details.
 */

Create a basic API endpoint to supply projects data for use in the front-end. This endpoint should support only GET requests to the /projects path. The returned data should be an array of projects. Each project should contain at minimum the project's WBS#, Name, Project Lead, and Project Manager.

In addition to running jest unit tests in GitHub Actions, we should also run a style check. This will likely require first running the check locally to see what it produces. Potentially consider this community created action, and other options to see how this can be done. Do a little experimenting and researching before opening PR.

A lot of progress has been made, and the README checklist may be lagging a bit behind the actual progress. Let's update that checklist and any other components of the README that may need updating.

Explore PostgreSQL hosting providers in an effort to understand which cloud-based fully-managed database hosting provider would be best. Also see #4. Options include: (feel free to trim the list before digging too deep)

• Digital Ocean
• Azure PostgreSQL
• AWS RDS for PostgreSQL
• Google
• ScaleGrid
• Heroku PostgreSQL
• ElephantSQL

Pricing is likely the most important axis of comparison. From rough napkin math, we anticipate having <1GB of data and a relatively small CPU load, but this could change. The 1-3 lowest price tiers are likely of most interest, and it would be beneficial to compare and see how features / performance scales with price for each provider. If prompted, bias towards hosting on the east coast, but do consider the price differences.

Research PostgreSQL for use as persistent data storage for the application. Potentially consider alternatives like Cloud Firestore, MongoDB(Atlas Cloud?) to achieve the same goals.

If inclined, explore PostgreSQL hosting providers such as Azure PostgreSQL, AWS RDS for PostgreSQL, or Heroku PostgreSQL in an effort to understand which cloud-based fully-managed database hosting provider would be best.

Put longer notes here in this issue, along with potential sample code and any other thoughts. And then you can put a couple bullets summary / thoughts in this document.

See Northeastern-Electric-Racing/NER-PM-Dashboard#114 as an excellent and thorough example.

Research Heroku for deploying the Node.js application. Potentially consider alternatives like Digital Ocean, AWS, or Google App Engine to achieve the same goals. Consider pricing, deployment ease, and compatibility with PostgreSQL.

Put longer notes here in this issue, along with potential sample code and any other thoughts. And then you can put a couple bullets summary / thoughts in this document.

See Northeastern-Electric-Racing/NER-PM-Dashboard#114 as an excellent and thorough example.

Create the view-only component for displaying project details. This should cleanly and readably display a set of key value pairs supplied by the projects-single API endpoint. Refer to the design sketch v4 snippet below for inspiration and context.

Here's a quick outline of steps for this issue. Check them off and / or suggest edits to them as you make progress on the issue. Existing dummy components may be useful to consult for guidance (see here).

• Create the component folder in /src/components/
• Create the test file, component file, and ccs module in the component folder
• Add basic TS functional component boilerplate to component file
• Add basic test suite describe() to test file
• Add the component to the main app component (so you can see the component when starting the app in development)
• Configure component props to take in the proper work package details
• Display all desired component props in the tsx
• Add DOM element division to begin arranging / styling data elements
• Add styling to CSS module file
• Attach CSS styling to proper sections / DOM elements in tsx
• Get the component to an aesthetically pleasing state that resembles the design sketch snippet below
• Open a PR with a screenshot of the component to get review and feedback
• Iterate and make changes based on feedback
• Once approved for merging, attach a screenshot of the finished component to this issue

Design Sketch v4 Snippet:

Create the sidebar component for the website. The plan is to have each icon as an individual component and to have one component that includes all the individual icon components. Refer to the V3 design sketch for how the sidebar should look. @jamescd18 has some Font Awesome icons in mind, so reach out to him for the specifics. The background color of the sidebar is undecided, so feel free to play around with colors to see what you think looks best. You can create separate files to show different styles/colors or take screenshots of some of the different styles/colors you experimented with. This document has some of the specific color codes the club uses for branding.

Create a basic simple container component (see #47 for details) that utilizes a react-bootstrap-table-next table from the Awesome React Bootstrap Components set as is explored in #19.

Start with a very simple table that just displays the project data: WBS#, Project Name, Project Lead, and Project Manager as is shown in the design sketch page from design sketches v4. Ignore everything that isn't just the simple table by itself.