PostGraphQL 2 Beta #145
PostGraphQL 2 Beta #145
Conversation
|
I’ve just published a documentation article detailing the entire process of creating a PostGraphQL schema. It also in detail describes authentication and authorization, some of which is new in PostGraphQL 2. The last thing I need to do is setup a demo database to enable people running Any last requests for breaking changes as I hope to not break anything for a while after this. |
This test was flaky in development where users are global across databases.
|
Excellent work, @calebmer! I was reading through the first half of the tutorial and have a few tweaks to suggest:
then -> than
The way this reads is a little misleading, I think - strict means if you give it null input it'll give null output. I'm not sure how postgraphql 2 handles this, but v1 would just return null (and no error).
Missing "not" Other than these minor niggles, it seems great so far! |
|
Ok, looks like we’re good, seems like all that’s left is bug fixes. I feel we got most of the major regressions so I’ll merge today and do the final |
|
🎉 Congrats! |
PostGraphQL 2 Beta
PostGraphQL 2 Beta
With this PR, I’m very excited to announce PostGraphQL 2 is now in beta 🎉
Get it now and start playing around by running (make sure you have a database running on
postgres://localhost:5432):PostGraphQL 2 fixes a number of long standing bugs, makes some breaking changes to reflect emerging GraphQL best practices, and sets a foundation which can be used to do truly amazing things in the future (most popularly MySQL support). To understand more of the theory behind PostGraphQL 2, read “#87 My vision for the future of PostGraphQL.”
A number of breaking changes were made in PostGraphQL 2. I hate making breaking changes, especially given that GraphQL itself is designed to be change-tolerant, but I felt these were (in most cases) necessary small fixes that would be best for PostGraphQL’s feature. While this PostGraphQL 2 release does add a lot of things, remember that its real purpose is to create a strong base on which to build a data interfacing platform. Therefore, it felt like breaking changes made sense. If you disagree with any breaking changes, let me know! I would be more than happy to add a flag to provide backwards compatibility where possible. I’m hoping most breaking changes are small enough to not be a big deal, and perhaps even be desired changes. Most are inspired by dialog with the community.
New Stuff
postgraphqland we will automatically connect to your local database running atpostgres://localhost:5432and thepublicschema. Before the release a--demoflag will also be added which will connect you to a database running in the cloud. So easy you have to try 😉--dynamic-jsonflag (Add JSON type #102). Compound type support means now you can create nested objects in your schemas, input or output.rowIdfields by default. By default, PostGraphQL no longer renamesidcolumns torowId. This was a controversial decision made in PostGraphQL 1 to support Relay 1, as Relay 1 requires theidfield to be a special global id. However, it would appear that the GraphQL team is moving towards a standard global field name in__id. This new field name makes a lot of sense for PostGraphQL so now all global ids are named__idby default. However, this does not mean PostGraphQL no longer supports Relay 1! You could use the Relay 1 fork that supports__id, or you could pass the option--classic-idsto PostGraphQL which will use the original behavior. If you prefer the classic behavior, all power to you!Nodeidentifier. The row’s primary key, or a unique constraint (Support mutations by global ID #126).{tableName}Nodes, as inpersonNodesorpostNodes. This was 8000 originally because I was against bringing in a pluralization package, mainly because it may have been awkward for non-English speakers. However, as PostGraphQL aims to be more and more extensible, it isn’t hard to change/add pluralization rules. So in PostGraphQL 2, names are not pluralized and read likeallPeopleorallPosts. This feels like much more natural and may always be configured.Other Breaking Changes
--developmentflag. Instead all of the features in--developmenthave been broken out into their own flags. The reason this was done is because sometimes a GraphiQL interface in production makes since. GraphiQL is now also enabled by default, use--disable-graphiqlto disable it./graphqlroute with a browser, you would see GraphiQL. This turns out to not be a best practice as it tightly couples GraphiQL to the GraphQL endpoint. If we wanted to add features to GraphiQL like a headers editor, or a SQL terminal it would be much more difficult if the routes were not separated. Whenever you start PostGraphQL you will be told the exact URL GraphiQL is served on so you won’t be confused.patchobject whose fields correspond to the object’s fields.descendingargument in connection fields, instead descending information is contained in theorderByenum. So instead of configuringorderBy: NAME, descending: true, you would instead just write:orderBy: NAME_DESCororderBy: NAME_ASC.viewerfield has been renamed toqueryin PostGraphQL 2. The root levelviewerfield is a hack for Relay 1 to workaround some of Relay 1’s limitations when it comes to top level fields (such limitations should be gone in Relay 2). However, theviewerfield could also have some semantic meaning such as the literal “viewer,“ or “current user” of the schema. By naming this root fieldviewer, PostGraphQL 1 disallowed users to add their own implementation forviewer. In PostGraphQL 2, the field still exists, but it has been renamed toquery. It can be used in the exact same way, just now with a better name 😉Steps To Release
The core codebase for PostGraphQL 2.0.0 is done and ready for production use. The reason it isn’t going straight to a release is that there are a few extra things that need to be done.
Also, I wanted to add a period of time to allow for feedback. Once we hit 2.0.0, I don’t want to make any breaking changes for as long as possible, so now would be the time to make those breaking changes!
The list of things that need to get done before we can release are as follows.
postgraphql --demo.What Comes Next?
So what’s the plan after PostGraphQL 2.0.0 is released? We’ll continue with my rough timeline as proposed in #87, but here it is again with a few extra things.
Please try out PostGraphQL 2 and tell me what you think! It’s as easy as (if you have a Postgres database running on
postgres://localhost:5432):