Routine bug fixes

Thanks to @ferdinandsalis and @prevostc for the bugfixes in this release!

• Fixed a bug where tables with array columns couldn’t be used with computed columns—@ferdinandsalis (#58).
• Added missing support for user defined domain types—@prevostc (#64).

Relay viewer tag added

The Relay standard viewer field has been added to PostGraphQL. Now Relay users can query root PostGraphQL fields without worrying about the Relay imposed limitations for root fields defined in facebook/relay#112. For an example of how the viewer field works see the following:

{
  thing(id: "dGhpbmc6NQ==") { ...thing }

  viewer {
    id
    thing(id: "dGhpbmc6NQ==") { ...thing }
  }

  node(id: "viewer") {
    id
    ... on Viewer {
      thing(id: "dGhpbmc6NQ==") { ...thing }
    }
  }
}

fragment thing on Thing {
  id
  note
}

The viewer field simply returns all of the fields in the root query just nested one level deeper. This is very helpful for Relay applications and other frameworks that put limitations on what can be included in a root field. The Viewer type (returned by the viewer field) also implements the Node interface with a non-opaque ID of simply “viewer” making it re-fetchable by Relay.

The viewer field is also included in all mutation payloads now which can be helpful for Relay and non-Relay users alike as now you can query your entire data domain from the scope of a mutation payload.

Non-Relay users needn’t worry as this addition does not affect you at all. It provides a great benefit to Relay users which makes it worth including in PostGraphQL.

Finally, if you were using the viewer field name in your application with a procedure to return the authorized user object, you can still use standard field names like me or game.

Bugfixes

This release also contains a few bugfixes. Notably:

• Falsey values can now be used in the update mutation instead of being discarded with a falsey check—@ferdinandsalis in ac15f8e

Library usage now supported.

Because PostGraphQL is written in Node.JS, it has the great advantage of being integratable with standing Node.JS applications. This release aims to make this goal even easier by enhancing PostGraphQL’s abilities as a library.

To use PostGraphQL in this way you now just need to do the following:

import express from 'express'
import postgraphql from 'postgraphql'

const app = express()

app.use(postgraphql('postgres://localhost:5432'))

app.listen(3000)

To learn more about all of the options available when using PostGraphQL as a library, read the documentation article here.

Added support for procedures

This release is pretty exciting for me as it adds support for PostgreSQL procedures. To see more check out PR #41.

Procedures in PostgreSQL are powerful for writing business logic in your database schema, and PostGraphQL allows you to access those procedures through a GraphQL interface. Create a custom mutation, write an advanced SQL query, or even extend your tables with computed columns! Procedures allow you to write logic for your app in SQL instead of in the client all while being accessible through the GraphQL interface.

So a search query could be written like this:

create function search_posts(search text) returns setof post as $$
  select *
  from post
  where
    headline ilike ('%' || search || '%') or
    body ilike ('%' || search || '%')
$$ language sql stable;

And queried through GraphQL like this:

{
  searchPosts(search: "Hello world", first: 5) {
    pageInfo {
      hasNextPage
    }
    totalCount
    nodes {
      headline
      body
    }
  }
}

For more information, check out our procedure documentation and our advanced queries documentation.