๐ฎ Graphile's Crystal Monorepo; home to Grafast, PostGraphile, pg-introspection, pg-sql2 and much more!
OTHER License
Bot releases are hidden (Show)
Published by benjie over 4 years ago
process.env.JWT_SECRET
(#1236, @AxelUlmestig)parseTags
, withPgClient
and getPgClientAndReleaserFromConfig
from graphile-build-pg
(engine#601, @enisdenjo)If you're using self-signed certificates for your PostgreSQL database, either keep your pg
version pinned to whatever it is currently, or read: https://node-postgres.com/announcements#2020-02-25.
Please note that we do not consider widening the range of a supported module to be a breaking change. You should use a lockfile and only upgrade the dependencies you intend to. Read more in our versioning policy.
The main features in this release are:
@omit many
from foreign key constraints (https://github.com/graphile/graphile-engine/pull/565; thanks @ab-pm)@pgSubscription
directive now supports a filter argument (#596; thanks @enisdenjo)We also did an amount of housekeeping including adding a couple minor TypeScript types, improving our snapshot tests, and adding more tests on the built project.
IMPORTANT: we released a preliminary 4.6.0-alpha.0
which completed conversion of the entire project to TypeScript (finally removing Flow from its last places) but unfortunately the type churn was too high for this to be included in a non-breaking update (even though it was only the types that changed) so we decided to move the release of TypeScript conversion until v5 of PostGraphile. Effectively we're going to pretent v4.6.0-alpha.0 never happened.
Published by benjie almost 5 years ago
(v4.5.1-v4.5.3 were skipped)
Fixes some Smart Tags teething problems (specifically related to fake constraints).
Published by benjie almost 5 years ago
Lots of pull requests and documentation improvements from the community in this release! ๐
First, things to be aware of before you deploy:
In enhanced GraphiQL you can now toggle 'Explain' to view the generated SQL and the query plan of that statement. This is not enabled by default - you have to opt in with --allow-explain
, or in library mode you can supply an allowExplain(req)
function that determines on a per-request basis if the user may use the explain functionality or not.
No longer do you need to put COMMENT
commands in the database ("smart comments") to customise your schema, you can now use a tags file to gather these "smart tags" into one, version controlled, easy to diff, place. Smart comments and smart tags can be used in unison, and both will be supported going forward so you can pick whichever works best for your team. In library mode you can manage smart tags however you like, and it's possible to pull smart tags from multiple sources and they will be automatically combined. Find out more about smart tags here: graphile.org/postgraphile/smart-tags/.
Community member @singingwolfboy has drafted a JSON schema definition that may help editors such as VSCode to help you when editing the default postgraphile.tags.json5
file. We've not upstreamed it yet, but hopefully will do so in the coming months.
Team Graphile went to ReactiveConf in Prague last month; check out Benjie's talk Increasing Velocity with GraphQL and PostgreSQL.
We now have 84 sponsors across GitHub and Patreon and that means we're funded to spend an average of nearly 2 days per week on Open Source; this is brilliant!
Don't forget GitHub are matching sponsorship currently - so do sign up to be a sponsor if you haven't already - the more time we can put into open source, the faster we can build awesome tools for you to build epic software with!
postgraphile.tags.json5
support (#1177) (7da3c7f), closes graphile/graphile-engine#529
pgUseCustomNetworkScalars
; thanks @higherorderfunctor@pgQuery
support for scalars (#534) (49259c2); thanks @phryneas/Mayflower
@pgQuery.source
can be function (#555) (907c8e6)Middleware
genericWe're no-longer listing chore-level items, but there have been a lot of them. Special thanks to @singingwolfboy for helping me to keep the codebase tidy.
Published by benjie about 5 years ago
General maintenance release.
Features:
readCache
can now pass an object to be used as the cache (@garcianavalon, https://github.com/graphile/graphile-engine/pull/479)Fixes:
--init
with Docker; turn off progress barsChores:
Published by benjie about 5 years ago
makeExtendSchemaPlugin
in the last release disabled the built-in directives @include
and @skip
; this hotfix restores them.
Published by benjie about 5 years ago
Benjie has been approved for GitHub Sponsors and for a limited time GitHub are match-funding, so there has never been a better time to support development of this software!
Talking of sponsorship, please check out our new featured sponsor, Timescale!
This is mostly a maintenance release, no major new features.
Features:
jwtSignOptions
to PostGraphile, thanks to @spellermakeExtendSchemaPlugin
now supports defining unions, directives and scalars (required to support Apollo Federation, which you can try out with @graphile/federation); unions only work in certain places and are currently undocumented (and thus unsupported)hideIndexWarnings
option for when you have ignoreIndexes: false
thanks to @tinymarsracingFixes:
PgNodeAliasPostGraphile
plugin to solve itbigint
or bigserial
in your primary key, values greater than 9 quadrillion (technically > 9,007,199,254,740,991
) are now treated as strings in the node identifier, so nodeId
is now valid for thesemoney
, or decimal
/numeric
or some other weird numeric type in your primary keys these will now also be represented as a string within the base64-encoded node IDs, so your node IDs will change. If this affects you (unlikely?) please get in touch with Benjie (to be clear: int, int2, int4, float, float4 and float8 are unaffected; and int8/bigint only changes node IDs for values over 9 quadrillion)@foreignKey
smart comment) as indexed so it works nicer with ignoreIndexes: false
jwtRole
, thanks to @bidoubiwaPublished by benjie over 5 years ago
The main feature of this release is significant performance improvements โ enjoy!
We also overhauled how Docker builds work, so they're now tagged in a more sensible manner. Almost all previous tags have been deleted. From now onwards we have versioned Docker images:
graphile/postgraphile:4
will give you the latest stable in the "v4.x.x" line (no alphas, betas, rcs); this is the recommended version to use
vX.Y.Z
git tag (i.e. no alpha/beta/rc) will automatically release graphile/postgraphile:X-Y
and graphile/postgraphile:X-Y-Z
graphile/postgraphile:latest
will give you the latest stable (but beware of major version bumps!)graphile/postgraphile:next
will give you the equivalent of what's on master
right now (i.e. pre-release/bleeding edge/nightly)We're currently in a teething period for this, so there may be some bumpiness - if you face any issues, please let me know via GitHub issues or discord.
NOTE: this only applies to future releases; we are not back-filling previous releases, so there's not many tags to choose from right now.
Other changes:
graphile-utils
externalUrlBase
for websockets (thanks @DvdGiessen)PGHOSTADDR
envvar if PGHOST
is not present (thanks @encima)SETOF
function mutations (these fields were never valid, so any client using them would already be broken, thus I am not classing this as a breaking change).Published by benjie over 5 years ago
Please sponsor development (anything from $1/mo) or take out a support contract to help fund ongoing development on the project. PostGraphile is liberally licensed and relies on crowd-funding to advance.
Thanks to the continuing sponsorship from PostGraphile's community, we've added to PostGraphile core what you've all been waiting for - GraphQL Subscriptions, and Live Queries!
We've enhanced PostGraphile with subscriptions / websockets functionality, including adding subscriptions support to our built in GraphiQL IDE (no more need to test with external GraphQL clients!). To get this you have to opt-in via the --subscriptions
flag (library: subscriptions: true
).
You can use our simple subscriptions listen
endpoint, or easily write your own subscription endpoints using makeExtendSchemaPlugin
- it's all documented on our website. PostGraphile subscriptions can use Postgres' LISTEN
/NOTIFY
, or any other source of realtime data โ you decide what makes sense for your application.
Subscriptions are the recommended way for adding realtime features to PostGraphile.
More experimental and much heavier on the database is our live queries support โ suitable for use in internal tooling within your company, but perhaps not for the internet at large. You can opt-in via the --live
flag.
We've built into the core of PostGraphile the ability to track when collections/records are referenced (and the filters that apply to them, such as foreign key constraints and conditions
); you can then combine this with one or more realtime provider plugins which inform PostGraphile when these tracked resources change, triggering the query to be re-executed and the result sent to the user.
This feature is exposed over standard GraphQL subscription
operations so you should be able to just switch out query
with subscription
at the beginning of your GraphQL document to make it live. No need for specific client support โ it supports all clients that support subscriptions. (We plan to support the @live
directive optimisation available in Apollo Client in a future release, should demand be sufficient.)
We recommend using simple request documents with live queries because each time a relevant row is changed the entire document is recalculated and sent to the user: more complex queries will consume more resources when recalculated and will likely be triggered more frequently, leading to non-linear performance costs. (Note: we throttle updates to prevent overwhelming the client or the server, and this throttle period is configurable.)
Our first live queries provider plugin, @graphile/subscriptions-lds
uses PostgreSQL's extremely efficient logical decoding functionality to stream changes out of the database using the replication interface. It requires you to tweak a couple of settings in postgresql.conf
but is otherwise simple to set up - see the documentation on the website which also includes instructions for Amazon RDS.
Note that live queries are still experimental, and have not been performance optimised yet - please let us know of any issues you face!
Docker compose/kubernetes users may appreciate the new --retry-on-init-fail
flag that means PostGraphile will keep trying to rebuild the initial schema, so with this flag it can be started before the database is ready. (Uses exponential backoff with a 30s cap.)
We've increased performance for queries that use large offset
values (so long as the relevant table is not using column-level select grants, which are not recommended with PostGraphile).
makeExtendSchemaPlugin
now has support for re-using existing Relay Connections; it can also be used with the @pgQuery
directive to add connections deeper into the schema. The documentation has been updated with more details.
You can now add your own aggregates to connections using our new aggregates infrastructure. totalCount
on connections has been re-written to use this, and there are more examples (e.g. exposing SUM(...)
) in the PR description: https://github.com/graphile/graphile-engine/pull/415; if you require certain aggregates please get in touch.
Thanks to @dijam we now accept Buffer
objects as jwtSecret
in addition to strings.
build.scopeByType
was added to enable plugin authors to get from a GraphQL type the scope it was created with - useful for finding the PostgreSQL table associated with a GraphQL object type, for example.
Plugins now have a dependency ordering system, so we can move to using --append-plugins
for everything and have hooks register their own positions. This system is not yet documented (or final) so is not officially supported yet, but it's a good way to easily enable features that previously involved a complex setup.
Many more tests were added.
--owner-connection
/ ownerConnectionString
setting added, to give PostGraphile access to a privileged Postgres account. It is needed for logical decoding, but it's now also used (if present) to install watch fixtures and avoid the "Failed to setup watch fixtures in Postgres database" error. It is recommended in development for the watch schema, but only recommended in production if you are using live queries.
Newly introduced @simpleCollections
smart comment enables you to override the simpleCollections
setting on a per-table, per-relation and per-function basis. I.e. you can now opt-in to using the list interface (rather than Relay connection interface) in certain places without affecting the rest of your schema.
Filterable, filter-by-able, sortable and sort-by-able functions support was introduced in 4.3.1.
GraphiQL Explorer support added in 4.3.2;
These are fixes that might break you schema if you were relying on the broken behaviour (please don't do that!). We've added flags to some of them so you can maintain the old (broken) behaviour should you need to.
interval
, etc) incorrectly having a String
input type (opt out with disableIssue390Fix
- ref https://github.com/graphile/graphile-engine/pull/405)--simple-collections only
we still used to add Relay edges to mutation payloads (these edges are pointless without the connections they applied to). We've corrected this oversight by removing them, but you can add them back with the disableIssue397Fix
flag - ref https://github.com/graphile/graphile-engine/pull/408)graphile-utils
: if you were using makeExtendSchemaPlugin
to add a field returning a Connection
type, this will not have been working correctly. Instead of returning return {data: await selectGraphQLResultFromTable(...)}
from your custom resolver you should now just return the result of selectGraphQLResultFromTable directly: return await selectGraphQLResultFromTable(...)
, and then pageInfo
and the rest will work correctly. The makeExtendSchemaPlugin docs have been updated, worth a re-read. If you're affected by this and don't make this change, you'll see errors like TypeError: data.data.map is not a function
.hstore
to handle issues in search_path
--subscriptions
or --live
flags as it requires you to have granted select to at least the primary keys of the tables you exposemakeWrapResolversPlugin
can now replace the arguments that are pass to PostgreSQL function calls for root-level custom queries and mutations.totalCount
is now non-nullable because I couldn't find any justification for it being nullable and no issues came up during the beta and RC phaseX-GraphQL-Event-Stream
header (thanks @imolorhe)hasVersion
to allow pre-releasesnamespaceName
in introspection for extensionsPublished by benjie over 5 years ago
Fixes an issue one of the PostGraphile sponsors had where sharing the PgPool between their own code and PostGraphile, using pgPool.query, and setting DEBUG
with the SQL-outputting debug variables caused an error to be produced. https://github.com/graphile/postgraphile/pull/987
Published by benjie over 5 years ago
The lovely folks over at OneGraph sent a PR to integrate their GraphiQL Explorer into PostGraphile โ this awesome feature really helps users get started with GraphQL. Make sure you're using --enhance-graphiql
to use it! #981
Additionally @mlipscombe discovered an issue where your PgPool could become exhausted if an enough errors were thrown on COMMIT
, and sent over a PR to fix: #978
Published by benjie over 5 years ago
Important note: pgInflection
should not appear anywhere in your code or that of your plugins; see below. (If it does, you'll get some warning messages, but things should continue to work for the time being.)
The main feature in this release is you can now opt-in to filtering and sorting function results (so long as they return setof table type), and enabling you to filter-by and sort-by scalar computed columns. This is opt-in behaviour on a per-function basis using smart comments because if used incautiously it could result in significant performance woes (basically: in many cases database functions are black boxes to PostgreSQL, so the full function result may have to be calculated before it can then be sorted, and if it returns millions of rows that might take a moment).
Also in this release are a number of small fixes and enhancements detailed below. See the ๐จ for a fix that may impact your schema if you were relying on broken behaviour.
PostGraphile is crowd-funded, we ask the individuals and businesses that use PostGraphile to please sponsor ongoing maintenance and development.
@filterable
and @sortable
smart comments; you can also mark the result as non-nullable via @notNull
smart comment (https://github.com/graphile/graphile-engine/pull/378)makeWrapResolversPlugin
has been enhanced to allow wrapping all resolvers that match a filter functionmakeAddInflectorsPlugin
has been enhanced to allow you to access previous inflectors (e.g. if you only want to override them in certain circumstances)Query
, Mutation
and Subscription
- just override the inflection.builtin(name)
inflectorundefined
as any of PostGraphile's options now throws an error to help you more rapidly spot issues in your code (thanks @marshall007); the PostGraphile call signature has not changedintarray
PostgreSQL extensionpgInflection
where they meant pgIntrospection
; have kept the old name too to prevent this being a breaking change, but please update your plugins to use the correct nameinflection
option to PostGraphile (which became pgInflection
internally) that was deprecated in 4.0.0-beta.6 now generates warning messages if you use it, which you should not. Instead migrate to the plugin-capable inflection system
Published by benjie almost 6 years ago
4.3.0 was never promoted to @latest
due to a couple of issues:
pgInflector
argument than expected; this has been restored in 4.3.1: https://github.com/graphile/graphile-engine/pull/381
@sortable
that broke a plugin; this is also resolved in 4.3.1: https://github.com/graphile/graphile-engine/pull/386
builtin
inflector: https://github.com/graphile/graphile-engine/pull/387
We're going to look into extending the release tests to running against some popular community plugins to ensure future releases don't introduce backwards-incompatible changes. If you'd like your plugin to be included in this effort, please get in touch.
Published by benjie almost 6 years ago
Thanks to sponsorship from ULTA.io, this release introduces support for defining constraints (e.g. foreign keys, primary keys, etc) via "smart comments". This means that VIEW
s and MATERIALIZED VIEW
s can now act a lot more like regular tables when viewed by PostGraphile - you can define a @primaryKey
for your view, or have a @foreignKey
that references another table (or another view!). You can also mark fields as @notNull
For more information, see the documentation:
The other change in this release is that we now surface a warning message if a foreign key constraint is skipped because it lacks an index and you're using --no-ignore-indexes
or ignoreIndexes: false
.
Published by benjie almost 6 years ago
Wow, this is a big release! If you have any questions about this release, please come ask in the discord chat: http://discord.gg/graphile
PostGraphile is crowd-funded open source. We use the MIT license to give you freedom in how you use it, but you should support its development by sponsoring us: https://www.graphile.org/sponsor/
View announcement for a less technical summary!
Lets jump straight in:
When updating to this version, IF you use any third-party plugins, you MUST update them too and test your application - some PostGraphile internals have changed, and although they are undocumented (and thus do not constitute a breaking change) depending on the complexity of the plugins you use they may be affected. (See below for more info.)
You should also pin your GraphQL version as this release increases the supported GraphQL version range to include v14.x which has some breaking changes.
Thanks to funding from Connecting Good, running PostGraphile in serverless is a lot lower latency. It's now possible to webpack up PostGraphile nice and tight, resulting is much smaller .zip
files to upload to Lambda (1/10th of the previous size); massively improved unzip time (milliseconds instead of seconds); and significantly reduced I/O time during startup, leading to sub-0.5s cold-starts when combined with our caching functionality.
Instructions and a demo on how to use this are available here:
https://github.com/graphile/postgraphile-lambda-example
A documentation article should be compiled in the coming months (when someone gets time...)
Thanks to a Herculean effort from @mattbretl, we now have support for many more function shapes, including IN
/ OUT
/ INOUT
parameters, and the RETURNS TABLE(...)
return type.
This was a massive (MASSIVE!) pull request, with a tonne of back-and-forth, and an incredibly large number of edge cases; so please do pop onto the Discord chat and congratulate Matt on a job well done!
If for some bizarre reason you don't want this awesome new functionality, Matt has even added a way for you to opt out via the --legacy-functions-only
CLI flag.
--no-ignore-indexes
Following on from --no-ignore-rbac
; you can now opt in to --no-ignore-indexes
. If you saw my talk at GraphQL Finland you'll understand that it's very important that we only expose what the server can fulfil efficiently; this option helps you to adhere to this by not exposing relations or filters that don't have associated indexes.
It's also nice for just tidying up your GraphQL schema - you don't really want to be able to do a condition
on a JSON
column do you? ๐
prettier
GraphQL, links, logo!)Run PostGraphile with --enhance-graphiql
(or enhanceGraphiql: true
) and you'll get a few enhancements to GraphiQL:
prettier
under the hood, leading to much nicer GraphQL formattingEasily wrap a resolver:
module.exports = makeWrapResolversPlugin({
User: {
async email(resolve, source, args, context, resolveInfo) {
const result = await resolve();
return result.toLowerCase();
}
}
});
Easily change the nullability (true = nullable, false = non-nullable) of fields in your GraphQL:
module.exports = makeChangeNullabilityPlugin({
User: {
email: true,
},
})
Process your entire GraphQL schema via a plugin; great for adding third-party enhancements such as graphql-shield
.
module.exports = makeProcessSchemaPlugin(schema => {
return addThirdPartyEnhancementsToSchema(schema);
});
We've split PostGraphiQL from the rest of PostGraphile, which has allowed us to add support for GraphQL v14 whilst still using GraphQL v0.13 with GraphiQL. GraphQL v14 has a number of breaking changes; so...
๐จ ...we recommend that you keep GraphQL pinned at whatever the current version is that you're using, but still upgrade PostGraphile.
๐จ The latest GraphQL spec changes how errors are handled. PostGraphile has embraced this, and error from --extended-errors
are now located in error.extensions.exception
. In order to maintain backwards compatibility (as this is only a minor release) we still expose these properties in the old location too, but version 5 will only expose the new interface (error.extensions.*
) so it's advised that you move your client code over to the new format ASAP. (Even if we remove the old format, you'll still be able to add it back via a handleErrors
callback, but you should probably follow the GraphQL spec too!)
This isn't officially supported; however it should work a lot better now. If you're mounting under a subpath in express then app.use("/path/to", postgraphile())
should work automatically without requiring any options. If you're using an external proxy then you must supply the base URL so that PostGraphile knows where to tell the browser the assets are located. This is all so that PostGraphile can reference different parts of itself correctly, such as the watch stream to put in the header, or the GraphQL endpoint for GraphiQL to connect to.
e.g.:
// Assuming you combine both Express subpath AND an external
// proxy which mounts your express app at `/myproxypath`, you
// should provide options like this:
app.use('/path/to', postgraphile(db, schemas, {
externalUrlBase: '/myproxypath/path/to',
graphqlRoute: '/graphql',
graphiql: true,
graphiqlRoute: '/graphiql',
}));
// Then you can load GraphiQL at `/myproxypath/path/to/graphiql`
// and it will know to connect to GraphQL at
// `/myproxypath/path/to/graphql`
Amazingly @tim-field discovered an issue that has never come up in the year of testing PostGraphile went through, which has required a little bit of restructuring of PostGraphile internals - we've mostly removed the recurseDataGeneratorsForField
internal API. This has meant that the generated SQL queries are now a little differently structured, particularly when it comes to connections and mutations; as such, some third-party plugins might need some minor tweaks. If you have a plugin affected by this, please reach out to me on Discord and I'll do my best to guide you through fixing it: http://discord.gg/graphile
๐จ We've mostly removed the recurseDataGeneratorsForField
internal API.
Plugins, such as filter plugins, that merely adjust the where
clause should be unaffected.
Plugins implemented via makeExtendSchemaPlugin
following the documentation should be safe in most cases, however if you use the @recurseDataGenerators
directive then you should change your plugin to follow the new documentation to avoid a warning message (namely: change the @recurseDataGenerators
directive to @pgField
, and return the data
property from your resolver). If your makeExtendSchemaPlugin
does not use @recurseDataGenerators
then you should be fine.
๐จ Plugins that wrap existing resolvers and either depend on or change the resulting data will probably need testing as the structure of the data returned from these has changed slightly.
DEBUG="postgraphile:postgres:notice"
envvar for outputting notices from your PostgreSQL functions (thanks @arshadkazmi42!)true
as the second argument to makeAddInflectorsPlugin
in order to replace existing inflectors--skip-plugins graphile-build:NodePlugin
should be sufficient/_postgraphile/stream
to ${graphqlRoute}/stream
(i.e. /graphql/stream
); but don't hard-code this - use the X-GraphQL-Event-Stream
header.pgSkipInstallingWatchFixtures
Graphile Engine setting to allow you to skip the warning if you're using PostGraphile in the recommended way (i.e. NOT using a superuser account!)@deprecated
smart-comment support has been extended to tables, functions and constraints engine #340 (thanks to @mattbretl)resolveInfo
(immutably) to avoid adding an extra argumentgraphql-parse-resolve-info
nodes
list and the edges.node
entry did not match for functions which return a set of scalars (e.g. RETURNS SETOF int
)Published by benjie about 6 years ago
Main feature in this release is added support for logging PG notices and improved support for logging PG errors - including additional metadata. Thanks to @arshadkazmi42 for working with me on this! Examples:
ERROR[ERR12]: Error Message Here! | WHERE: PL/pgSQL function a.generate_error(text) line 1 at RAISE | HINT: Help!
NOTICE[NOT23]: This is a notice. | WHERE: PL/pgSQL function a.generate_notice(text) line 1 at RAISE | HINT: Help!
To enable this, make sure you are using the debug envvars: export DEBUG="postgraphile:postgres:error,postgraphile:postgres:notice"; postgraphile ...
Also in this release is a tiny patch enabling plugin authors to reference the "parent" query builder from "child" query builders. This, for example, allows them to check a column from a parent record to decide which children to include. This is necessary for the @graphile-contrib/pg-omit-archived soft deletion plugin's INHERIT
option.
This release also introduces another helper to graphile-utils
: makePluginByCombiningPlugins
- enabling you to bundle multiple plugins into one (particularly useful for combining makeAddInflectorsPlugin
and makeExtendSchemaPlugin
plugins with raw Graphile Engine plugins).
Finally it makes the terminology used more consistent - "Graphile Engine schema plugins" and "PostGraphile server plugins".
Published by benjie about 6 years ago
After many months of development, testing and iteration it is my great pleasure to announce that PostGraphile v4 is officially available! All PostGraphile and PostGraphQL users are recommended to update to this version at their earliest convenience. A migration guide is available for PostGraphQL (v3), most users should find the upgrade fairly painless. A full feature guide is available detailing the various enhancements incorporated into PostGraphile v4.
A lot has changed in PostGraphile v4 (though it's still broadly compatible with version 3); here are some of the features I'm most excited about:
--no-ignore-rbac
, types and fields you cannot access (according to PostgreSQL GRANTs) are removed automaticallyThe biggest change in v4 is that the entire GraphQL schema generation has been re-built from the ground up to be both highly performant and highly customisable. This has been enabled with the help of the plugin-based Graphile GraphQL Engine. A few members of the community have already written some interesting plugins for PostGraphile, and we're keen to see what others come up with in the coming months!
We've also fixed a huge number of issues that affected V3, updated various dependencies, added support for PG10 features and PG11, added support for query batching, added support for a cluster mode to better make use of your many server cores, added simplified collections so you can bypass edges/nodes if you want to, greatly improved support for PostgreSQL functions, made watch mode even more reliable and useful, added a --no-server
option for schema export scripts, added cache functionality to skip database introspection on startup, configuration file support, better support for common environmental variables, bundled TypeScript typings and much much more!
Published by benjie about 6 years ago
The biggest issue people tend to face when getting started with PostGraphile are name collisions - where something in your database causes the same name for a type or a field to be generated twice in the GraphQL schema PostGraphile generates, leading to a failure to start. Errors generated previously were pretty obtuse, we now output much more information when this happens, including what the source of the two conflicting names were, and even hinting how it might be possible to fix it using smart comments:
Error: A naming conflict has occurred - two entities have tried to define the same key 'query'.
The first entity was:
Default field included in newWithHooks call for 'Query'. graphile-build built-in (root query type)
The second entity was:
Adding row by globally unique identifier field for table "public"."query". You can rename this table via:
COMMENT ON TABLE "public"."query" IS E'@name newNameHere';
These errors can clearly be enhanced further - if this is something that interests you please get in touch!
We've also squashed a few remaining bugs, and even added a new introspection template system so we can more easily support different PostgreSQL versions (thanks @mattbretl!).
foreign key (col_a, col_b) references other_table(col_1, col_2)
) where the column spec ((col_a, col_b)
) has a unique constraint now result in a one-to-one reference instead of a connection. (The connection still exists, but it's deprecated, so this is not a breaking change.) (graphile/graphile-engine#298)--skip-plugins
option to the CLI, and documented it in the middleware thanks to @mattbretl (graphile/postgraphile#853)before
cursor combined with last
option over a connection without a unique ordering constraint (such as a function, or a table with no primary key) the hasNextPage
entry in pageInfo
would incorrectly return false; this is now fixed. (graphile/graphile-engine#297)-A ''
to postgraphile now allows you to disable JWT audience validation (as the documentation claims). (graphile/postgraphile#848)๐ Sponsor PostGraphile Development ๐
Published by benjie about 6 years ago
A recent influx of Patreon support has enabled me to spend an extra day on PostGraphile this month, so this release contains more enhancements than expected! Thanks so much, Patreon supporters!
The biggest change in this release is to the TypeScript support - if you use PostGraphile in a TypeScript project then please remove any custom declarations you may have written for postgraphile
, postgraphile-core
, graphile-build
, graphile-build-pg
, graphile-utils
, pg-sql2
and graphql-parse-resolve-info
- all of these now come with their own built in TypeScript type definitions! ๐
GraphQL 0.13.x support! ๐ (We were limited to 0.12.x before) - this should hopefully help people get started a lot easier due to fewer graphql module conflicts!
Better TypeScript support
postgraphile-core
, graphile-utils
and graphql-parse-resolve-info
have been ported to TypeScriptgraphile-build
and graphile-build-pg
now export .d.ts
files so they should automatically work with TypeScript (ultimately we plan to move these to TypeScript too)graphile-utils
enhancements
@requires(columns: [...])
directivesupport for a couple more PG types:
hstore
supportinet
support thanks to @syndesisMore information in some places for plugins to use
jwtClaims
is now available on the GraphQL context, so your plugins can reference them (thanks to @hyperparsa)QueryBuilder
instances now have a reference to parentQueryBuilder
Better errors in a number of places
Improved CLI documentation / messages
Smart comments:
comment on constraint person_secret_person_id_fkey on c.person_secret is E'@forwardDescription The `Person` this `PersonSecret` belongs to.\n@backwardDescription This `Person`''s `PersonSecret`.';
Many fixes, including:
--watch
mode now watches more things--body-size-limit
option now applies to all body types (previously they defaulted to 100kB across the board, and only JSON was overridden with this option)We now accept the X-Apollo-Tracing
header which means you should be able to use hosted GraphQL Playground with a PostGraphile schema (this was causing CORS issues before)