-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: implement online style fetching for stable style resolving #459
Conversation
667e688
to
30b96a5
Compare
export const DEFAULT_MAPBOX_STYLE_URL = | ||
'https://api.mapbox.com/styles/v1/mapbox/outdoors-v12' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure which style we'd like to use by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know, but I think it's probably fine to merge this as long as we eventually confirm this is reasonable.
src/fastify-plugins/maps/index.js
Outdated
// Some upstream providers will not set the 'application/json' content-type header despite the body being JSON e.g. Protomaps | ||
// TODO: Should we forward the upstream 'content-type' header? | ||
// We kind of assume that a Style Spec-compatible JSON payload will always be used by a provider | ||
// Tehcnically, there could be cases where a provider doesn't use the Mapbox Style Spec and has their own format, | ||
// which may be delivered as some other content type | ||
rep.header('content-type', 'application/json; charset=utf-8') | ||
return upstreamResponse.json() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
highlighting this. implementation currently assumes that most upstream providers will be working with a JSON-based style definition. technically, it could be some other format with a different content-type, but not sure how many providers like that actually exist.
the content-type
header workaround is mostly defensive - just something i noticed when testing with Protomap's style API (which currently doesn't set an expected content-type: application/json
header)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM other than my numerous nitpicks and questions.
src/fastify-plugins/maps/index.js
Outdated
rep.header('content-type', 'application/json; charset=utf-8') | ||
return upstreamResponse.json() | ||
} else { | ||
fastify.log.error( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@EvanHahn do you think this should this also be a warning instead of a error log?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Short answer: yes, I think it should be a warning.
Long answer:
At a high level, I believe two things about how errors should be logged:
- Errors are for developer mistakes. Invalid states are a good example, because a perfect developer would never put the system into an invalid state.
- Warnings are for unavoidable problems. Network failures are usually a good example, because even a perfect developer can't fix a user turning their wifi off.
To be clear, this is personal preference!
So what would I do this case?
If we get a 5xx error from the server, that's a warning, because we didn't make a mistake. But you could argue that we should error if we get a 4xx. After all, if we send a bogus request, isn't that a developer's fault?
In this case, I think the answer is...maybe? Do we consider a bad API key an error, or a warning? Does it depend on what kind of 4xx status code you get (e.g., is 422 "our fault" but 429 is not)? I don't think it's worth thinking too hard about, so I'd probably just go with a warning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is helpful! thanks for sharing both answers 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addressed via 0d992ef
d6f96b6
to
096e0d9
Compare
0654550
to
a6d8c44
Compare
I plan to review this on Monday.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM as long as we get an answer to this question (doesn't have to be before merge):
https://github.com/digidem/mapeo-core-next/pull/459/files#r1473479880
096e0d9
to
3b6d2ce
Compare
a6d8c44
to
0d992ef
Compare
3b6d2ce
to
e37954e
Compare
ef1c0dd
to
dff966d
Compare
Not planning to re-review this. Let me know if that's wrong! |
@achou11 Anything else you want to do on this PR before we merge it? |
considering it's stacked, I'd prefer to merge the other ones first based on stack order. the other ones haven't been reviewed yet and so id refrain from merging in order to make them easier to review |
Ah, of course. Sorry for the ping!
|
e37954e
to
8153ae9
Compare
cc0c3ff
to
9ed4430
Compare
8153ae9
to
ef363dd
Compare
9ed4430
to
2abe8a4
Compare
ef363dd
to
af62ed3
Compare
2abe8a4
to
0a84122
Compare
af62ed3
to
be88383
Compare
0a84122
to
12ea285
Compare
Closes #439
Closes #448
Stacked on #450
Notes:
key
query param when requesting the stable style json endpoint (as opposed to us using some hardcoded token)TODO:
Potentially use a proper fixture and/or making an actual request to the upstream provider? Right now I mock the response using Undici's mocking mechanismsAdded fixtures for style.json's from both Mapbox and ProtomapsDo we want to incorporate a compression plugin? (e.g. https://github.com/fastify/fastify-compress/). Most of the time, these upstream providers are compressing the responses but since we don't have anything set up, our forwarded response is not compressed right nowEDIT: seems like we don't need to right now based on feedback