exogen / graphbrainz Goto Github PK

Obviously there have been no commits to this repo in a long time but even cloning and deploying to Heroku no longer works as some dependencies in npmjs 404. If there is no plan to maintain the repo then shouldn't it be marked as such?

http://facebook.github.io/graphql/October2016/#sec-Documentation

Version 6.24.1 of babel-cli just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-cli is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

https://musicbrainz.org/artist/e01646f2-2a04-450d-8bf2-0d993082e058/relationships

I want to pull the instagram URL of this band, so I wrote a query like:

  lookup {
    artist(mbid: "e01646f2-2a04-450d-8bf2-0d993082e058") {
      id
      mbid
      name
      sortName
      relationships {
        urls {
          edges {
            node {
              sourceCredit
              targetCredit
              begin
              end
              ended
              type
              typeID
              attributes
              direction
            }
          }
        }
      }
    }
  }

But I don't see any way of getting the title and URL of the relationship. Any insight?

Thanks for an amazing library, it really is super helpful.

Hi again,
I'm getting an unusual amount of ESOCKETTIMEDOUTs.
Maybe the request() should use an HTTP Agent, for keep-alive. Don't think it is.
https://github.com/request/request#user-content-requestoptions-callback

I want to apply the https://github.com/exogen/graphbrainz#as-a-client use case using rollup etc., but the client has dependencies on some core node modules (url, fs etc.).

How to resolve this (or provide a working client example?

Thanks!

Since there are so many similar types and fields in the schema, the implementation for many of the resolvers is shared, and the appropriate handling is determined based on examining the requested fields in the query.

For example, in a query like { browse { releaseGroups(...) } }, we construct the API call to the release-group endpoint based on the fact that the field name is releaseGroups.

Aliases and fragments throw this off because we get the aliased/fragment names, not the ones we expect as defined in the schema. The information we need is there, it's just not being used properly at the moment.

Version 6.24.1 of babel-preset-stage-2 just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-preset-stage-2 is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 6.24.1 of babel-register just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-register is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Use the wikipedia URL relationship to query Wikipedia for more information, using the MediaWiki API.

I don't see any reason why limit & offset args couldn't be supported alongside first & after, to provide a more friendly schema for users who aren't using Relay. It might also just be confusing to have both.

e.g. in relationships, the target field successfully resolves the single mbid field on Entity, but can't resolve any fields on other Entity types – it just results in an empty object. This is due to a bug in GraphQL.js and will need to be fixed there: graphql/graphql-js#1093

Version 6.24.1 of babel-preset-es2015 just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-preset-es2015 is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 0.19.1 of ava just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As ava is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Did the heroku application perhaps run out of free dyno hours?

I've been running a large amount of complex queries, and often it's the case that deeply nested results lead to lots of individual lookup queries for entities.

I hacked up a proof-of-concept that uses dataloader's batching feature to recognize such lookups and make them using the search endpoint.

e.g. /ws/2/recording?query=rid:"{MBID}" OR rid:"{MBID}" OR ...

Then it will automatically map the results to the original, individual lookup requests, so they don't even know a different endpoint was used.

It works surprisingly well. The search endpoint also tends to return more data for each entity by default. This can speed up queries by 20–50x and avoid waiting for rate limits to clear up.

I'm planning on a rewrite of the whole GraphBrainz "query engine" to support this.

Currently, most of the extensions depend on being attached to a particular MusicBrainz entity, and don't offer many of their own fields on the root Query.

I'm considering rebranding this project to something like "MusiQL", which would be very similar, but not MusicBrainz-centric. Most of the existing queries would work exactly the same, but be under a musicBrainz field on the root query.

https://musicbrainz.org/doc/Collections

May require support for logging in?

It seems like the Heroku demo is down; are there any plans for fixing it?

Find genius.com URLs in lyrics relationships and query the Genius API for more information.

Version 10.0.1 of standard just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As standard is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Use the wikidata URL relationship to query WikiData for more information.

• getting

graphbrainz:api/client Error: “Error: ESOCKETTIMEDOUT” url=http://musicbrainz.org/ws/2/undefined/560b15db-79ea-49c0-b26e-84c808986e99?inc=artist-credit

• which isn't accessing

https://musicbrainz.org/ws/2/recording/560b15db-79ea-49c0-b26e-84c808986e99?inc=artist-credits
(both the query parameter and entity are wrong)

• on the query:

{
   browse {
    recordings(isrc:"GBUM70601491") {
      nodes {
        id
        mbid
        title
        length
        artistCredits {
          name
        }
      }
    }
  }
}

thank you.

As mentioned in the API documentation: https://musicbrainz.org/doc/Development/XML_Web_Service/Version_2

Despite the key being artist-credit in the JSON returned from the REST API, the field is always referred to in the plural ("artist credits") elsewhere in the MusicBrainz documentation, it is a list of credits, and the inc parameter to include them is artist-credits.

Add artistCredits and add a deprecation notice for artistCredit.

MusicBrainz tells us the total count of items in its paginated results. We should expose this as totalCount on connection objects.

Is it possible to retrieve all of the tracks on a Release? Looking at the MusicBrainz API it should be possible to do this:

{
  lookup {
    release(mbid: "617908f2-7a0b-3aad-ae02-5a5c125fa1a7") {
      media {
        trackCount
        position
        tracks # Cannot query field "tracks" on type "Medium"
        formatID
        format
      }
    }
  }
}

This is the equivalent request on the JSON web service: http://musicbrainz.org/ws/2/release/617908f2-7a0b-3aad-ae02-5a5c125fa1a7?inc=recordings&fmt=json

{
  "id": "617908f2-7a0b-3aad-ae02-5a5c125fa1a7",
  "media": [
    {
      "track-count": 12,
      "position": 1,
      "track-offset": 0,
      "tracks": [{}],
      "format-id": "9712d52a-4509-3d4b-a1a2-67c88c643e31",
      "format": "CD"
    }
  ]
}

Use the Spotify API to retrieve more information about entities.

Version 2.3.6 of sinon just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As sinon is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 0.9.3 of graphql just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As graphql is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

The sample query in the demo:

{
  lookup {
    artist(mbid: "5ca3f318-d028-4151-ac73-78e2b2d6cdcc") {
      name
      mediaWikiImages {
        url
        objectName
        descriptionHTML
        licenseShortName
      }
    }
  }
}

returns

{
  "errors": [
    {
      "message": "certificate has expired",
      "locations": [
        {
          "line": 5,
          "column": 7
        }
      ],
      "path": [
        "lookup",
        "artist",
        "mediaWikiImages"
      ]
    }
  ],
  "data": {
    "lookup": {
      "artist": null
    }
  }
}

Should the link for client submodule (src/api.js) be updated to /src/api/client.js?

https://github.com/exogen/graphbrainz/blob/fc53b15455840999d00b06209d25c1d2e7b923b8/README.md

Running a search on both my Heroku deployed instance as well as GraphBrainz test instance results in out of date information.

For example searching for artist "Opeth" returns albums up to around the year 2002 when clearly MusicBrainz has all albums up to 2019.
Musicbranz site search: https://musicbrainz.org/artist/c14b4180-dc87-481e-b17a-64e4150f90f6

Searching on GraphBrainz test and my instance using the following which results in less data:
query OpethArtistInfo { lookup { artist(mbid: "c14b4180-dc87-481e-b17a-64e4150f90f6") { name mbid releases { edges { node { mbid title date } } } } } }

How do we go about retrieving actual up to date data? Is there something I am missing? @exogen

Instead of making people access information through the somewhat cumbersome relationship API, it would be nice if an extension parsed out common relationships into something more useful.

For example, artists could be given members, originalMembers, and tributeArtists fields.

The below query

query Artist {
  node(id: "QXJ0aXN0OjMyM2VkOTc0LThiZjYtNGY1NC05NTI1LWI3NzRhNjU5ZjgwNQ==") {
    ... on Artist {
      relationships {
        __typename
      }
    }
  }
}

when used on https://graphbrainz.herokuapp.com/ fails with

{
  "errors": [
    {
      "message": "__typename-rels is not a valid inc parameter for the artist resource.",
      "locations": [
        {
          "line": 4,
          "column": 7
        }
      ],
      "path": [
        "node",
        "relationships"
      ]
    }
  ],
  "data": {
    "node": {
      "relationships": null
    }
  }
}

The problem seems to come from the __typename meta-field that is not correctly understood: https://spec.graphql.org/draft/#sec-Type-Name-Introspection

With the latest fixes to update packages I am able to deploy successfully to Heroku now, thank you. However, I wish to use the Discogs extension.

The installation details state to just run npm install graphbrainz-extension-discogs but doing so on the Heroku console results in a lot of console logs stating Integrity checksum failed when using sha1.... and listing Discogs as an extension in the config vars does not work, probably because it cannot find it if it was installed.

How could I go about installing and using this extension? I would create a discussion on this topic and not an issue but I do not see this option for the repo. Thank you in advance!

Version 0.6.5 of express-graphql just got published.

This version is covered by your current version range and after updating it in your project the build failed.

express-graphql is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴