Skip to content
This repository has been archived by the owner on Apr 14, 2023. It is now read-only.

spec-compliant GET support #490

Merged
merged 5 commits into from
Feb 17, 2018
Merged

spec-compliant GET support #490

merged 5 commits into from
Feb 17, 2018

Conversation

glasser
Copy link
Member

@glasser glasser commented Feb 16, 2018

Review commits separately. In addition to explicitly supporting GETs in apollo-link-http, we ban GETs in apollo-link-batch-http, and add an Observable helper fromError.

  • If this PR is a new feature, reference an issue where a consensus about the design was reached (not necessary for small changes)
  • Make sure all of the significant new logic is covered by tests
  • Rebase your changes on master so that they can be merged easily
  • Make sure all tests and linter rules pass
  • Update CHANGELOG.md with your change
  • Add your name and email to the AUTHORS file (optional)
  • If this was a change that affects the external API, update the docs and post a link to the PR in the discussion

@glasser glasser changed the title [wip] apollo-link-batch-http: disallow GET with batches [wip] spec-compliant GET support Feb 16, 2018
@apollo-cla
Copy link

apollo-cla commented Feb 16, 2018

Messages
📖

Please add your name and email to the AUTHORS file (optional)

📖

If this was a change that affects the external API, please update the docs and post a link to the PR in the discussion

Generated by 🚫 dangerJS

@codecov-io
Copy link

codecov-io commented Feb 16, 2018

Codecov Report

Merging #490 into master will decrease coverage by 0.04%.
The diff coverage is 90.9%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master    #490      +/-   ##
=========================================
- Coverage   91.35%   91.3%   -0.05%     
=========================================
  Files          19      19              
  Lines         798     828      +30     
  Branches      196     204       +8     
=========================================
+ Hits          729     756      +27     
- Misses         64      67       +3     
  Partials        5       5
Impacted Files Coverage Δ
packages/apollo-link-retry/src/retryFunction.ts 100% <ø> (ø) ⬆️
packages/apollo-link-retry/src/delayFunction.ts 100% <ø> (ø) ⬆️
packages/apollo-link/src/linkUtils.ts 89.04% <100%> (+0.46%) ⬆️
packages/apollo-link-http-common/src/index.ts 85.89% <100%> (ø) ⬆️
...ckages/apollo-link-batch-http/src/batchHttpLink.ts 91.54% <83.33%> (-1.31%) ⬇️
packages/apollo-link-http/src/httpLink.ts 90.47% <91.66%> (+0.82%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d257ade...fffde25. Read the comment docs.

@glasser
Copy link
Member Author

glasser commented Feb 16, 2018

Hmm, both the template and the bot tell me to update AUTHORS. But does this repo actually have AUTHORS?

They also refer to making and linking to docs PRs, but for this repo docs are inside the repo, right?

Copy link
Contributor

@evans evans left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks really good! fromError is great. A couple documentation suggestions. Otherwise looks good to me.

fetch: customFetch
});
```
You can use the `fetch` option when creating an http-link to do a lot of custom networking. This is useful if you want to modify the request based on the headers calculated or calculate the uri based on the operation:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think "request based on the calculated headers or calculate" would be better

@@ -44,6 +44,14 @@ export interface UriFunction {
(operation: Operation): string;
}

// The body of a GraphQL-over-HTTP-POST request.
export interface Body {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may be able to have Body be an interface that extends Partial, see this SO. GraphQLRequest is exported from apollo-link

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

query is a string rather than a DocumentNode (and there's no context), so I don't think that'll work?

In my experience over the entire open source and commercial Apollo codebase, guessing what type is going to be in a field or variable called query is the most challenging part :)

fetch: customFetch
});
```
You can use the `fetch` option when creating an http-link to do a lot of custom networking. This is useful if you want to modify the request based on the headers calculated or calculate the uri based on the operation:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

calculated headers sounds a bit better in my head

fetchMock.post('begin:data', makePromise(data));
beforeEach(() => {
fetchMock.restore();
fetchMock.post('begin:http://data/', makePromise(data));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the uri's are nice! Much more descriptive

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh, back when I implemented this using the URL web API it didn't work without this :)

@@ -233,18 +241,18 @@ export const selectHttpOptionsAndBody = (
};
};

export const serializeFetchBody = body => {
let serializedBody;
export const serializeFetchParameter = (p, label) => {
Copy link
Contributor

@evans evans Feb 17, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jaydenseric This is going to be a breaking change for [email protected]

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this OK? I thought this hadn't been released yet so it was an OK interface to break without documenting.

Copy link

@jaydenseric jaydenseric Feb 17, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's ok if the change is documented in a changelog entry, and a new version of apollo-link-http-common is published with a semver major (breaking change).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I didn't realize Evans had published a non alpha version of the package.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Evans, should I just revert the name change or something, or bump to 0.2.0?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you keep the breaking changes, please bump to v1.0.0, breaking changes in semver minor releases are the devil.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@glasser We can bump to v1.0.0, since it will make Jayden's life easier. I'm not worried about having the version number bloat and it might force better practice. The plan for apollo-link-common-http was to be a semi private API(without documentation due to overhead) that developers of links can look at if they want to align with apollo-link-http and apollo-link-batch-http. In that goal I think attempting to follow SemVer would be make keeping up with the changes easier

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I am wrong ^. Let's do v0.2, since we are pre v1.0 SemVer says that a breaking change should be a minor version. Also it looks like we should be okay for Jayden's upload-client

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

All 3 things should be assumed to be true for every npm package that can be publically installed. There are only upsides and no downsides to bumping the major version number if there is ever a breaking change.

FB in particular is the absolute worst for this. react jumping from v0.14 to v15 was an admission of guilt they had it wrong for 14 major versions. graphql being a v0.x causes great disruption to the ecosystem every update.

@glasser glasser changed the title [wip] spec-compliant GET support spec-compliant GET support Feb 17, 2018
@glasser glasser force-pushed the glasser/better-GET branch 2 times, most recently from 4b4c63f to 30539b1 Compare February 17, 2018 08:24
@glasser
Copy link
Member Author

glasser commented Feb 17, 2018

OK, I bumped the version of apollo-link-http-common to 0.2.0. This should be ready to merge (please don't squash). @evans / @jbaxleyiii I'll let you do the merge — @evans said you were trying to get another release out soon and it would be great to get this in it.

There is no spec for batching over GET. I don't believe apollo-server supports
it given that there's no spec. We can always come up with a spec and implement
it later.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants