Improve our app to prep for lambdas. #113
Conversation
Codecov Report
@@ Coverage Diff @@
## master #113 +/- ##
==========================================
- Coverage 70.47% 70.37% -0.10%
==========================================
Files 86 87 +1
Lines 3948 3965 +17
==========================================
+ Hits 2782 2790 +8
- Misses 894 904 +10
+ Partials 272 271 -1
Continue to review full report at Codecov.
|
| @@ -145,10 +145,11 @@ export function useGame(): Result { | |||
| const { currentUser } = useAuth(); | |||
| const { setAlert } = useAlert(); | |||
| const dispatch = useDispatch(); | |||
| const base = `https://lambda.hobbycribbage.com`; | |||
There was a problem hiding this comment.
🔮 In the future, it may be prudent to upload a settings.json as part of our SPA bundle that we can independently update without making a code change.
Then again, making a code change on a hobby project is just as fast so 🤷
There was a problem hiding this comment.
I agree. I don't know how to do that. What's the trick?
There was a problem hiding this comment.
It's a bit more work than this (obviously), and it's been a while since I've done this, but generally:
- We'd have to know the name of the bucket from which the CDN distributes our bundle (CDK would give us this)
- We'd have to upload
settings.jsonto that bucket, as a sibling to ourindex.html - We'd have to handle uploading that with our deploy -- in the past, I've used a separate
ts-nodescript and apostdeploynpm script in our CDK package to do this (notes about post* scripts) - We'd also want to tell our CDN to invalidate the cache for
settings.jsonso our clients get the updated version - Ideally, we'd also want an easy way to upload something there independently of our deploy since that's the whole point of this
This smells like a separate PR to me.
| @@ -21,6 +21,7 @@ export function useActiveGames(): ReturnType { | |||
| const { currentUser } = useAuth(); | |||
| const { setAlert } = useAlert(); | |||
| const dispatch = useDispatch(); | |||
| const base = `https://lambda.hobbycribbage.com`; | |||
There was a problem hiding this comment.
At the very least, we might pull this out into a separate file so it can be shared in all the places it needs to be. Perhaps we could make a cribbageClient of some sort that's constructed with a base URL and takes relative paths for requests.
There was a problem hiding this comment.
💡 Right now, these are all the same because we're using lambdas for everything. Someday, we could have a "games" service, and a "recommendation" service, and a "AI hand identifier" service. In each of those, they might hit different subdomains.
Perhaps, it's best to have a gameBaseURL var that we would use for all of the current usages...
There was a problem hiding this comment.
I'm fine with that. We could also say YAGNI and keep it baseURL until we need something different, but my main concern is centralizing the value of it, and the identifier is more :meh: to me
💡 🔮 Maybe it would be fun to learn about OpenAPI/Swagger and get it to generate a TypeScript SDK for us based on our games API spec
server/persistence/dynamo/utils.go
Outdated
| @@ -10,7 +10,7 @@ import ( | |||
|
|
|||
| const ( | |||
| dbName = `cribbage` | |||
| partitionKey = `DDBid` | |||
| partitionKey = `gamesV1` | |||
There was a problem hiding this comment.
📖 Is it a good idea to name our partition which stores games, players, interactions, etc. gamesV1?
There was a problem hiding this comment.
true. I guess it should be descriptive of what's in the value attribute field. Perhaps uuid or simply id? I like something that's "unique enough" so it's easy to correlate and search for in the code. Maybe cribbageID?
There was a problem hiding this comment.
cribbageID sounds good to me. I suppose this is one of the idiosyncrasies of dynamo preferring one table for storing many types of things 🤷
| router.GET(`/backdoor`, func(c *gin.Context) { | ||
| c.String( | ||
| http.StatusOK, | ||
| `The front door is open. Come on in!`, | ||
| ) | ||
| }) |
There was a problem hiding this comment.
Do we need to keep this?
There was a problem hiding this comment.
🤷 I like it. It's an easy way to test that the lambda is deployed. And it's occasionally fun to have easter eggs.
What broke / What you're adding
lambdas are almost ready (see #111). There's some things that'll be good to have in before that. let's do that.
How you did it
DDBid->gamesV1define a baseURL in the client network requests (so that we can hit a different domain).
add CORS to http request handling.
add a backdoor endpoint to see if its working or not.
How to test it and how to try to break it