The Ultimate GraphQL solution

I’ve been building an app called Awesfit for while now, using the facebook stack. What i’m learning is that I really like graphql, but there are some pesky issues with it as it stands.

Graffiti

I’ve tried lots of things: first I started with graffiti, which is a great library and the only game in town for MongoDB. It also has great introspection and decent support for relations. You pass your existing mongoose models and it makes types out of them. Querying and mutation of basic primitives is easy, but I’m still not sure how to make belongsTo/hasOne mutations in one go, but I’ll save elaborating on that for another post. The best thing about graffiti is that it has “hooks” — functions that you can specify to run both pre and post resolve() execution. These hooks allow you to in theory — easily set up authorization, but it is quite tedious and error prone in practice. The biggest problem with trying to implement authorization in Graffiti is actually underneath the stack, in MongoDB; MongoDB doesn’t have a notion of authorization, it leaves that to the application.

[Edit: https://docs.mongodb.com/manual/core/authorization/]

PostGraphQL

So, coupled with the twin issues of MongoDB relations not being 100% solid in graffiti, and MongoDB authorization not being straightforward, we look further afield and stumble upon postgraphql. Postgraphql is also a great library, once you understand what it’s doing and how simple it is to setup.

Postgraphql simply connects to your existing database and makes GraphQL types and relational connections out of your tables. It’s very sophisticated in this regard, and goes far beyond graffiti’s capabilities here. For instance, it supports stored procedures.

By switching to PostgresQL, authorization is also virtually free, because Postgres was bred for the ACL, role-based, sysadmin-gives-privileges world.

But, alas, there’s no support for hooks like graffiti has, so if you have authorization that depends on external data sources, you won’t get much love from PostGraphQL. What’s more, because postgraphql doesn’t cleanly expose its externals, you’re forced to either fork the library in order to ‘patch’ new schema types in, or live with it tightly controlling everything. So we continue our search.

sql-to-graphql

Another library I found was sql-to-graphql. This library also does introspection of many relational databases, though not nearly as thoroughly as postgraphql. The postgres solution wasn’t working, so I forked it, and made it work after a little bit of bit twiddling. What I liked about this library was that it wasn’t very opinionated and, without digging too far into the code, it could point me in the direction I needed to go in order to develop what I want. It simply outputs CJS or ES6 types from your tables and wires them up in a generated app you can run. You are then free to edit the resulting types and connections.

An idea begins to take shape

What if we could have hooks, table introspection, ACL authorization, custom types, and a nice database migration management system all in one? I’ve decided to build just that, using inspiration from all of the above libraries. I’m calling it Mastodon, and I’ll be documenting how it will work in coming posts as I build it.

Edit: 1/17/2017 — read Part 2