JavaScript API Consumption Exercise

[r002]

Friday

Tasks

• [x] Create a Starter Repo template in GitHub
  • [x] Make a Frontend Starter template
  • [x] Write basic code that consumes from public API
    • [x] Vanilla (no-auth)
    • https://r002-starter.web.app/ghClient.html
    • [x] With OAuth and API Key
    • https://us-central1-r002-starter.cloudfunctions.net/getDogs?limit=2
  • [ ] Write some basic Jest testing templates
  • [x] Make a Backend Starter template
  • [x] Set up GCF CORS proxy
    • http://localhost:5000/tetrisClient1.html
    • Directly pings https://ctwc-cloud.appspot.com/v1/match/ctwc_2014_r5-01 - fails
    • http://localhost:5000/tetrisClient2.html
    • Pings https://us-central1-r002-starter.cloudfunctions.net/hardProxy which is a hard-proxy - succeeds
    • http://localhost:5000/tetrisClient3.html
    • Pings https://us-central1-r002-starter.cloudfunctions.net/corsProxy/https:/ctwc-cloud.appspot.com/v1/match/ctwc_2014_r5-01 which is a generalized-proxy - succeeds
  • [ ] Write basic code that consumes from public API
    • [ ] Vanilla (No Auth)
    • [ ] With OAuth and API Key
  • [ ] Write Jest testing templates
• [ ] Make a Google App Scripts starter template project

---

Case #1: This fails when we try to directly query the resource because its header is missing ‘Access-Control-Allow-Origin’:

Case #2: This succeeds because we use a CORS proxy to add ‘Access-Control-Allow-Origin: *’ to the response headers:

---

Step 1:

• [ ] Consume public JSON API from frontend JS
  • [ ] If server isn't configured to deliver cross-origin (eg. 'Access-Control-Allow-Origin: *'), resort to CORS proxy
  • [ ] Set up my own CORS proxy server
• [ ] Consume public JSON API from backend JS
• [ ] Consume public JSON API from Google App Scripts

Step 2:

• [ ] Wrangle data

Step 3:

• [ ] Write good tests
  • [ ] Use Chai/Jest/Mocha? https://www.theregister.com/2021/01/14/javascript_survey_jest_webpack_on/

References

• https://stackoverflow.com/questions/46673210/curl-d-parameter/46673681
• https://www.petfinder.com/developers/v2/docs/
• https://stackoverflow.com/questions/39297345/fetch-resolves-even-if-404
• https://stackoverflow.com/questions/55498693/how-to-really-call-fetch-in-jest-test/55506587#55506587
• https://stackoverflow.com/questions/39565706/post-request-with-fetch-api
  • https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
• https://firebase.google.com/docs/functions/get-started#deploy-functions-to-a-production-environment
  • https://firebase.google.com/docs/functions/config-env
  • https://firebase.google.com/docs/functions/local-emulator#set_up_functions_configuration_optional
• https://github.com/matthew-andrews/isomorphic-fetch

[anitabe404]

Interesting. I sparked a TDD discussion on Twitter and someone mentioned that they found writing tests for JS difficult. I hadn't looked into it, so I didn't know what tools were out there to conduct JS testing.

[r002]

@anitabe404 Yeah-- up until this week, I was most recently predominantly writing tests in Go and didn't have much formal JavaScript testing experience either. So I've been trying to figure out the JS landscape. It's weird because in Go all testing is just built into the standard library. So there isn't any need to seek out third-party testing frameworks like the way it works in JS. I poked around the internet and found Jest, Jasmine, Chai, and Mocha. They all have various affiliations (like "good for React" or "good for Angular") but from what I read, at least in the time I spent, Jest seemed like a well-liked framework that also worked well with just vanilla JS. (Also, other devs I follow seem to like it so that was encouraging!)

TDD and different testing paradigms is a total world unto itself. 🙂 In my own experience, a lot of what specific paradigm you ultimately use is actually driven by team culture-- like if it's a TDD shop you eventually land at, there's just a straight-up process for how all developers develop. Ie. You write the failing tests first, then the code, then pass all the tests. Or: Every time there's a PROD fix, you write a test that verifies that exact breakage can't ever reproduce in the same way again. Etc. Like-- the team has a process; that's the process all peer-code reviews are checked against; and so it's very clear and everyone just follows it. Which is good! 🥳

(Or-- to share a horror story from one of my past lives in my more junior days: The team you land on doesn't write tests at all! In that case, I ended up also not writing tests either. Testing was always a series of manual GUI checks we did every time we did a new release. As you might surmise-- eventually this grew incredibly onerous... oh, how we suffered... 🤦‍♂️😤)

When I've been on my own though, I've been more lax with my tests. I've had the luxury of developing solo so there's that. But I definitely also still do write tests because the idea is to be able to get one's code to a state --especially once it starts getting larger-- where you can always make changes confidently. So you can move fast and not break things. ☺

[anitabe404]

@r002 Wow, no tests sounds like an absolute nightmare. And yes, a lot of it is dictated by the team/group you're in. There were some pretty strong opinions against TDD. I'm not a TDD purist; I can see some scenarios where writing tests after the code is written could be okay. I think going out without automated tests is too extreme. I've been taking a TDD approach to my project and I enjoy it. It forces me to think. Although there have been moments where I coded first to get a better understanding of what I was trying to do before going back and writing/updating tests.

But yea, I got a few people going on Twitter. 😂

[r002]

But yea, I got a few people going on Twitter. 😂

LOL 😂

It forces me to think.

Totally this!! One of the absolutely best parts about writing tests is that it forces you to properly think about encapsulation and all the different/proper/useful ways to break apart your code into what abstractions. Totally 100% agree! Writing tests is the way! 😄