Potential expansion to be less MusicBrainz-centric

[exogen]

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.

[lukehedger]

What are your latest thoughts on this @exogen? Would be interested to collaborate in some way if you are still planning to move to the MusiQL model.

[exogen]

Great question, it is still in the works and I would love to collaborate! I have a bunch of preliminary code written laying things out, but not in a state to push up yet.

Here is a rough outline of my latest thinking:

• Monorepo with "core" plus the official extensions (the current GraphBrainz extensions all living separately is already quite annoying to maintain)

• Server's loaded extensions themselves are introspectable, e.g. there's an extensions field that will list the loaded extensions' name/description/homepage etc.

• I would like to move away from using graphql-js directly for the schema definition. I'm generally a fan of the schema-first approach, and have used it elsewhere, and really gave it a fair shot for a GraphBrainz/MusiQL rewrite – but IMO it just doesn't work. There are too many repeated types/patterns/descriptions/etc. for it not to be constructed programmatically. It's a big schema.

  If writing the GraphQL SDL directly, for example, I need to duplicate the description for the alias field that appears in dozens of places. I would really like that to never have the potential to be out of sync if someone forgets to update one. Solving that would involve string interpolation...and I'd want to parameterize some of these patterns/descriptions/etc. as well, it just ended up really messy/ugly.

  So, I'd like to try out some of these newer approaches that are still programmatic schemas and not GraphQL SDL, but also not the no-frills graphql-js. Maybe GraphQL Nexus for instance: https://github.com/graphql-nexus/nexus

  @lukehedger Have you explored any of those strategies before?

• In general, I'm quite happy with the way the current schema is designed. If you use it often and there are rough edges, now's a good opportunity to revisit.

  e.g. I noticed some APIs (like GitHub's) will have a single search resolver, and the type of entity to search is an enum. Depending on what people are building with the API, this could make some things easier (like MusicBrainz's own search box where you select the type to search – it could be a variable in the query, instead of needing to access entirely different fields). But, I think I prefer my current approach of the different entities having their own subfields, because then each type can have its own custom search/browse/lookup arguments (it knows that you can search/browse/lookup certain entities by certain extra facets). What do you think?

  (One solution would be to keep things as they are, but also add an entity subfield, where you could use an enum to specify the type. Adding more fields doesn't really harm anything, no reason not to be batteries-included)

[exogen]

Timely article: https://www.prisma.io/blog/the-problems-of-schema-first-graphql-development-x1mn4cb0tyl3

[lukehedger]

That article certainly hits the nail on the head when it comes to schema-first. Had not seen graphql-nexus before but I think that approach is definitely the way to go. Prisma also seem to hint they will be introducing a similar tool next week 🤞 (EDIT: Looks like it is now https://github.com/prisma/nexus).

In general, I wonder if it makes sense to move to a schema/API that abstracts the sources away from the user? So, the API would just expose top-level entities like artists, tracks, releases etc etc (essentially, promoting the browse query fields and retaining MusicBrainz,'s ontology), as well as search. The response fields would be an amalgamation of available data from MusicBrainz, LastFM, Spotify and the extensions. Over time more sources could be added that augment the top-level entities without changing the API - the user just gets richer data.

The way search is designed right now feels flexible enough to support different use cases (eg. single entity and mixed entity searches), whereas the enum approach might be a bit restrictive I guess.

Agree on the monorepo too but not sure I understand enough about how the extensions work to comment on that!