search

opentracing / specification

A place to document (and discuss) the OpenTracing specification. 🛑 This project is DEPRECATED! https://github.com/opentracing/specification/issues/163
http://opentracing.io/spec
Apache License 2.0
1.17k stars 182 forks source link

Added graphql semantic names #133

Closed bbakerman closed 1 year ago

bbakerman commented 5 years ago

GraphQL queries are an important way clients get data.

This PR adds new semantic names to capture the graphql query text, the operation type and the operation name

bbakerman commented 5 years ago

In general, I'm not very keen on having this, as all other semantic conventions we have are quite abstract, like db or http, without knowledge about the concrete DB type/family or HTTP version/server.

I suspect your viewing graphql as something quite specific like say "MySQL syntax" or "Elastic Search syntax etc.."

It is not. Its is a query language that describes how to find data. Its very generic at its heart.

Technically it is not even HTTP specific, although will grant that 95% of people currently sent graphql queries over HTTP but it could be gRPC / Protobuf / whatever.

But all the typically HTTP "verb / return code" information is not longer super relevant* in graphql - not like it is in REST based HTTP system

* it is a bit relevant but not core to graphql systems like it might be in RESTian systems

jpkrohling commented 5 years ago

I suspect your viewing graphql as something quite specific like say "MySQL syntax" or "Elastic Search syntax etc.."

Not really -- I'm not that familiar with GraphQL, but I understand that it is similar in purpose to SQL (the standard), not to specific implementations. Given that SQL queries are stored within db.query, I'd say that GraphQL queries would also fit there.

Technically it is not even HTTP specific

Sorry, my comment about "HTTP" was in relation to the prefix http, also part of this convention, as an example that tag prefixes are meant to be very generic.