I want to create a "Query Logger" that tracks what queries are being used, how often they're being used, and other metrics like total execution time, etc.

This should give insight into what Queries are popular, what queries might be problematic, etc.

This can help inform where Resolve optimizations should be made, where Query Complexity implementation should be applied, etc.

Additionally, this can help implement a query whitelist/blacklist that can check if queries should or should not be allowed to be executed before actually attempting to execute anything.

For reference on why I landed with this train of thought: https://dev-blog.apollodata.com/5-benefits-of-static-graphql-queries-b7fa90b0b69a#.xhj7s7tm7

We should create an abstract class for setting up types. We should have one to extend the InputObjectType class, and one to extend the ObjectType class. This will help reduce some redundant code when creating a new object and will make the registration more consistent. It should also help us keep the field filters consistent as that should be in the abstract class too.

There should be a "taxonomies" connection field on the PostTypeType that resolves to taxonomies that are registered in WP as connected to the postType

This will allow post types like "Attachments" to register their own type definition class. This is useful when the schema is considerably different than the standard post schema.

We map input fields to Query args for WP_Query, WP_Comment_Query, etc.

We should look into "hardening" this and make sure we're only passing "safe" data through to the Query args.

We likely can DRY up a lot of the code as well, as it's a tad messy right now.

See:

• https://github.com/wp-graphql/wp-graphql/blob/master/src/Data/Resolvers/CommentsConnectionResolver.php#L215
• https://github.com/wp-graphql/wp-graphql/blob/master/src/Data/Resolvers/PostObjectsConnectionResolver.php#L272

Graphiql is a great tool, but sometimes it's nice to see documentation for a schema in more of a "static" format.

There are tools that output the Schema in more of a flat, static format, such as: https://www.npmjs.com/package/graphql-docs

I'm thinking it would be a cool add-on plugin that you could install and it would add a new endpoint like /graphql-schema that would output the static Schema.

Check out possibly using WP_HTTP_Response for returning a response vs. process_http_request

Some links for reference:

https://developer.wordpress.org/reference/classes/wp_http_response/

https://github.com/WordPress/WordPress/blob/b6ce4e283080332525bb276e2bacaf566c4a9b5c/wp-includes/rest-api.php#L462

Currently, the definitions of fields for types is set in the __construct() of each of the classes. To clean this up we should move it into a method further down in the class and just call it in the construct.

Posts can have a parent that can be any postType, so the Parent field needs to be a unionType, allowing for the resolver to resolve to any allowed_post_type

Add authentication layer to WPGraphQL.

The GIST of Authentication should look something like this:

An authentication mutation with username and password should be sent to authenticate which will return a "refresh token" and "JWT token"

The refresh token is a long-lived token and is should be persisted in WP in connection with the user (user_meta), and can be revoked (temporarily or permanently) at any point.

A valid refresh token can be used to get a new JWT token later. If revoked, the refresh token will be invalid for getting a refreshed JWT token, and would need successful username/pw authentication to re-generate (if not permanently revoked). If permanently revoked, it would require admin action to allow the user to obtain new refresh/jwt tokens.

The JWT token is a short-lived, signed token that can be sent in the headers for future requests and will be used to pass the user down in the AppContext of GraphQL for use in authenticating resolvers. The JWT token should include user info, including role/capability info that can be used by resolvers to check if the user has proper permission for the resolver to execute.

So, typical client flow should look something like this:

• Client should first authenticate with username/password (over https) via a GraphQL mutation
• Client should receive refreshToken and jwtToken in the mutation response
• Client should persist the refreshToken and jwtToken however they want (LocalStorage, etc)
• For all future requests, the client should first ensure the jwtToken is not already expired
  -- If expired, Client should ask for a new jwtToken using the refresh token
  ---If refresh token is invalid (revoked, or other), a new token will need to be created via user/pass auth request.
• if jwtToken is valid, pass it down to resolvers in the GraphQL AppContext
• If jwtToken is invalid, the GraphQL request should not be executed at all

Typical server flow should look like this:

• Server receives authentication mutation with username/password.
• If valid, return jwtToken and refreshToken
  -- if no refreshToken exists in user's user_meta, and the user isn't flagged as not being allowed to generate a new one, a new token should be created and stored in user_meta connected to the user. This should be something totally unique to the user that can be verified whenever it's sent, but can be revoked at any time.
  -- jwtToken should have a short expiration (tbd) and should include pertinent info about the user's roles, capabilities, etc (as well as all the other standard JWT details)
• For requests that contain a valid refreshToken in the header, a valid jwtToken should be returned.
• For requests that contain a jwtToken, the token should be validated before executing GraphQL.
  if the token is invalid, GraphQL should not execute
  if the token is valid, the user should be populated into the GraphQL AppContext before execution, and should be passed down to all resolvers so each resolver can reference when resolving

We need to decide on a new organizational structure for types. I recommended the following:

Within the Types folder, I think it would be good to have an Input folder and an Objects folder. We would then put all of the classes for query args in the Input folder, and the classes for object return values in the Objects folder. I think this naming convention most closely mimics the classes those classes are actually extending, but I could be open to something like "Input" and "Output" if you preferred that. I think this would really help clean up that folder since it's a little confusing what each of those classes is doing until you really dive into them. We could then put the RootQueryType in the root of the Types folder since that is different than everything else in there.

Then @jasonbahl came back with the structure from here: https://github.com/ParabolInc/action/tree/master/src/server/graphql/models

he said:

so, re structure. . .that's one thing I keep going back and forth on. . .it's hard to find any large open source examples of how folks are structuring. . .I think the largest example of an open source GraphQL server that I know of is: "Action" a Jira/Trello-esque app. . .here's how they structure their "types"

I don't think it matters which way we go, we just need to do something to organize the types.

Attachments (mediaItems) have a different Schema than standard postObjects and will require different input and save actions.

See the shape of mediaItems added here: #141

Should probably provide the ability to mutate at least the same data the REST API provides support for, but should also consider some of the nested postmeta as well

fwiw, here's where the REST API team ended up with Widget support: https://github.com/WP-API/wp-api-menus-widgets-endpoints

The "attachment" type needs to be defined with all the attributes of attachments (captions, alt_text, etc).

We should compare the attributes that the REST API outputs, as well as what wp_prepare_attachment_for_json outputs

Based on my initial research, the data that core uses for images either as part of the main post object or in post_meta are:

• id
• post_name
• post_parent
• post_parent
• _edit_last
• _edit_lock
• _wp_attached_file
• _wp_attachment_backup_sizes
• _wp_attachment_context
• _wp_attachment_image_alt
• _wp_attachment_metadata
• _wp_old_slug
• comment_count
• comment_status
• guid
• menu_order
• mime_type
• ping_status
• pinged
• post_author
• post_content
• post_content_filtered
• post_date
• post_date_gmt
• post_excerpt
• post_modified
• post_modified_gmt
• post_password
• post_status
• post_title
• post_type
• to_ping

The wp_prepare_attachment_for_json function returns the following fields:

• id
• title
• filename
• url
• link
• alt
• author
• description
• caption
• name
• status
• uploadedTo
• date
• modified
• menuOrder
• mime
• type
• subtype
• icon
• dateFormatted
• nonces
• editLink
• sizes
• width
• height
• fileLength
• compat

Need to write info in the readme.

fwiw, here's where the REST API team ended up with Widget support: https://github.com/WP-API/wp-api-menus-widgets-endpoints

XDebug might throw errors based on the max_nesting_limit, so it should be documented that if this occurs during development that the setting in xdebug might need to be adjusted

http://stackoverflow.com/questions/4293775/increasing-nesting-function-calls-limit#answer-4293870

The "CommentType" should have a field that connects it to the postObject it's connected to.

This field needs to be a "union", as a comment can be related to any type of post that has post_type support.

For reference: https://github.com/wp-graphql/wp-graphql/blob/master/src/Type/CommentType.php#L37

I'm a huge fan of using the Graph_i_QL Desktop tool, but it might be good to have an add-on plugin that folks can install to have GraphiQL in browser and we could customize things like add a login box for authentication, etc. . .

The CommentConnections are not yet fully tested. We need to flesh out test coverage to ensure the CommentConnections are working as expected.

You can see coverage here: https://coveralls.io/github/wp-graphql/wp-graphql?branch=master

Basically, we need to test the various connection queries that can be made and ensure things are working as expected to get the CommentConnection* files up to 100% coverage.

This will allow taxonomies to register their own type definition class. This is useful when the schema is considerably different than the standard taxonomy schema.

Need to include instructions for installing the Tests and running.

The command that needs to be run to install the tests from inside the plugin directory is:

bin/install-wp-tests.sh <db-name> <db-user> <db-pass> [db-host] [wp-version] [skip-database-creation]

This will install a test database or connect to an existing one if skip-database-creation is set to true and and the credentials entered are for an existing database.

We should implement DataLoader to take advantage of the batching/caching functionality as it should boost performance significantly.

https://github.com/overblog/dataloader-php