smashingboxes / boxcar Goto Github PK

CC: @ecexplorer
This probably deserved its own milestone, but figured if we are discussing these things now, we should be moving in this direction as well

https://docs.travis-ci.com/user/caching/

Motivation

I think this would be great for monitoring apps and finding / understanding bugs throughout the full stack on a live production server.

Requested Feature

It would be useful if we could log errors and other events from both the front and the back end.

Example (frontend):

    try {
      foo()
    } catch (e) {
      // handle error
      logger.log({
        error: e,
        description: 'something something failed when something',
        //...
       })
    }

The logger on the frontend would have to send logged events to the back end with http requests. On the back end all logged events would have to be persisted.

Now even though the error was handled, we could use the logging solution to show us all logged events (of both the front and back end) during a specified time frame and filter for certain keywords.

Monitoring Solutions

We'll want to set this up in a way that doesn't tie the project to a certain authentication strategy.

Here's some of the strategies we might want to support

• No authentication
• Devise session auth?
• devise_token_auth
• JWT
• Oauth
• SAML

Right now, our erb code does not get linted at all, because rubocop does not handle that. We've tried the erb-lint gem and liked it, so we should pull it in here

• Update yarn build to something like cd frontend && npm run build && cd .. && rm -rf public && mkdir -p public && mv frontend/build/* public && mv public/index.html public/frontend.html
• Add docs describing the monorepo setup
• Add links to that doc from app/assets and app/javascript

Some reference
https://redux.js.org/faq/organizing-state#should-i-put-form-state-or-other-ui-state-in-my-store
Basically, redux says you probably don't need your form state in redux. So, I agree 😄
Their first recommendation: just write it yourself
Their second recommendation: https://goshakkk.name/on-forms-react/
The third, and probably best (?) option, Formik https://github.com/jaredpalmer/formik

Whoever pulls this story should read the above articles, play around with at least the second and third options (we've all done the first in some capacity), and document what they found, and their recommendations moving forward. I can see this getting pulled into an Allhands potentially.

This is dependent upon #14

I can update the documentation around how this will work, but I have all the code for these in personal repos, I just need to include it in boxcar.

Reference PR: https://github.com/smashingboxes/transenterix/pull/44

We'll want to set this up in a way that doesn't tie the project to a certain authentication strategy.

Here's some of the strategies we might want to support

• No authentication
• Devise session auth?
• devise_token_auth
• JWT
• Oauth
• SAML

This will more than likely be worked in tandem with #45

TODOs

• Set up auth on the backend, with a User model
• Seed a user object
• Connect frontend to backend auth, as an example of how to use redux and save tokens

Libraries Needed:

• fetch-mock
• sinon
• enzyme
• faker.js
• redux-mock-store or a good store mocking package

Overall I believe these are pretty good articles on setting up some of these libraries:
https://www.leighhalliday.com/testing-react-jest-enzyme-sinon
https://medium.com/codeclan/testing-react-with-jest-and-enzyme-20505fec4675

Admittedly, I don't use prettier or husky, and the 15 minutes I spent to set them up didn't seem to work.

TODOS:

• install husky and any needed dependencies
• set up the rules we all agree upon to get husky doing the right things pre-commit.
• update the Readme.md to explain what husky is and what we are using it for.

Currently we are trying to define what it means to use redux in a standard manner for our apps going forward. However, as a first pass, I recommend we see the structure/patterns used in Koru, and follow those for now.

While they are not 100% ideal as far as the boilerplate created, I believe this approach makes it very clear what an action is doing, and leverages strongly typed actions as well.

TODOs:

• Add in the following libraries: redux, react-redux, redux-thunk, redux-devtools-extension
• Follow the patterns in the configureStore.ts file to connect all of the reducers.
• Add in a blank reducer, auth, which just returns the initial state it was passed.
• Add in a unit test around this reducer, and any actions included.

This is blocked by #14 because we need a user model in order to add roles to it.

I've used these in the past, basing the generation off of a swaggerdoc, but we have also been a discussion of moving to graphQL. This is more a braindump to see if anyone has any knowledge around this, and how to move forward if so. graphql-code-generator could be a helpful tool, but i don't know much about it.

Much like our PR template, we should create a standard Issues template, so they all follow a similar format.

Pieces that have already been included in the first commit that have not been well-documented

• find and replace any references to boxcar
• what to replace in the /frontend/public folder when bootstrapping a new app
• notes on how to run vscode debuggers
• documenting what linting rules we change and why. Currently we don't change any.
• If the app is react, delete react native and vice versa (note this will only be valid if we create a RN app inside boxcar as well)
• how to use the bundle analyzer command
• how to use react-intl

rswag is a gem for creating swagger docs from request specs. The specs have to be formatted in a certain way, but in my opinion, this can completely replace the way we currently do request specs.

Here's what a spec looks like:

require "swagger_helper"

describe "Gopher API", type: :request do
  path "/api/v1/orders/{id}/flag" do
    post "Creates a new flag" do
      tags "Orders"
      consumes "application/json"
      produces "application/json"
      security [access_token: [], token_type: [], client: [], expiry: [], uid: []]

      parameter name: :id, in: :path, type: :integer
      parameter name: :params, in: :body, schema: {
        type: :object,
        properties: {
          reason: { type: :string },
          description: { type: :string }
        }
      }

      let!(:order) { create(:order) }
      let(:reason) { Flag.reasons.keys.sample }
      let(:description) { Faker::Lorem.sentence }

      let(:id) { order.id }
      let(:params) { { reason: reason, description: description } }

      before { @flag_count_before = Flag.count }

      response "200", "Valid Credentials, Valid Params" do
        let(:current_user) { create(:user, :gopher) }
        include_context "when auth headers are included"

        schema type: :object,
               properties: {
                 id: { type: :integer },
                 reason: { type: :string },
                 description: { type: :string },
                 order_id: { type: :integer },
                 user_id: { type: :integer },
                 created_at: { type: :string, format: :date },
                 updated_at: { type: :string, format: :date }
               }

        run_test! do |response|
          json_response = JSON.parse(response.body)
          expect(Flag.count).to eq(@flag_count_before + 1)
          created_flag = Flag.find(json_response["id"])
          expect(created_flag.reason).to eq(reason)
          expect(created_flag.description).to eq(description)
        end
      end

      response "403", "Unauthorized" do
        let(:current_user) { create(:user, :requestor) }
        include_context "when auth headers are included"

        description "This probably means you're not signed in as a gopher"

        examples "application/json" => {
          "meta" => {
            "success" => false,
            "message" => "Unauthorized."
          },
          "errors" => [
            "Unauthorized."
          ]
        }

        run_test! do
          expect(Flag.count).to eq(@flag_count_before)
        end
      end
    end
  end
end

and here's what it looks like in swagger:

Activeadmin assets are still in the asset pipeline, so we need uglifier for the compilation process.

We should only be using secrets.yml for actual secrets. We should have another file for settings.

Native fetch?
Axois?

Whatever we implement, we need to standardize the way a base api/api controller is instantiated, and the way in which to send network requests, deal with failures, manipulate/handle headers, etc.

Pretty Self Explanatory

TODOS:

• Add react-router
• Add in a dummy route that links to a new component, showing how we define routes at the root level
• potentially tests around the new app, or updating a dummy component for testing that is wrapped in the appropriate provider
• Update the Readme.md to reflect that we use this library, and links to any pertinent documentation
• Add a generic 404 page. This is important because with the monorepo setup, all 404s will be sent to the frontend

A standard library we can use to persist data to local storage.

TODOS:

• add in redux-persist and follow the docs to get it wired up.
• Add either a whitelist or a blacklist, so it is clear how those work
• Update the Readme.md to reflect on how to use redux-persist, even if this is just a link out to official docs, and links in the repo to any relevant files.

Ideally, each of our repos should have instructions for how to deploy, in some standard place. A DEPLOYMENT.md is one place we could put that.

An example of a pretty well supported plugin for Material UI:

• https://github.com/react-theming/storybook-addon-material-ui
• https://storybook.js.org/

Personally, I don't see a lot of benefit in this one, considering how different our apps are, but if we do go down the route of a repo for shared components, This could have some pretty solid benefits, as far as documentation and onboarding are concerned.

This should probably wait until after #14

Since create-react-app v3 you can configure your app to use absolute imports (= relative to a top-level folder, e.g. src). I think this would make imports easier to write and more readable.

Example:

// tsconfig.json
{
  "compilerOptions": {
    "baseUrl": "src"
  },
  "include": ["src"]
}
​
// before
import Button from '../../Button/Button'
​
// after
import Button from 'components/Button/Button'

Here's a good example config: https://github.com/smashingboxes/pr-mate/blob/master/config/initializers/airbrake.rb

One thing to note: The project_id and project_key change on every project. The easiest way to handle that is probably ENV variables.

Pin gem versions to minor versions (eg ~> 1.2), so that bundle update <gem> works without breaking changes.