Merge pull request #335 from oslabs-beta/main

Merging Swell v1.14 into OS labs main

Author: AkeemESmith

.github/workflows/codeql-analysis.yml

@@ -0,0 +1,61 @@
+# You may wish to alter this file to override the set of languages analyzed,
+# or to provide custom queries or build logic.
+name: "Code scanning"
+
+on:
+  workflow_dispatch:
+  push:
+    branches: [ ci-feature, ci-draft, dev, main ]
+    # paths: [ 'test/**', 'src/**', 'menu/**', 'main_process/**', 'build/**', '.github/workflows/**', 'webpack**' ]
+  pull_request:
+    branches: [ dev, main ]
+    # paths: [ 'test/**', 'src/**', 'menu/**', 'main_process/**', 'build/**', '.github/workflows/**', 'webpack**' ]
+
+jobs:
+  analyze:
+    name: Analyze code
+    runs-on: ubuntu-latest
+    permissions:
+      actions: read
+      contents: read
+      security-events: write
+
+    strategy:
+      fail-fast: false
+      matrix:
+        language: [ 'javascript', 'typescript' ]
+        # CodeQL supports [ 'cpp', 'csharp', 'go', 'java', 'javascript', 'python' ]
+        # Learn more:
+        # https://docs.github.com/en/free-pro-team@latest/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#changing-the-languages-that-are-analyzed
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v3
+      
+    # Initializes the CodeQL tools for scanning.
+    - name: Initialize CodeQL
+      uses: github/codeql-action/init@v2
+      with:
+        languages: ${{ matrix.language }}
+        # If you wish to specify custom queries, you can do so here or in a config file.
+        # By default, queries listed here will override any specified in a config file.
+        # Prefix the list here with "+" to use these queries and those in the config file.
+        # queries: ./path/to/local/query, your-org/your-repo/queries@main
+
+    # Autobuild attempts to build any compiled languages  (C/C++, C#, or Java).
+    # If this step fails, then you should remove it and run the build manually (see below)
+    - name: Autobuild
+      uses: github/codeql-action/autobuild@v2
+
+    # ℹ️ Command-line programs to run using the OS shell.
+    # 📚 https://git.io/JvXDl
+
+    # ✏️ If the Autobuild fails above, remove it and uncomment the following three lines
+    #    and modify them (or add more) to build your code if your project
+    #    uses a compiled language
+
+    #- run: |
+    #   make bootstrap
+    #   make release
+
+    - name: Perform CodeQL Analysis
+      uses: github/codeql-action/analyze@v2

.github/workflows/unit-tests.yml

@@ -0,0 +1,24 @@
+name: Unit Tests
+
+on: [pull_request]
+
+jobs:
+  tests:
+    strategy:
+      matrix:
+        node-version: [16]
+        os: [macos-latest, ubuntu-latest, windows-latest]
+    runs-on: ${{ matrix.os }}
+    steps:
+      - name: Checkout repo
+        uses: actions/checkout@v3
+      - name: Use Node.js ${{ matrix.node-version }}
+        uses: actions/setup-node@v3
+        with:
+          node-version: ${{ matrix.node-version }}
+      - name: Install dependencies
+        run: npm i && npm ci
+      - name: Run unit tests
+        uses: coactions/setup-xvfb@v1
+        with:
+          run: npm run test-jest

.travis.yml

@@ -41,6 +41,10 @@ Swell is a one-stop shop for sending and monitoring your API requests:
 - _WebSockets (WS)_: Swell enables connecting directly to WebSocket servers with an HTTP handshake, with developers able to send messages to the connected WS server directly. All outgoing and incoming messages are displayed in real time.
   <img src="./ReadMeGifs/Gifs/Websockets.gif" style="display: block; margin: 10px auto 30px;" />
 
+- _gRPC_: Swell includes full support for all four streaming types of gRPC - unary, client stream, server stream, bidirectional stream.
+  <!-- -TODO --- This needs to be updated -->
+    <img src="./ReadMeGifs/Gifs/gRPC.gif" style="display: block;  margin: 10px auto 30px;" />
+
 ## Additional features
 
 - _Stress testing for HTTP/2 and GraphQL_: Test your server backend with Swell's stress testing feature to ensure your server can manage expected and unexpected loads accordingly
@@ -66,12 +70,9 @@ Swell is a one-stop shop for sending and monitoring your API requests:
 - _Mock Server_: Swell allows you to create your own HTTP/2 mock server to facilitate front-end development without depending on a fully built backend server.
   <img src="./ReadMeGifs/Gifs/MockServer.gif" style="display: block;  margin: 10px auto 30px;" />
 
-- _gRPC_: Swell includes full support for all four streaming types of gRPC - unary, client stream, server stream, bidirectional stream.
-  <img src="./ReadMeGifs/Gifs/gRPC-responses.gif" style="display: block;  margin: 10px auto 30px;" />
-
 - _tRPC_: Swell includes full support for all methods of TypeScript Remote Procedure Calls including batch call support for queries and mutations.
-  <img src="./ReadMeGifs/Gifs/tRPC-query.gif" style="display: block; margin: 10px auto 30px;" />
-  <img src="./ReadMeGifs/Gifs/tRPC-subscription.gif" style="display: block; margin: 10px auto 30px;" />
+  <img src="./ReadMeGifs/Gifs/tRPC.gif" style="display: block; margin: 10px auto 30px;" />
+  <!-- <img src="./ReadMeGifs/Gifs/tRPC-subscription.gif" style="display: block; margin: 10px auto 30px;" /> -->
 
   Calls are currently being made using Swell's own TRPCProxyClient generated from the URL provided by the user.
   Batch requests must be entered one request per line. Swell will treat each line of code entered into the editor as a separate request before batching and returning responses.
@@ -133,6 +134,10 @@ Feel free to check out the `DEV-README.md` in the `docs` folder.
 
 ## Authors
 
+- **Timmy Zhu** - [timzhu15](https://github.com/timzhu15)
+- **Christina Walton** - [CElizOwens](https://github.com/CElizOwens)
+- **Akeem Smith** - [AkeemESmith](https://github.com/AkeemESmith)
+- **William Murphy** - [olsoninoslo](https://github.com/olsoninoslo)
 - **Chris Suzukida** - [csuzukida](https://github.com/csuzukida)
 - **Fred Kim** - [Fredkim21](https://https://github.com/Fredkim21)
 - **Jason Huang** - [jjhuang3](https://https://github.com/jjhuang3)

README.md

@@ -14,6 +14,7 @@ If you are considering contributing to Swell in the context of a group or medium
 - Express
 - Webpack
 - Client-side storage (IndexedDB)
+- GitHub Actions (CI/CD)
 - Testing
   - Unit testing with Jest
   - End-to-end (E2E) testing with Playwright and Mocha
@@ -28,8 +29,6 @@ If you are considering contributing to Swell in the context of a group or medium
     - WebRTC
     - OpenAPI
 
----
-
 ## How to download and test the application locally?
 
 1. Fork and/or clone the repository into your local machine
@@ -38,7 +37,7 @@ If you are considering contributing to Swell in the context of a group or medium
    - `npm run dev`
 3. Wait for the electron application to start up (it may take a bit)
 
-There is E2E testing available via `npm run test`. Note that not all tests in the E2E test suite work currently. Please refer to `./test/testSuite.js` for more details.
+There is E2E testing available via `npm run test`. Note that not all tests in the E2E test suite work currently. Please refer to `./test/testSuite.js` and `./test/subSuites` for more details.
 
 ---
 
@@ -71,11 +70,11 @@ From a functionality standpoint:
 - GraphQL stress testing with `Query`
 - Mock server for HTTP/2 (`Express`)
 - Ability to store historical requests and create/delete workspaces
+- Frontend conversion to TypeScript
+- From a codebase standpoint:
 
-From a codebase standpoint:
-
-- Partial conversion to TypeScript
-- Conversion to Redux toolkit _almost_ complete
+- Increase quality of TypeScript and continue converstion
+- Conversion to Redux toolkit _almost_ complete (need to implement hooks like useSelector and useAppDispatch)
 - Most working E2E testing (more details in `./test/testSuite.js`)
 
 ---
@@ -85,15 +84,21 @@ From a codebase standpoint:
 ### _Continue reducing the size and complexity of the codebase_
 
 This codebase has an interesting combination of over-modularization and code de-centralization/duplication occurring at the same time. For example - each type of API endpoint composer window (top right section of the app) is its own module/file, but a lot of the code inside is duplicated (see `Http2Composer.tsx` and `GraphQLComposer.tsx`).
-
+The reason many iteration groups have stayed away is becuase one would need to craft a function/component that is flexible enough to handle the population of the reqRes object and dispatch of the state to the vairous slices. This is not an easy task, and may take the entire iteration time allotted. It would be a worthy
 The impacts to the product are:
 
 - The codebase can be incredibly difficult to navigate if you are not familiar with the structure
+  - That being said, the file structure has been extensively modified to make the navigation much easier.
+    The most challenging aspects are the understanding how state flows through the application, from the front-end to main_process, controllers, etc.
+    This is the most important thnig to understant when iterating on Swell
 - The app is slow to load in all environments (production, development, test)
+  - Adding multiple entry points to for the build process would greatly improve this, but be careful because you can end up makiing performance much worse in the process
 
 **Some of us have found [ReacTree](https://reactree.dev/) VS Code extension incredibly helpful in visualizing the UI components. Utilizing the extension could be your entry into understanding the structure of the codebase.**
 
-As you iterate the product, keep in mind the footprint your new feature could add to the codebase. Could you re-use some of the existing modules? Can you even refactor and/or remove the obsolete code to help maintain the health of the codebase?
+As you iterate the product, keep in mind the footprint your new feature(s) could add to the codebase. Could you re-use some of the existing modules? Can you even refactor and/or remove the obsolete code to help maintain the health of the codebase?
+
+There are many parts of the codebase that break DRY principles, and with a such a large application, really keep in mind that when you add features it is completely necessary. Past iterators added an experimental feature(s) without it fully working and the next team(s) would add there own experiemental feature. Fixing features the past teams couldn't get to not only is a great way to learn these technologies, but is a great thing to talk to in interviews. " I fixed the webRTC feature that has been stagnant for 5 years", "I addressed the technical debt and reoganized the state...", or "Increasesed the quality of typeScript". These all show maturity as a developer and will allow to focus the entire time of OSP on the 20% problems.
 
 ### _Ensure consistent redux state management_
 
@@ -103,7 +108,8 @@ The redux state initiation and management for various API endpoints in this code
 
 For the following technologies - if you reference the gifs in `readme` and try to replicate the steps in the application you may not get the same result:
 
-- gRPC
+<!-- - gRPC -->
+
 - tRPC
 - OpenAPI
 
@@ -117,11 +123,13 @@ Moreover, the application lacks instructions on how to utilize some of the more
 
 Lastly, when making the app smaller on windows desktop or using a computer with smaller screen size, some of the buttons are partially cut out. It would be great to establish a minimum size for each section and/or input field so the application can auto-resize elegantly.
 
-### _Continue conversion to TypeScript, Material UI and Redux toolkit_
+You will notice that there are a few places where MUI is used. Material UI is a huge component library that is popular, though figuring out how to lessen Swells depence on it would go a long way to reducing it's bloat.
 
-Conversion to Material UI allows a more consistent component style and promotes semantic HTML language throughout the application. TypeScript provides strong typing to improve code quality, maintainability and reduce runtime errors. Redux toolkit reduces the amount of boilerplate requires to use Redux within the application and provide a centralized environment for state initialization and management.
+### _Continue conversion to TypeScript and Redux toolkit_
 
-### _Enhance HTTP/2 Mock server functionality; expand feature to GraphQL_
+TypeScript provides strong typing to improve code quality, maintainability and reduce runtime errors. Redux toolkit reduces the amount of boilerplate requires to use Redux within the application and provide a centralized environment for state initialization and management.
+
+### _Enhance HTTP/2 Mock server functionality_
 
 Currently, the HTTP/2 mock server has the ability to create a server that is accessible outside of the application, and create any endpoint that the user chooses. There could be a lot of potential to enhance the current mock server to include features such as:
 
@@ -130,30 +138,36 @@ Currently, the HTTP/2 mock server has the ability to create a server that is acc
 - the ability to mock HTML responses (or remove the HTML option from the BodyEntryForm component)
 - Connect the headers and cookies to the mock endpoint creation
 
-Moreover, the mock server functionality can be extended to GraphQL as well so that is something that can be considered in the future.
-
 ### _WebRTC STUN/TURN server input is read-only_
 
 The `RTCConfiguration` format required for WebRTC STUN/TURN server is an object with `iceServers` as the key and an array of objects as the value. With the current input format on the application, it is very difficult and error-prone to attempt to format the user input correctly. Based on research it seems like many other alternatives that test STUN/TURN servers separate each key/value into its input text box (similar to how key/value pairs for headers are done for HTTP/2 in Swell). Our assumption is that this way the application can have better control formatting `RTCConfiguration`. If anyone is considering advancing the current WebRTC functionalities in the future, this should be a priority so we can fully enable the ability to test any STUN/TURN servers using Swell.
 
 ### _Incomplete E2E testing coverage_
 
-Some of the following features either have broken, or no E2E testing coverage in the repository:
+Some of the following features either have broken, incomplete, or no E2E testing coverage in the repository:
 
-- gRPC
 - tRPC
 - OpenAPI
 - Mock server
 
 Future iteration should consider fix or add E2E testing coverage for these features.
 
-### _Broken Travis CI build_
+### _CD pipeline is incomplete_
+
+Continuous Integration has been implemented using GitHub Actions. If you would like to edit workflows or add new ones to the pipeline, here is the process that we employed to test new workflows before using them on critical branches like main and dev:
+
+- Create two test branches (ex: ci-draft and ci-main)
+- Define a workflow in a yaml file and test its execution by pushing it to ci-draft and/or opening a pull request to merge ci-draft into ci-main depending on the triggers you have defined in the workflow
+- Make any necessary adjustments to the workflow and continue testing it on ci-draft and ci-main until the workflow is functioning as intended
+- Finally, open a pull request to merge the new workflow into the dev and/or main branches
+
+The idea is to troubleshoot new workflows before applying them to the dev or main branches. 
 
-The [Travis CI link](https://travis-ci.org/open-source-labs/Swell) is not functional. A broken CI/CD pipeline blocks the ability to automatically package and release new iterations of the application, so it would be great if we can rebuild CI/CD using alternative services like GitHub Actions.
+A Continuous Deployment pipeline would be an advantageous addition, as its absence blocks the ability to automatically package and release new iterations of the application. The groundwork for it is there (see the “scripts” and “build” properties in package.json) but packaging for Linux will need some attention, as outlined in the next section.
 
 ---
 
-## How can I package and release the application without a functional CI/CD pipeline?
+## How can I package and release the application without a functional CD pipeline?
 
 There are a few options to package an electron app for production. Some of the most popular options are electron forge and electron builder, and Swell uses electron builder currently.
 
@@ -163,7 +177,7 @@ While electron builder supports [multi-platform build](https://www.electron.buil
 
 For Mac users, running `npm run package-mac` and `npm run package-win` (as defined in `package.json`) would allow you to package the Swell app for Mac and Windows environment. If you try to package for the linux environment (i.e. `npm run package-all`, `npm run package-linux`, `npm run gh-publish`), you will run into issues requiring `snapcraft` and `multipass` to create a linux virtual machine in order to package the application. You can try to install `snapcraft` and `multipass` via `brew` per instructions, but there has not been much success locally.
 
-The only remaining option to build a linux package for MacOS users is via a CI/CD tool like Travis CI or GitHub Actions but the pipeline is not functional in the Swell repository. **To work around this limitation without building a new CI/CD pipeline, we recommend you ask a developer with a WSL or Linux environment to help you package the application.**
+The only remaining option to build a Linux package for MacOS users is via the CI/CD pipeline but the CD portion is not yet implemented in the Swell repository. **To work around this limitation without building a CD pipeline, we recommend you ask a developer with a WSL or Linux environment to help you package the application.**
 
 - Ask the developer to clone the project into their local WSL/Linux environment. **The user does not need the ability to open the electron application.**
 - run `npm install && npm run package-linux`