matthewkmayer / refeed-rampage Goto Github PK

Should we load test?

A big win is probably not creating a new DynamoDB client on every request that hits the DB.

Should we be concerned with backend instrumentation? Specifically performance things like response fulfillment time.

Get a baseline before changing things in the name of performance.

Meals should have a star rating associated with them.

The frontend is requiring some refactors to apply better patterns. To ensure we don't break existing behavior we need to bulk up our tests to be able to ensure we don't miss something.

What if the Lightsail VPS goes away?

A real one provided at build time.

See https://gist.github.com/WesThorburn/62ea13952749d6563ce2fb15b45f1ba8 .

Lighthouse tool in Chrome suggested this.

cargo build --release only for tagged commits.

As per https://seed-rs.org/guide/server-integration we can structure things so it's only updated in one spot.

Navbar disappears 🤔

First pass: store creds in the database and expose a new endpoint for signing in, returning a JWT.

Later we should try github auth or twitter or something so we don't have to manage creds.

First pass checklist:

• add login endpoint to backend with hardcoded user/pw
• save bits returned in session/local storage
• return a JWT after login ( https://github.com/Keats/jsonwebtoken )
• send auth header on requests
• auth with JWT on backend - in memory store at first, then dynamodb for session storing?

Make it easier to see where we are.

Reloading the page shouldn't remove our auth details

Let's keep our entire build time down to three minutes.

We're at ~5.5 for the longest step of the parallel jobs right now.

Whoops

The Login link in the upper right should switch to Logout if the user is authenticated.

We should run smoke tests after deployment has completed. This is from #13 .

First step could be verifying the tag was released. Requires #29 and #28 .

It's "pay off" not "pay odd."

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Query.html

This should be usable on the web.

First step is deploying the frontend. We can see about deploying the backend to Lightsail or other easy to deploy setup.

the checklist

• spin up lightsail instance
• set up perms for Dynamodb and verify with aws cli
• set up VPS with nginx, let's encrypt, etc...
• make new ssh key
• have deployments on tags push something to the instance like a text file
• do real deployments with backend and frontend
• post test deploys (another ticket?) #31

Need a guideline of when to consider the project done and in maintenance only mode.

Navigate to meal list page. Click a meal. Click back. See nothing happens.

It should go back to meal list page.

Same behavior with editing a meal: back button doesn't go back to meal list.

This should be an automated test. 👍

We're on the west coast, let's use carbon-neutral us-west-2. 🎉

If we're going to use SCP and SSH actions from others, lock down the version instead of using latest.

See https://rustwasm.github.io/docs/book/reference/code-size.html .

parent ticket for doing JWTs right

Work to do:

• backend: login should return the session jwt and refresh jwt (refresh jwt in an httponly cookie)
• backend: new endpoint: /refresh should take only the refresh jwt and give a new one
• backend: reject expired JWTs
• backend: reject refresh JWT used as auth
• frontend: handle new login bits of two tokens
• frontend: see if session jwt has or will expire soon and get a new session token via refresh token (should work after not having the tab open for 15m)

Resources:

• https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/
• https://auth0.com/docs/tokens/guides/store-tokens

original ticket

Right now we're using JWTs as long lived instead of issuing a 15 minute token and a refresh token. We should do the right thing with keeping the refresh token around and using that.

See #39 for info on how the JWTs should be used.

Fix it up

GHA tests appear to fail out because they can't find AWS creds. Try providing some via env vars. Fake ones should be accepted by local dynamodb.

Taiko and Gauge?

GitHub Actions please. 😄

The WASM file isn't gzipped coming out of nginx and it could be.

https://docs.nginx.com/nginx/admin-guide/web-server/compression/

https://github.com/h5bp/server-configs-nginx/blob/master/h5bp/web_performance/compression.conf

Similar to #28 but for frontend.

Maybe a tiny bit of text at the footer?

Should we keep people from steamrolling things? Especially the backend, when we don't have auth yet.

Standard cmake should be fine.

We can use the Java local dynamodb for testing.

The local dynamodb container takes a while to start. We should figure out how to wait for it to come up and be available before moving on instead of the sleep commands we have now.

Curl? Ping? docker ps | wc -l ? Bash while loop?

We could use nginx as a reverse proxy to the backend service and to serve html.

A stepping stone to go from running "serverless" on ECS Fargate to Lambda functions instead of the warp backend and S3/Cloudfront instead of nginx.

We've got a bunch of differently styled buttons and we should change 'em to be the same style.

A technology compatibility kit (TCK) is a service that acts like another service, but is mocked and is faster.

For the frontend behavior tests, we can replace the real backend with https://github.com/gomicro/duty . To ensure it works the same as the backend, we'll run the same backend tests against it to catch any drift.

This should help achieve #9 .

https://github.com/bbqsrc/cucumber-rust ?

We should use the git tag to say what version we're running. Lets us verify deploys and know what's running.

Right now we dump the entire error message to the page. We should display what went wrong without lots of detail that's not meaningful.

Dump full error to console and state what went wrong and what could maybe be done. "Couldn't reach the API, please try again."

https://material-ui.com/ ?

We'll need support in the backend and frontend.

Probably Let's Encrypt.