Internal Q&A - Sai

[harshasrikara]

Ask questions & document answers

Each officer must ask 5 questions that they come up with when exploring the various codebases. Will be checked off once the answer to those questions has been documented. Codebases to review:

• portal
• portal-backend
• Development

Officer --> @Balstun

How to complete

Post questions as comments to this issue. Once comment receives a :+1: (will receive a thumbs up if there isn't already documentation surrounding the question) write the documentation for it & link it. That will result in the task list being checked off. Rinse and repeat 5 times. Ask as many questions as you have! :grin:

Q&A Checkoff Set 1

• [ ] Q1 & Documented
• [ ] Q2 & Documented
• [ ] Q3 & Documented
• [ ] Q4 & Documented
• [ ] Q5 & Documented

[Balstun]

The ACM Authentication Flow template, which is currently failing its automated tests, asks developers to Create an Auth0 Account. However, the link is currently broken. I can see from the later documentation that it specifically asks for an Auth0 account, when it specifies the packages to be installed. Are there specific instructions to follow when creating an account, such as joining a team/organization? I'm not familiar with this particular service yet, hence my question.

[harshasrikara]

We use Auth0 to handle sign in across various applications. Auth0 refers to each "group" or domain as a tenant. An invitation to join the acmutd tenant has been sent. You will be able to view user accounts + manage roles/permissions + more on there.

Regarding the automated tests which are failing its because process.env.CI is set to true. This means that it treats any warnings that might happen during the compile step as an error. In this situation there's an unused variable which is causing that error to appear. Removing that variable will fix it.

Other Notes about that repo: One additional change that needs to be made for that repo is to update the ExternalApi component to make an actual API call to a debug endpoint on ACM Core to show how authentication is required for making api calls. Also would be nice if we could add a GitHub workflow to automatically compile + deploy the built version to a gh-pages branch with the associated environment variables. There's already a workflow that does this in the portal repo. Copying this over with a few minor changes should do it & we can add a DNS record to show this off as a proper template that has a deployed demo. Can convert all this additional info into a GitHub issue for that repo.

[Balstun]

As a new Dev Officer, will I have 2 weeks to complete the various challenges outlined in the Development repository, or will the timeframe vary? More specifically, when do my 2 weeks start? I would appreciate it started the Monday after our team onboarding session, but I would like to confirm. On another note, I read about the challenges and projects for Dev Officers to be done in Summer 2020. Will we have a similar experience this Summer 2021? Or should this be something we can discuss at a later date? I also wanted to know if it's by this time that a Dev Officer should be prepared to pursue his/her own project.

[Balstun]

My understanding of Redux is that it is used to store global states, compared to the local states utilized by React hooks. But how exactly does Redux interact with Firebase? I would appreciate it if you could point me to a few GitHub files to better understand their relationship. I will soon learn more about Redux and how to utilize it over the next few weeks working with ACM Portal and ACM Portal Backend.

[Balstun]

When working with Typeforms and Sendgrids, are there certain restrictions we have to follow? I don't know if I can access the form currently to look into the inner mechanics.

[Balstun]

Are there certain errors we should be more aware of when developing, certain errors we should check with either Node.js Sentry, or by try/catch?

[Balstun]

When publishing new changes and developments, utilizing branches is the best way to ensure no unsatisfactory changes are made to the official website/service. Are there certain restrictions to adding new branches I should be aware of? Such as, only using a new branch for a specific feature or major issue being targeted? An addition to this question: I know you mentioned incorporating GitHub actions this year in ACM Development; Is this something I/we will need to explore with regards to creating new branches and the like?

[harshasrikara]

As a new Dev Officer, will I have 2 weeks to complete the...

Current Dev Officers do NOT need to complete the dev challenges found in the Development repo.

Backstory: Over the course of the past year we explored various different ways to onboard new team members. An initial set of challenges existed for officers who wanted to join prior to Summer 2020. However, those were far too easy and did not really translate to helping us identify talent in the applicant pool. The current challenges in the Development repo were created for students who chose to apply in Fall 2020. These proved to be significantly more challenging and caused a dip in the ratio between applicants to people who completed the challenges. Beginning in Spring 2021, we switched to the current format for recruiting. Application --> Review --> Interview --> Selection. If are interested in trying the challenges just for fun go for it!

On another note, I read about the challenges and projects for Dev Officers...

Because of the vast breadth of projects in ACM (not just specific to Development) our first priority as a team is to ensure that all officers are strongly familiarized with certain subsets of the various codebases. For the foreseeable next ~2-3 months all new officers will focus on the 3 repos mentioned at the top (and those themselves are quite extensive so likely each officer will find a niche in it that they want to specialize in). Following this time period and by the time summer rolls around you'll have the opportunity to either expand significantly upon one of these projects themselves or if you so wish start a new one that you believe will benefit ACM / student community.

[harshasrikara]

My understanding of Redux is that it is used to store global states, compared to the local states utilized by React hooks.

Correct, redux is for storing global state. However, although the portal repo does have Redux setup it doesn't actually use Redux for storing state.

Instead we use a new and upcoming library called Recoil for managing global state. While not as versatile as Redux, its significantly easier to use & looks much more cleaner in the codebase. It also works really well with features like React Suspense which while experimental I've found is great for handling UI during data loading. I would recommend familiarizing yourself with the basics of recoil such as atoms, selectors, async selectors, etc. Recoil state is setup here. The actions folder in /src/api/actions contains the logic to populate those states. Once the data is populated accessing it within a React hook is very very simple. Here's an example. Here we're basically saying fetch whatever is in the recoil selector called profile. Recoil is also smart about populating global state. If we aren't on a page of the site that requires the data then recoil won't bother making the api calls to load the data. In this situation when we land on the profile page, recoil fetches the data through the action in /src/api/actions and saves it in the state and makes it accessible to the component.

how exactly does Redux interact with Firebase

Note: Answering how recoil interacts with firebase (Redux is setup for the project but not actually used)

One important part of good architectural design is to never have the front-end communicate directly with firebase / firestore for data. Anytime we want data the ACM Portal will make an api call to the ACM Core API (the portal-backend repo). The core api is basically a simple restful service that acts as a middle man for fetching the data (and also writing data when that's necessary). All the logic for making the API calls to populate the data are in /src/api/actions. Another good architectural design is to never mix UI components and data together. This means that keep the UI in a separate file than the data files. Ideally none of the React components should make any api calls to fetch data. They request Recoil for the data and recoil will call an action to populate the data if not already present.

Example files

• UI Profile Component
• Recoil Profile State
• Recoil Action to populate the Profile State

[harshasrikara]

When working with Typeforms and Sendgrids, are there certain restrictions we have to follow?

• Typeform API Documentation
• SendGrid API Documentation

For Typeform its unlikely that we'll need to work with their API very much. Most of our actions are very Webhook driven. Anytime a typeform is submitted the data is sent to the ACM Core API which has an open endpoint for receiving typeform submissions. Logic to parse type forms and save it in a much more simpler format is already written here. Its very likely that you'll have to just interact with the output of that which has the data in a much cleaner format. Documentation around how typeform is connected to ACM Core & in many situations how we secure type forms through SSO like the vanity form is documented in google drive under ACM General > How To Guides > Dev Documentation > ACM Zero Trust.

I don't know if I can access the form

If you sign in to firebase with your acm account and open up Cloud Firestore you'll see a collection called typeform that has all the submissions. You can inspect the schema that its saved in and more on there.

[harshasrikara]

Are there certain errors we should be more aware of when developing, certain errors we should check with either Node.js Sentry, or by try/catch?

For the ACM Core API wrap all async functions in a try/catch block. Send all captured exceptions to Sentry. More documentation on sentry is present in Google Drive under How To Guides. Because of the nature the API is setup exceptions need to be purposefully sent to Sentry else they don't get captured which is why you'll see most files/functions have a Sentry.captureException(err) statement in the catch block. The portal repo for the frontend is much simpler. Its already configured to send all errors to Sentry regardless of how/where they get thrown. Basically a one-time setup which has been completed and therefore no need to worry about it.

[harshasrikara]

When publishing new changes and developments, utilizing branches is the best way

Yes, always create a branch for working on new feature / fix / etc. The default branch for both the portal repo and portal-backend is currently set to the dev branch. You can make a branch from the dev branch and label it along the lines of feature/stuff-goes-here, fix/stuff-goes-here, or internal/stuff-goes-here. After completing your changes you can open a pull request to merge it to the dev branch. To be able to merge a pull request, your PR must get reviewed by another developer on the team. This is to ensure that more than one person is aware of changes being made and also to catch any potential issues that might be present. Once a month after completing a series of feature additions / bug requests we will merge from dev to master and create a new tagged release. Gist of it is always create a branch for everything that you might need to work on. Committing directly to either the dev branch or master is not allowed.

An addition to this question: I know you mentioned incorporating GitHub actions

There are several GitHub actions already setup to handle pull request checks and more. You can view all the GitHub action workflows under the .github/workflows folder for either repo. These checks will ensure that your code can compile, follows good coding practices and more. Essentially responsible for running an automated suite of tests against all PRs. There are no changes really required for these workflows since they've already been created.

Some workflows that do require updates have issues opened on them. The portal repo has a GitHub action for an automated deploy to GitHub Pages in lieu of using Heroku. That workflow needs minor updates before it can be used for production. The portal-backend has a GitHub workflow for testing automated compile & deploy that errors out on one of the uses steps. That has an issue opened for fixing it.

[Balstun]

I've been reading through the Dev Documentation, particularly the How-To Guide for LogDNA. I noticed that the Github Student Developer Pack provided LogDNA for a year. But if I were to activate it this year, I won't be able to utilize the service the year after right? So when should I activate it? Or should I avoid using it for the moment? (I believe it would be best to wait until I'm more involved in a repo to use the service in the first place.)

[harshasrikara]

I've been reading through the Dev Documentation, particularly the How-To Guide for LogDNA

Go ahead and set it up now. In a year who knows if we'll still be using LogDNA or if we will have switched to another company. A lot can happen over that much time.

[stevenmqnguyen]

Closing - add contents to wiki.