profile
viewpoint
David Glasser glasser Meteor Development Group San Francisco, CA http://flickr.com/photos/glasser/

dferber90/meteor-prerender 17

Allow your Meteor web app to be crawled by search engines

broxtronix/Fiat-Lux 14

Lasers. On ice.

glasser/acme 0

:lock: acmetool, an automatic certificate acquisition tool for ACME (Let's Encrypt)

glasser/amock 0

Automatically exported from code.google.com/p/amock

glasser/apollo-tracing-ruby 0

Ruby implementation of GraphQL trace data in the Apollo Tracing format

glasser/bouncy 0

bounce HTTP requests around for load balancing or as an HTTP host router

glasser/commitissuelinker 0

A chrome extension that adds links to your issue tracker when you are inside a GitHub commit/pull request

Pull request review commentapollographql/apollo-studio-community

GraphRoles: More concrete details

 We've identified new requirements for access control at the graph level since th  Here's what we plan to do for the next phase of work in Studio on access control, which we hope will cover your needs for graph and variant permissions. If this plan does not address your needs, please let us know so we can understand what the gaps are. -1. Introduce a way to override any role a user might have in the org with a higher role for a specific graph. A user might be an **Observer** in the org, but can be promoted to a **Contributor** on a specific graph.-2. Introduce a **Graph Admin** role that can operate with all permissions of the **Contributor** role, but can also manage user access to the graph (our current **Admin** role becomes **Org Admin**). When users create a graph, they are automatically the graph admin, and they can delegate that permission to other users by granting the graph admin role to other users on that graph.-3. Introduce a way to mark variants as **protected**. A protected variant is effectively _read-only_ to everyone who can see the graph except the graph admins and org admins, who have permission to push schemas, see keys, change configuration, etc.-4. Introduce a way to assign roles to graph API keys. We would make the **Consumer**, **Observer**, **Contributor**, and **Graph Admin** roles available for assignment on API key creation.-5. Introduce a setting on graphs that flags them as "visible" or "hidden" to the members of that graph's org by default. Right now, all graphs in the org are visible to all members of the org. If you mark a graph as "hidden" to your org, only you will see it. You can grant permission for other users in your org to see your graph as well.+1. Introduce a **Graph Admin** role that can operate with all permissions of the **Contributor** role, but can also manage user access to the graph and delete the graph. (Our current **Admin** role will be renamed to **Org Admin**. **Graph Admin**s and **Org Admin**s will have identical permissions to act on graphs, but org admins will also be able to manage org membership, billing, etc.)  The **Contributor** role will be made less powerful. It will not be able to perform management tasks on the graph like updating integrations and settings; it will have all the permissions of **Observer** plus the ability to push new versions of the graph's schema.

I think it's worth reaching out to active customers to see what they'd prefer, but yeah, probably transitioning to Graph Admin (which will be identical to the old Contributor except that they will be able to delete graphs and manage per-graph permissions) makes sense. What do you think?

glasser

comment created time in 5 hours

PullRequestReviewEvent

pull request commentapollographql/apollo-server

fix(lambda) File uploads

Hi, I'm not an active maintainer of this project. Sorry!

mathix420

comment created time in a day

push eventglasser/vote.davidglasser.net

David Glasser

commit sha b9032ac919d8d985d83ddb37832685b1607a1194

hill #2

view details

push time in 3 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha 6dcfc8140cce6167a2237c0148637eeed7296512

Final choices

view details

push time in 3 days

issue openedalexghr/got-fetch

Incorrect calculation of content-length for string or URLSearchParams bodies

got-fetch calculates the HTTP content-length header like this for string bodies:

        'Content-Length': String(body.length)

However, body.length is defined as UTF-16 codepoints (roughly, "characters") whereas content-length is defined as bytes. So for any non-ASCII body, this will set a content-length that is too small.

I am a little surprised that this isn't something that you can just rely on got to handle for you rather than calculating it yourself. got has a whole file dedicated to calculating this correctly: https://github.com/sindresorhus/got/blob/835c70bd6fdc5b1ba7e7ffd322490b6d66fb407e/source/core/utils/get-body-size.ts

created time in 7 days

issue commentapollographql/apollo-server

apollo-server-plugin-response-cache: cache hint not working

Yes, looking at your reproduction, this is working as intended. The theory when designing this feature was that object fields are more likely to be "looking up a different thing with different cacheability" than scalar fields. I'm not sure that this area of the product is under enough active development for it to be likely to change the semantics at this point.

cherukumilli

comment created time in 9 days

issue commentapollographql/apollo-server

apollo-server-plugin-response-cache: cache hint not working

@mattvb91 I'll dig in on your reproduction, but I do think you're observing documented behavior. https://www.apollographql.com/docs/apollo-server/performance/caching/#setting-a-default-maxage says:

By default, root fields (ie, fields on Query and Mutation) and fields returning object and interface types are considered to have a maxAge of 0 (ie, uncacheable) if they don't have a static or dynamic cache hint.

nestedObject is a field returning an object type is its default maxAge is 0.

Whether this design for @cacheControl's defaults is a good idea is a different question, but I'm pretty sure this is working exactly as intended?

cherukumilli

comment created time in 9 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha a7a6d2affc0729632cfddea4b7d9e9b44a9fb141

Mayor

view details

push time in 11 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha db196917b5134ac6e5938883e38e13f3a8f799aa

updates

view details

push time in 11 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha f3341f22ba9c8eb5b59d02cccd4b06e1f0b155e2

more tweaks

view details

push time in 12 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha 9607c2fd747e52878954a340af21a2a5c63dd2ba

tweaks

view details

push time in 13 days

issue openedapollographql/apollo-server

Misleading error if you set `APOLLO_KEY` to something that is not a service token

If you set APOLLO_KEY to something that does not start with service: (and don't explicitly set APOLLO_GRAPH_ID or apollo: {graphId}), then the usage reporting plugin will be installed by default, but it will fail with the misleading error

You've enabled usage reporting via ApolloServerPluginUsageReporting, but you also need to provide your Apollo API key, via the APOLLO_KEY environment variable or via `new ApolloServer({apollo: {key})'

The fix is twofold:

  • Make the error be clearer if the problem is specifically the lack of graph ID
  • Don't auto-load the plugin unless you have a graph ID

That said, usage reporting doesn't actually work for anything other than graph (service) tokens (ie, user tokens are not supported for usage reporting, though they are for schema reporting), so if you're not setting a service token it's not going to work.

created time in 13 days

PullRequestReviewEvent

push eventglasser/vote.davidglasser.net

David Glasser

commit sha 64f11f9482dc46b342bab2c6c975eb69a227d776

more no on 22

view details

push time in 15 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha 77d5bb6e836ad00014873c334eb14179be16e605

finally figured out AC props

view details

push time in 15 days

Pull request review commentapollographql/apollo-server

Edits to usage reporting plugin and AS constructor docs

 If set, prints all reports as JSON when they are sent. (Note that this feature i </td> <td> -Specify the function for creating a signature for a query. This option is not recommended, as Apollo's servers make assumptions about how the signature relates to the operation you executed.+Specify this function to create a signature for a query. This option is not recommended, because Apollo's servers make assumptions about how the signature relates to the operation you executed. </td> </tr>  </tbody> </table>++#### Valid `sendHeaders` object signatures

Move this below the sendVariableValues section so they are in the same order as the options in the table (and are in decreasing order of importance).

StephenBarlow

comment created time in 16 days

Pull request review commentapollographql/apollo-server

Edits to usage reporting plugin and AS constructor docs

 How often to send reports to Apollo. We'll also send reports when the report get </td> <td> -We send a report when the report size will become bigger than this size in bytes (default: 4MB).  (This is a rough limit --- we ignore the size of the report header and some other top level bytes. We just add up the lengths of the serialized traces and signatures.)

This is reference documentation, so I would prefer you keep the parenthesized caveat.

StephenBarlow

comment created time in 16 days

Pull request review commentapollographql/apollo-server

Edits to usage reporting plugin and AS constructor docs

 ----title: "API Reference: ApolloServerPluginUsageReporting"-sidebar_title: ApolloServerPluginUsageReporting+title: "API Reference: Usage reporting plugin"+sidebar_title: "Usage reporting plugin"

Can you update the sidebar titles for the other plugins at the same time, even if you're not updating the actual docs in the same PR? It looks inconsistent otherwise.

StephenBarlow

comment created time in 16 days

Pull request review commentapollographql/apollo-server

Edits to usage reporting plugin and AS constructor docs

 For example, you can look at the GraphQL operation's name in `requestContext.ope </td> <td> -By default, this plugin associates client information such as name and version with user requests based on HTTP headers starting with `apollographql-client-`. If you have another way of communicating client information to your server, tell the plugin how it works with this option. This option has type `(GraphQLRequestContext) => { clientName?: string, clientVersion?: string, clientReferenceId?: string }`.+Specify this function to provide Apollo Studio with client details for each processed request. Apollo Studio uses this information to [segment metrics by client](https://www.apollographql.com/docs/studio/client-awareness/).++This function is passed a [`GraphQLRequestContext`](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-server-types/src/index.ts#L115-L150) object containing all available information about the request. It should return an object with `clientName` and `clientVersion` fields that identify the associated client.

Are you explicitly removing the reference to clientReferenceId? I think it isn't mentioned much in the docs. Maybe we should just get rid of the feature entirely? (I've always been skeptical of its value.)

StephenBarlow

comment created time in 16 days

Pull request review commentapollographql/apollo-server

Edits to usage reporting plugin and AS constructor docs

 This deprecated option is how you configured connecting Apollo Server to [Apollo  ###### `plugins` -`Array<PluginDefinition>`+`Array` </td> <td> -An array of plugins to install in your server. Each plugin definition is either an object with methods like `requestDidStart` and `serverWillStart`, or zero-argument function returning an object of that form. See [the full plugin documentation](../integrations/plugins/) for more details.+An array of objects representing [plugins](../integrations/plugins) to install in your server instance.

I think it's nice to be clear that the elements can either be plugin objects themselves or objects returning plugin objects (and the other page doesn't say that either).

(Not actually super clear why that's beneficial these days tbh... But it's true.)

StephenBarlow

comment created time in 16 days

Pull request review commentapollographql/apollo-server

Edits to usage reporting plugin and AS constructor docs

 ----title: "API Reference: ApolloServerPluginUsageReporting"-sidebar_title: ApolloServerPluginUsageReporting+title: "API Reference: Usage reporting plugin"+sidebar_title: "Usage reporting plugin" api_reference: true --- -## Using the plugin+Apollo Server has a built-in usage reporting plugin that gathers metrics on how your clients use the operations and fields in your GraphQL schema. The plugin also handles pushing these metrics to [Apollo Studio](https://www.apollographql.com/docs/studio/), as described in [Metrics and logging](../../monitoring/metrics/).

I've been trying to move away from the term "metrics" for our usage reporting. Metrics feels very timing/performance-connected and I'm trying to emphasize "what clients use what fields" important rather than purely "and how long did it take to run".

StephenBarlow

comment created time in 16 days

Pull request review commentapollographql/apollo-server

Edits to usage reporting plugin and AS constructor docs

 This deprecated option is how you configured connecting Apollo Server to [Apollo  ###### `plugins` -`Array<PluginDefinition>`+`Array` </td> <td> -An array of plugins to install in your server. Each plugin definition is either an object with methods like `requestDidStart` and `serverWillStart`, or zero-argument function returning an object of that form. See [the full plugin documentation](../integrations/plugins/) for more details.+An array of objects representing [plugins](../integrations/plugins) to install in your server instance. -In addition to the plugins you explicitly install, Apollo Server ships with a few plugins that it enables in certain contexts (like when you specify an Apollo API key with `$APOLLO_KEY`, or if the server is a federated implementing service). See the API references for the [usage reporting](./plugin/usage-reporting/), [schema reporting](./plugin/schema-reporting/), and [inline trace](./plugin/inline-trace/) plugins for details.+In certain cases, Apollo Server installs one of its built-in plugins automatically (for example, when you provide an Apollo Studio API key with the `APOLLO_KEY` environment variable). For details, see the API references for these plugins: [usage reporting](./plugin/usage-reporting/), [schema reporting](./plugin/schema-reporting/), and [inline trace](./plugin/inline-trace/).

s/one/some/?

StephenBarlow

comment created time in 16 days

Pull request review commentapollographql/apollo-server

Edits to usage reporting plugin and AS constructor docs

 By default, all errors get reported to Apollo servers. You can specify a filter  ###### `includeRequest` -`Function`+`async Function` </td> <td> -This option allows you to choose if a particular request should be represented in the usage reporting sent to Apollo servers. By default, all requests are included. If this *async* predicate function is specified, its return value will determine whether a given request is included.--The predicate function receives the request context. If validation and parsing of the request succeeds, the function will receive the request context in the [`GraphQLRequestContextDidResolveOperation`](https://www.apollographql.com/docs/apollo-server/integrations/plugins/#didresolveoperation) phase, which permits tracing based on dynamic properties, e.g., HTTP headers or the `operationName` (when available). Otherwise it will receive the request context in the [`GraphQLRequestContextDidEncounterError`](https://www.apollographql.com/docs/apollo-server/integrations/plugins/#didencountererrors) phase. In either case, it should return a `Promise<Boolean>`.--For example, you can look at the GraphQL operation's name in `requestContext.operationName` or at the HTTP headers in `requestContext.request.http?.headers`.+Specify this asynchronous function to configure which requests are included in usage reports sent to Apollo Studio. For example, you can omit requests that execute a particular operation or requests that include a particular HTTP header. -(If you don't want any usage reporting for any request, don't use this plugin; if you are using other plugins that require you to configure an Apollo API key, use `ApolloServerPluginUsageReportingDisabled` to prevent this plugin from being installed by default.)+This function is called for each received request. It takes a [`GraphQLRequestContext`](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-server-types/src/index.ts#L115-L150) object and must return a `Promise<Boolean>` that indicates whether to include the request. It's called either after the request is successfully resolved, or after it generates an error.

after the operation is successfully resolved (ie, we've found an operation within the document that we're going to run).

I think your conciseness is good but keeping the link to the exact phase in the plugin doc could still be good.

StephenBarlow

comment created time in 16 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventapollographql/apollo-server

Oliver Salzburg

commit sha 7b2b11511a96050448be29f22c012b104c1af9c0

fix: Missing lru-cache dependency (#4600) Relates to #4453. Co-authored-by: Jesse Rosenberger <git@jro.cc>

view details

David Glasser

commit sha ae0c5204801dfa2d2372478e6af83762b838adc9

Update CHANGELOG header

view details

David Glasser

commit sha 8a9b03d2109fd87c00d8b40dd7faa0be1cbefda1

package-lock update

view details

David Glasser

commit sha a4786b2fbfd2ae60e1bf1cfaaced3f9c8d174a93

Release - apollo-server-azure-functions@2.18.2 - apollo-server-cloud-functions@2.18.2 - apollo-server-cloudflare@2.18.2 - apollo-server-core@2.18.2 - apollo-server-express@2.18.2 - apollo-server-fastify@2.18.2 - apollo-server-hapi@2.18.2 - apollo-server-integration-testsuite@2.18.2 - apollo-server-koa@2.18.2 - apollo-server-lambda@2.18.2 - apollo-server-micro@2.18.2 - apollo-server-testing@2.18.2 - apollo-server@2.18.2

view details

renovate[bot]

commit sha b201a2dce409085724884a87383563f13e9df111

chore(deps): update dependency gatsby-theme-apollo-docs to v4.5.3 (#4627) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

David Glasser

commit sha 7d75acdeb1e31ecf566bf7612473a53086ae5661

Merge pull request #4628 from apollographql/release-2.18.2 Release 2.18.2

view details

David Glasser

commit sha 5297a8d5aa8a59450def13af8c9aac8ce3002596

Merge branch 'main' into release-2.19.0

view details

push time in 17 days

push eventapollographql/apollo-server

Oliver Salzburg

commit sha 7b2b11511a96050448be29f22c012b104c1af9c0

fix: Missing lru-cache dependency (#4600) Relates to #4453. Co-authored-by: Jesse Rosenberger <git@jro.cc>

view details

David Glasser

commit sha ae0c5204801dfa2d2372478e6af83762b838adc9

Update CHANGELOG header

view details

David Glasser

commit sha 8a9b03d2109fd87c00d8b40dd7faa0be1cbefda1

package-lock update

view details

David Glasser

commit sha a4786b2fbfd2ae60e1bf1cfaaced3f9c8d174a93

Release - apollo-server-azure-functions@2.18.2 - apollo-server-cloud-functions@2.18.2 - apollo-server-cloudflare@2.18.2 - apollo-server-core@2.18.2 - apollo-server-express@2.18.2 - apollo-server-fastify@2.18.2 - apollo-server-hapi@2.18.2 - apollo-server-integration-testsuite@2.18.2 - apollo-server-koa@2.18.2 - apollo-server-lambda@2.18.2 - apollo-server-micro@2.18.2 - apollo-server-testing@2.18.2 - apollo-server@2.18.2

view details

David Glasser

commit sha 7d75acdeb1e31ecf566bf7612473a53086ae5661

Merge pull request #4628 from apollographql/release-2.18.2 Release 2.18.2

view details

push time in 17 days

PR merged apollographql/apollo-server

Release 2.18.2

As with release PRs in the past, this is a PR tracking a release-x.y.z branch for an upcoming release of Apollo Server. 🙌 The version in the title of this PR should correspond to the appropriate branch.

Check the appropriate milestone (to the right) for more details on what we hope to get into this release!

The intention of these release branches is to gather changes which are intended to land in a specific version (again, indiciated by the subject of this PR). Release branches allow additional clarity into what is being staged, provide a forum for comments from the community pertaining to the release's stability, and to facilitate the creation of pre-releases (e.g. alpha, beta, rc) without affecting the main branch.

PRs for new features might be opened against or re-targeted to this branch by the project maintainers. The main branch may be periodically merged into this branch up until the point in time that this branch is being prepared for release. Depending on the size of the release, this may be once it reaches RC (release candidate) stage with an -rc.x release suffix. Some less substantial releases may be short-lived and may never have pre-release versions.

When this version is officially released onto the latest npm tag, this PR will be merged into main.

+19 -13

1 comment

15 changed files

glasser

pr closed time in 17 days

created tagapollographql/apollo-server

tagpublish/20201005185658

🌍 GraphQL server for Express, Connect, Hapi, Koa and more

created time in 17 days

push eventapollographql/apollo-server

David Glasser

commit sha a4786b2fbfd2ae60e1bf1cfaaced3f9c8d174a93

Release - apollo-server-azure-functions@2.18.2 - apollo-server-cloud-functions@2.18.2 - apollo-server-cloudflare@2.18.2 - apollo-server-core@2.18.2 - apollo-server-express@2.18.2 - apollo-server-fastify@2.18.2 - apollo-server-hapi@2.18.2 - apollo-server-integration-testsuite@2.18.2 - apollo-server-koa@2.18.2 - apollo-server-lambda@2.18.2 - apollo-server-micro@2.18.2 - apollo-server-testing@2.18.2 - apollo-server@2.18.2

view details

push time in 17 days

push eventapollographql/apollo-server

David Glasser

commit sha 8a9b03d2109fd87c00d8b40dd7faa0be1cbefda1

package-lock update

view details

push time in 17 days

pull request commentapollographql/apollo-server

fix: Missing lru-cache dependency

Thanks, see https://github.com/apollographql/apollo-server/pull/4628

oliversalzburg

comment created time in 17 days

pull request commentapollographql/apollo-server

Release 2.18.2

This is a cherry-pick on top of v2.18.1, plus #4600, which is a regression in v2.18.0 for people using tools like yarn2 pnp which strictly enforce declared dependencies.

glasser

comment created time in 17 days

PR opened apollographql/apollo-server

Release 2.18.2

As with release PRs in the past, this is a PR tracking a release-x.y.z branch for an upcoming release of Apollo Server. 🙌 The version in the title of this PR should correspond to the appropriate branch.

Check the appropriate milestone (to the right) for more details on what we hope to get into this release!

The intention of these release branches is to gather changes which are intended to land in a specific version (again, indiciated by the subject of this PR). Release branches allow additional clarity into what is being staged, provide a forum for comments from the community pertaining to the release's stability, and to facilitate the creation of pre-releases (e.g. alpha, beta, rc) without affecting the main branch.

PRs for new features might be opened against or re-targeted to this branch by the project maintainers. The main branch may be periodically merged into this branch up until the point in time that this branch is being prepared for release. Depending on the size of the release, this may be once it reaches RC (release candidate) stage with an -rc.x release suffix. Some less substantial releases may be short-lived and may never have pre-release versions.

When this version is officially released onto the latest npm tag, this PR will be merged into main.

+5 -0

0 comment

2 changed files

pr created time in 17 days

create barnchapollographql/apollo-server

branch : release-2.18.2

created branch time in 17 days

pull request commentDataDog/integrations-extras

apollo: revert display name in CSV; update transition date

Thanks @hithwen! Agreed that the metrics list looks good, as does the logo. Down to just waiting on the title on the closed tile.

glasser

comment created time in 18 days

pull request commentapollographql/apollo-server

fix: Missing lru-cache dependency

Does this break the use of v2.18 in some cases? Should I rush this out as a v2.18.2, since I think v2.19 is going to go out until next week due to @jsegaran 's schedule?

oliversalzburg

comment created time in 18 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha f7ff1b0e2de8a8878fba4a7bd7b5c7158fd7a1c5

yikes

view details

push time in 18 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha adfd796e542590547d35b0443510435331dcbc27

stronger about no on 20

view details

push time in 18 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha a83192c7ca8be6db7e61d664b9dcd28f96e97383

first draft done

view details

push time in 18 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha c3bf70ee8f31d59111d0c79221c5c61c7e8b1717

tweak bart

view details

push time in 19 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha ae8f7b6ab140018c8dfbf21f145a0579e4ee55f1

Revert "Revert "https by default (swapped dns to cloudfront)"" This reverts commit ea8b34e589a72c733133dfbd746ba4dba9571380. DNS is more rolled out, should work better

view details

push time in 20 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha ea8b34e589a72c733133dfbd746ba4dba9571380

Revert "https by default (swapped dns to cloudfront)" This reverts commit 2b20e15396d74546e142425c71fc91a859e802ab. Wanna make sure the CF CNAME is fully propagated before doing this (which breaks even http if https is broken)

view details

push time in 20 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha 2b20e15396d74546e142425c71fc91a859e802ab

https by default (swapped dns to cloudfront)

view details

push time in 20 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha 179dc5c89af209f95c939466f89f6f7ecd3c1348

some candidate stuff

view details

push time in 20 days

pull request commentapollographql/apollo-server

[BE-615] AER: use a static identifier for GraphQL validation failures

for the PR description (final commit message when squashing) make sure you have double #s in the operation names

zionts

comment created time in 20 days

PullRequestReviewEvent
CommitCommentEvent

push eventapollographql/apollo-studio-community

David Glasser

commit sha 20848e213ee95cb5f02f276e9a4a135c696128be

New Datadog metric and tag names (#28)

view details

push time in 20 days

delete branch apollographql/apollo-studio-community

delete branch : glasser/datadog-forwarder-naming

delete time in 20 days

push eventapollographql/apollo

David Glasser

commit sha 4a7c07195f94730bacdb9ea92070e4c4e972971f

datadog-integration: typo

view details

push time in 20 days

push eventapollographql/apollo

David Glasser

commit sha c08b07f6ade86e92007202433ab650a155d1f582

[AR-1853] Update Datadog integration docs for new metric names (#998)

view details

push time in 20 days

pull request commentapollographql/apollo

[AR-1853] Update Datadog integration docs for new metric names

Note: the first image needs to be updated to show the new integration name once Datadog updates their site.

Datadog is seriously lagging on getting the logo and title updated. I'll deal with that later. See https://github.com/DataDog/integrations-extras/pull/729 for details

glasser

comment created time in 20 days

pull request commentDataDog/integrations-extras

apollo: revert display name in CSV; update transition date

Thanks @hithwen, this is all very helpful.

Metrics should be updated already, logo can take up to two weeks but hopefully less.

I don't see the Metrics tab of the tile in the app updated to contain the non-engine metrics.

glasser

comment created time in 21 days

pull request commentDataDog/integrations-extras

apollo: revert display name in CSV; update transition date

OK, so I should expect the metrics and logo in the tile to update on Monday?

And most importantly to me — as soon as the metrics in the tile have updated, does that mean that anything starting with apollo.* (not just apollo.engine.*) is billed as an integration metric rather than custom, or is that a separate process?

glasser

comment created time in 21 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha 8d42510ba40927951df9a14560cff66c4ee672e8

update top

view details

push time in 21 days

pull request commentDataDog/integrations-extras

apollo: revert display name in CSV; update transition date

Also our public_title in the JSON is Datadog-Apollo Integration; should I simplify that to just say "Apollo" or something?

glasser

comment created time in 21 days

pull request commentDataDog/integrations-extras

apollo: revert display name in CSV; update transition date

@hithwen Thanks Julia. I've added another commit to this PR that updates the metadata. So it sounds like the only things that will still have "engine" in it will be not publicly exposed to users, once the closed tile change is made? Is there any way for me to track the progress of that change?

glasser

comment created time in 21 days

push eventapollographql/integrations-extras

David Glasser

commit sha 55df4dc6032b192aa2a3dbfd8420d43316f32354

Change metadata file display name back to apollo_engine Apparently the attempt we've been making since March to remove our old product name from these integrations isn't possible and we need to keep display_name stuck on "Apollo Engine".

view details

push time in 21 days

pull request commentDataDog/integrations-extras

apollo: Update transition date

Ok, so what do you recommend we do if we don't want our old product name in your UI? Should we revert most of this year's Apollo changes in this repo and create a new second integration?

glasser

comment created time in 21 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha b1ee8715c904d5e9cc0e5f8af1fd20dd297ace6e

done props

view details

push time in 21 days

PullRequestReviewEvent

pull request commentDataDog/integrations-extras

Revert display name

(I'm also discussing this on #729 so maybe in the interest of not having too many parallel discussions, can you follow up there?)

hithwen

comment created time in 21 days

pull request commentDataDog/integrations-extras

apollo: Update metric names and tags

(In the interest of not having too many threads, maybe follow up this on #729 ?)

glasser

comment created time in 21 days

pull request commentDataDog/integrations-extras

apollo: Update transition date

OK, I see that @hithwen (a Datadog employee, I believe) reverted our display name back to Apollo Engine in #728 today. I'm not sure why that happened. Engine is no longer our product name and we really want to get it out of the Datadog integration.

Something similar happened by @FlorianVeaux in https://github.com/DataDog/integrations-extras/pull/547 in March.

Is our attempt to remove our outdated product name just doomed?

glasser

comment created time in 21 days

pull request commentDataDog/integrations-extras

Revert display name

Sorry, why did this change happen? We changed the name of our product to no longer be Engine and attempted to rename this integration in January (#508).

hithwen

comment created time in 21 days

pull request commentDataDog/integrations-extras

apollo: Update transition date

apollo_engine is the wrong value. We changed it in #508 earlier this year. (Engine is no longer our product's name. I think there were some follow-up PRs to iron out wrinkles.)

Perhaps this sort of rename isn't fully supported by your system and that's why we've been having trouble this year (eg no update of the tile until today, as described in #719)?

Are you suggesting that we should completely revert the rename we did in January if we want things to work?

glasser

comment created time in 21 days

push eventapollographql/apollo

David Glasser

commit sha 02f4a7da94e676bdb61b46e6a73d1115073cb327

review feedback

view details

push time in 21 days

PullRequestReviewEvent

Pull request review commentapollographql/apollo

[AR-1853] Update Datadog integration docs for new metric names

 Studio forwards the following metrics to Datadog:  | Name | Description | | ------- | --------- |-| `apollo.engine.operations.count` | The number of GraphQL operations that were executed. This includes queries, mutations, and operations that resulted in an error. |-| `apollo.engine.operations.error_count` | The number of GraphQL operations that resulted in an error. This includes both GraphQL execution errors and HTTP errors if Studio failed to connect to your server. |-| `apollo.engine.operations.cache_hit_count` | The number of GraphQL queries for which the result was served from Apollo Server's full query cache. |-|`apollo.engine.operations.latency.min`<br/>`apollo.engine.operations.latency.median`<br/>`apollo.engine.operations.latency.95percentile`<br/>`apollo.engine.operations.latency.99percentile`<br/>`apollo.engine.operations.latency.max`<br/>`apollo.engine.operations.latency.avg`| A histogram of GraphQL operation response times, measured in milliseconds. Because of Studio's aggregation method (logarithmic binning), these values are accurate to +/- 5%. |+| `apollo.operations.count` | The number of GraphQL operations that were executed. This includes queries, mutations, and operations that resulted in an error. |+| `apollo.operations.error_count` | The number of GraphQL operations that resulted in an error. This includes both GraphQL execution errors and HTTP errors if Studio failed to connect to your server. |+| `apollo.operations.cache_hit_count` | The number of GraphQL queries for which the result was served from Apollo Server's full query cache. |+|`apollo.operations.latency.min`<br/>`apollo.operations.latency.median`<br/>`apollo.operations.latency.95percentile`<br/>`apollo.operations.latency.99percentile`<br/>`apollo.operations.latency.max`<br/>`apollo.operations.latency.avg`| A histogram of GraphQL operation response times, measured in milliseconds. Because of Studio's aggregation method (logarithmic binning), these values are accurate to +/- 5%. |   These metrics are aggregated in 60-second intervals and tagged with the GraphQL operation name as `operation:<query-name>`. Unique query signatures with the same operation name are merged, and queries without an operation name are ignored. -These metrics are also tagged with both the associated Studio graph ID (as `service:<graph-id>`) and the associated variant name (as `variant:<variant-name>`). If you haven't set a variant name, then `current` is used.+These metrics are also tagged with both the associated Studio graph ID (as `graph:<graph-id>`) and the associated variant name (as `variant:<variant-name>`). If you haven't set a variant name, then `current` is used.++If you set up your integration before October 2020, the metric names start with `apollo.engine.operations` instead of `apollo.operations`, and used a `service:<graph-id>` tag instead of `graph:<graph-id>`. This is called "legacy mode". You may transition your graph to modern mode by clicking the "Transition to modern mode" button on your graph's Integrations page. This is a one-way change; you should be prepared to update any dashboards and metrics to use the new metric and tag names when you click the button.

done

glasser

comment created time in 21 days

PullRequestReviewEvent

Pull request review commentapollographql/apollo

[AR-1853] Update Datadog integration docs for new metric names

 Studio forwards the following metrics to Datadog:  | Name | Description | | ------- | --------- |-| `apollo.engine.operations.count` | The number of GraphQL operations that were executed. This includes queries, mutations, and operations that resulted in an error. |-| `apollo.engine.operations.error_count` | The number of GraphQL operations that resulted in an error. This includes both GraphQL execution errors and HTTP errors if Studio failed to connect to your server. |-| `apollo.engine.operations.cache_hit_count` | The number of GraphQL queries for which the result was served from Apollo Server's full query cache. |-|`apollo.engine.operations.latency.min`<br/>`apollo.engine.operations.latency.median`<br/>`apollo.engine.operations.latency.95percentile`<br/>`apollo.engine.operations.latency.99percentile`<br/>`apollo.engine.operations.latency.max`<br/>`apollo.engine.operations.latency.avg`| A histogram of GraphQL operation response times, measured in milliseconds. Because of Studio's aggregation method (logarithmic binning), these values are accurate to +/- 5%. |+| `apollo.operations.count` | The number of GraphQL operations that were executed. This includes queries, mutations, and operations that resulted in an error. |+| `apollo.operations.error_count` | The number of GraphQL operations that resulted in an error. This includes both GraphQL execution errors and HTTP errors if Studio failed to connect to your server. |+| `apollo.operations.cache_hit_count` | The number of GraphQL queries for which the result was served from Apollo Server's full query cache. |+|`apollo.operations.latency.min`<br/>`apollo.operations.latency.median`<br/>`apollo.operations.latency.95percentile`<br/>`apollo.operations.latency.99percentile`<br/>`apollo.operations.latency.max`<br/>`apollo.operations.latency.avg`| A histogram of GraphQL operation response times, measured in milliseconds. Because of Studio's aggregation method (logarithmic binning), these values are accurate to +/- 5%. |   These metrics are aggregated in 60-second intervals and tagged with the GraphQL operation name as `operation:<query-name>`. Unique query signatures with the same operation name are merged, and queries without an operation name are ignored. -These metrics are also tagged with both the associated Studio graph ID (as `service:<graph-id>`) and the associated variant name (as `variant:<variant-name>`). If you haven't set a variant name, then `current` is used.+These metrics are also tagged with both the associated Studio graph ID (as `graph:<graph-id>`) and the associated variant name (as `variant:<variant-name>`). If you haven't set a variant name, then `current` is used.

done

glasser

comment created time in 21 days

PullRequestReviewEvent

pull request commentDataDog/integrations-extras

apollo: Update transition date

Not sure what's up with the CI failure.

glasser

comment created time in 21 days

pull request commentDataDog/integrations-extras

apollo: Update metric names and tags

@apigirl I see that the text in the overview and configuration tabs have updated in the app. Thanks!

This seems to not be updated yet:

  • The metrics listed on the Metrics tab (doesn't have the new apollo.operations.* metrics)
  • The name of the integration ("Apollo Engine" -> "Apollo") as visible on the top-level integrations list
  • The integration logo

Is that a separate process? Also I'm not sure how to tell if the change to the "prefix" has made it to the point of your system that all apollo.* metrics count as non-custom for billing purposes. I'll definitely need confirmation of that before I can make the change for our users.

glasser

comment created time in 21 days

PR opened DataDog/integrations-extras

apollo: Update transition date

PR #719 took longer than expected to make it to Datadog's infrastructure. On the bright side, the message is more accurate when the release happens on the first of the month :)

What does this PR do?

Just an update to the integration's README

Motivation

I thought that #719 would make it to your infrastructure in September but it didn't. No big deal, but want to fix the date.

Review checklist

  • [ ] PR has a meaningful title or PR has the no-changelog label attached
  • [ ] Feature or bugfix has tests
  • [ ] Git history is clean
  • [ ] If PR impacts documentation, docs team has been notified or an issue has been opened on the documentation repo

Additional Notes

Please don't let the existence of this PR slow down the complete release to your infrastructure of the changes in #719 which appears to be in progress now.

+1 -1

0 comment

1 changed file

pr created time in 21 days

push eventapollographql/apollo

Renovate Bot

commit sha 9ad7290d67f8e9bc03fd6bf92d8bdd83aa8e7f11

Update dependency gatsby to v2.24.63

view details

David Glasser

commit sha 9ef61e32c428062b0587e43505d9a3cfd73cac6f

Remove more references to engine and graph manager (#1003) Update AS configuration docs to use the new v2.18 plugin API (or just to use APOLLO_SCHEMA_REPORTING=true rather than code to turn on schema reporting).

view details

David Glasser

commit sha 805809020bf7d7b4365cd9f2c00b31bb0d8b187f

tutorial: Update register-schema image (#1004)

view details

Adam Zionts

commit sha 8f931d9934def1e545ab0f061a968e44ec6e301e

Add docs to identify which URLs are used from CLI/AS Different versions of Apollo Server and the Apollo CLI send data to different URLs. This adds a section into the "data privacy" document to indicate which versions of each piece of open source technology send which data to which domains. This does not include anything about which data is sent using the Apollo CLI. In particular, this comes along with an effort that David Glasser is taking to de-engine-ify our open source technology, and as such update our domains to use generic *.api.apollographql.com domains. These changes should not be released until corresponding versions of the CLI and Apollo Server have landed.

view details

Stephen Barlow

commit sha b16c41c122f620eebe69a2430ff4ab1740d90844

Consolidate URL tables and other privacy edits (#987) Co-authored-by: Stephen Barlow <stephenbarlow@APOLLO-StephenBarlow.attlocal.net>

view details

David Glasser

commit sha a4f0e207f806ad45483cc72115580efbf0e102aa

Update versions

view details

David Glasser

commit sha 8b4f567a4f5e67a656e02300a9386671537e4458

Merge pull request #984 from apollographql/adam/20/8/urls Add docs to identify which URLs are used from CLI/AS

view details

David Glasser

commit sha b8d95c515b8281f479a2fcee69fed39cf2e09bab

data-privacy: add URLs for managed federation and op reg (#1005)

view details

Renovate Bot

commit sha 536172fa70054315d32fbe9de32284792b85717a

chore(deps): update dependency gatsby to v2.24.65

view details

Sachin D. Shinde

commit sha c6ea6f8789e2c54d9faf534969dbd60cd33736a2

docs: Add new description change codes to schema-checks.mdx (#1007)

view details

Stephen Barlow

commit sha 47a68411fb00148dc301ff065a1e82b1778c515c

Add Explorer demo video to a couple Studio pages

view details

Stephen Barlow

commit sha 616e2c81e2b7de00992a9fb4eee71f31db53baab

Merge pull request #1010 from apollographql/sb/explorer-video Add Explorer demo video to a couple Studio pages

view details

David Glasser

commit sha 0592b6c2defbde224568aad5c6c00e0ac2928428

[AR-1853] Update Datadog integration docs for new metric names

view details

push time in 21 days

pull request commentapache/druid

Fix the offset setting in GoogleStorage#get

Thanks! This has been annoying me for 1.5 years but I never quite managed to fix it :)

abhishekagarwal87

comment created time in 22 days

pull request commentDataDog/integrations-extras

apollo: Update metric names and tags

I confirmed with a friend whose Datadog account has never used our integration that they are also seeing the many months out of date text in their in-app tile, fwiw.

glasser

comment created time in 23 days

pull request commentDataDog/integrations-extras

apollo: Update metric names and tags

Thanks @ChristineTChen and @apigirl !

I see the changes have already made it to https://docs.datadoghq.com/integrations/apollo/ That's great!

Do you need to take explicit steps to make these changes show up in the in-app integration tile (https://app.datadoghq.com/account/settings#integrations/apollo)? Note that changes from much earlier in the year such as #551 do not seem to have made it to the tile, at least in our account. (Unless the semantics are that integration documentation doesn't update for existing installations but does for new ones or something?)

glasser

comment created time in 23 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha df31df70b9b52e8a07fa2c60531eda6c996bc183

prop 19 needs research but isn't the same as 2018-5

view details

push time in 23 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha e53c076e1b04724901696d5550551c0fdc561b58

biases re props at all; formatting

view details

push time in 23 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha 77ea3a48323afa6b397790d70ab349bdcfb5642d

improve text by stealing something from 2018

view details

push time in 23 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha a139f50c9a22a114391428b67c468b40700bd42c

more props

view details

push time in 23 days

push eventglasser/vote.davidglasser.net

David Glasser

commit sha 99a61c853695c50a7996dfcb6e4d460f26b8fb34

some ca props

view details

push time in 23 days

Pull request review commentapollographql/apollo-server

[BE-615] AER: use a static identifier for GraphQL validation failures

 export default async function pluginTestHarness<TContext>({    const executionListeners: GraphQLRequestExecutionListener<TContext>[] = []; -  // This logic is duplicated in the request pipeline right now.+  // Let the plugins know that we now have a STRING of what we hope will+  // parse and validate into a document we can execute on.  Unless we have+  // retrieved this from our APQ cache, there's no guarantee that it is+  // syntactically correct, so this string should not be trusted as a valid+  // document until after it's parsed and validated.   await dispatcher.invokeHookAsync(+    'didResolveSource',+    requestContext as GraphQLRequestContextDidResolveSource<TContext>,+  );++  if (!requestContext.document) {+    await dispatcher.invokeDidStartHook(+      'parsingDidStart',+      requestContext as GraphQLRequestContextParsingDidStart<TContext>,+    );++    try {+      requestContext.document = parse(requestContext.source, undefined);+    } catch (syntaxError) {+      const errorOrErrors = syntaxError+      requestContext.errors = Array.isArray(errorOrErrors)+        ? errorOrErrors+        : [errorOrErrors];+      await dispatcher.invokeHookAsync(+        'didEncounterErrors',+        requestContext as GraphQLRequestContextDidEncounterErrors<TContext>,+      );++      return requestContext as GraphQLRequestContextWillSendResponse<TContext>;+    }++    await dispatcher.invokeDidStartHook(+      'validationDidStart',+      requestContext as GraphQLRequestContextValidationDidStart<TContext>,+    );++    /**+     * We are validating only with the default rules.+     */+    const validationErrors = graphqlValidate(requestContext.schema, requestContext.document);++    if (validationErrors.length !== 0) {+      requestContext.errors = validationErrors;+      await dispatcher.invokeHookAsync(+        'didEncounterErrors',+        requestContext as GraphQLRequestContextDidEncounterErrors<TContext>,+      );+      return requestContext as GraphQLRequestContextWillSendResponse<TContext>;+    }+  }++  const operation = getOperationAST(+    requestContext.document,+    requestContext.request.operationName,+  );++  requestContext.operation = operation || undefined;+  // We'll set `operationName` to `null` for anonymous operations.  Note that+  // apollo-engine-reporting relies on the fact that the requestContext passed+  // to requestDidStart is mutated to add this field before requestDidEnd is+  // called+  requestContext.operationName =+    (operation && operation.name && operation.name.value) || null;++  // This logic is duplicated in the request pipeline right now.

Honestly I'm not 100% sure what this comment was referring to originally but I suspect it works better higher up the function, or maybe not at all.

zionts

comment created time in 23 days

Pull request review commentapollographql/apollo-server

[BE-615] AER: use a static identifier for GraphQL validation failures

 export interface ApolloServerPluginUsageReportingOptions<TContext> {    * },    * ```    *-   */+send   */

revert

zionts

comment created time in 23 days

Pull request review commentapollographql/apollo-server

[BE-615] AER: use a static identifier for GraphQL validation failures

 Specify the function for creating a signature for a query. This option is not re </td> </tr> +<tr>+<td>++###### `sendOperationDocumentsOnUnexecutableOperation`++`Boolean`+</td>+<td>++Whether to include the entire document in the trace if the operation was a GraphQL parse or validation error (i.e. failed the GraphQL parse or validation phases). This will be included as a separate field on the trace and the operation name and signature will always be reported with a cosntant identifier. Whether the operation was a parse failure or a validation failure will be embedded within the stats report key itself.

cosntant -> constant

But also I think we can make this be a little more user-focused. Maybe something more along the lines of

Statistics about operations that your server cannot execute (because the operation cannot be parsed or fails validation or has an operation name that doesn't match the operation body) are not reported separately to Apollo's servers, but are grouped together as "parse failure", "validation failure", or "unknown operation name". By default, the usage reporting plugin does not include the full operation document in reported traces, because it is challenging to strip potential private information (like string constants) from invalid operations. If you'd like the usage reporting plugin to include the full operation document so you can view it in Apollo Studio's trace view, set this to true.

The wording isn't ideal but I think this helps explain what's going on and why you might want to set it better?

zionts

comment created time in 23 days

Pull request review commentapollographql/apollo-server

[BE-615] AER: use a static identifier for GraphQL validation failures

 export interface ApolloServerPluginUsageReportingOptions<TContext> {    * ID that the other plugin reports.    */   overrideReportedSchema?: string;+  // FIXME Add to the API reference docs

you did this

zionts

comment created time in 23 days

PullRequestReviewEvent

Pull request review commentapollographql/apollo-server

[BE-615] AER: use a static identifier for GraphQL validation failures

 describe('end-to-end', () => {     ).toBeTruthy();   }); +  it('fails parse for non-parseable gql', async () => {+    const { report } = await runTest({ query: 'random text' });+    expect(Object.keys(report!.tracesPerQuery)).toHaveLength(1);+    expect(Object.keys(report!.tracesPerQuery)[0]).toBe(+      '## GraphQLParseFailure\n',+    );+    const traces = Object.values(report!.tracesPerQuery)[0].trace;+    expect(traces).toHaveLength(1);+  });++  it('validation fails for invalid operation', async () => {+    const { report } = await runTest({ query: 'query q { nonExistentField }' });+    expect(Object.keys(report!.tracesPerQuery)).toHaveLength(1);+    expect(Object.keys(report!.tracesPerQuery)[0]).toBe(+      '## GraphQLValidationFailure\n',+    );+    const traces = Object.values(report!.tracesPerQuery)[0].trace;+    expect(traces).toHaveLength(1);+  });++  it('is unknown for missing operation', async () => {+    const { report } = await runTest({ query: 'query notQ { aString }' });+    expect(Object.keys(report!.tracesPerQuery)).toHaveLength(1);+    expect(Object.keys(report!.tracesPerQuery)[0]).toBe(+      '## GraphQLUnknownOperationName\n',+    );+    const traces = Object.values(report!.tracesPerQuery)[0].trace;+    expect(traces).toHaveLength(1);+  });++  it('is unknown for missing operation', async () => {

This test name looks copied from the previous test

zionts

comment created time in 23 days

PullRequestReviewEvent
more