RFC: Starter Template: Third Party query example & best practices

[benjaminsehl]

In the starter template today we don't provide any guidance around how to query third party APIs and what the best practices are around things like caching and error handling.

An idea that I'd discussed with @timlombardo was to provide a resource route that might act like a dummy API that we could query, and given different search parameters, have a predictable result.

For example, fetching /dummy-api?response-code=500 would return a 500, which you could then test out how an Error Boundary works, etc. Other things like /dummy-api?throttle=true could be useful.

[timlombardo]

Couple of questions:

• Do we need to provide a dummy example or could we refer to an actual 3P example as best practice?
  I think the benefit of the dummy example is being able to test out the scenarios more easily and learn from it a bit more, where as with an actual 3P example you probably just need faith that it handles errors the way you're hoping. (eg switching between the good state and error state will be helpful)

• Does this fit in the scaffolded template out of the box or is it an example we can refer to?
  If the former, would it be cruft that must be deleted or does it all live in a dummy route thats out of the way. If the latter, how do people discover it?

[frandiox]

I feel like an example integrating with Sanity / Contentful / etc would be better (as in an example project unrelated to skeleton)? That way it's a real API and we can add real error-handling.

[juanpprieto]

I like this, but I am a bit confused with the main goal(s).

On one hand, it seems that we want to have a reference example/implementation on how to integrate a 3P API / client using best practices (caching etc).

On the other hand, it seems like we want to have an internal v-route we can use to test various error handling layers associated with 3P API calls?

If yes, I think it might be worth splitting into two separate RFCs.

[filipedeo]

https://httpstat.us/ is an example of a 3p tool that provides a "dummy-api" experience for pretty much all status codes out there. Something like /dummy-api?throttle=true essentially translates to a 429 (too many requests) status, like this one: https://httpstat.us/429. This also supports delaying a response and extra headers. Would we need anything beyond standard use cases? E.g. anything shopify-specific?

I wonder if we could just focus on the best practices side of things instead.

[timlombardo]

I don't think we need anything particularly special.

The dev wants to see an example of how error states are handled in the loader, ui, action etc. And to be able to see that working (ie not just the best practice for integrating sanity with errors, but also to see it working by inducing errors) << this is an assumption, maybe better examples are enough?

It'd be great if something like httpstat.us is available so we don't have to code it - what we really care about is a dev can run the hydrogen example locally with something like /products/1234?recommendationMock=500 and the response for the recommendation subrequest is a 500.