Data work is grueling work. I’ve been working with databases since my first job developing student information databases in 1988 (don’t tell my wife). I’ve worked with Cobol, Foxpro, SQL Server, Filemaker, Access, MySQL, PostGres, and now Aurora databases over the last 30 years. I like data. I can even trick myself into doing massive data and schema refinement tasks on a regular basis. It is still grueling work that I rarely look forward to doing. Every company I’ve worked for has a big data problem. Data is not easy work, and the more data you accumulate, the more this work grows out of control. Getting teams of people to agree upon what needs to happen when it comes to schema and data storage, and actually execute upon the work in a timely, cost effective, and efficient way is almost always an impossible task. Which leaves me questioning (again), why GraphQL believers think they are going to be successfully in offshoring the cognitive and tangible work load to understand what data delivers, and then successfully apply it to a meaningful and monetizable business outcome.
Don’t get me wrong. I get the use cases where GraphQL makes sense. Where you have an almost rabid base of known consumers, who have a grasp on the data in play, and possesses an awareness of the schema behind. I’m have made the case for GraphQL as a key architectural component within a platform before. The difference in my approach over the majority of GraphQL believers, is that I’m acknowledging there is a specific group of savvy folks who need access to data, and understand the schema. I’m also being honest about who ends up doing the heavy data lifting here—-making sure this group wants it. However, I have an entirely separate group of users (the majority) who do not understand the schema, and have zero interest in doing the hard work to understand the schema, navigate relationships, and develop queries—-they just want access. Now. They don’t want to have to think about the big picture, they want one single bit of data, or a series of bits.
I’ve worked hard to engage in debate with GraphQL believers, and try to help provide them with advice on their approach. They aren’t interested. They operate within the echo chamber. They see a narrow slice of the API pie, and passionately believe their tool is the one solution. Like many API tooling peddlers who originate from within the echo chamber, they are hyper focused on the technology of managing our data. They think all data wranglers are like them. They think all data-driven companies are like theirs. They do not see the diverse types of API solutions that I see working across companies, institutions, organizations, and government agencies. They are not always aware of the business and political barriers that lie in between a belief in an API tool, and achieving a sustained implementation across the enterprise. They have that aggressive, tenacious startup way of penetrating operations, something that works well within the echo chamber, but it is an approach that will lose strength, and even begin to work against you outside the eco chamber within mainstream business operations.
I definitely see some interesting and useful tooling coming out of the GraphQL community. GraphQL is a tool in my API toolbox right along with REST, Hypermedia, Siren, HAL, JSON API, Alps, JSON Schema, Schema.org, OpenAPI, Postman Collections, Async API, Webhooks, Kafka, NATS, NGINX, Docker, and others. It has a purpose. It isn’t the silver bullet for me getting a handle on large amounts of data. It is one thing I consider when I’m trying to make sense of large data sets, and depending on the platform, the resources I have on staff, and the consumers, or the industry I am operating in–I MAY apply GraphQL. However, the times I will be able to successfully get it in the door, past legal, approved by leadership, accepted by internal developers, and then accepted and applied successfully by external developers, will be much fewer because of the aggressive echo chamber, investor-driven approach, which does not help sell the tool to my enterprise customers who have been investing in evolving their schema, and developing a suite of internal and external APIs over the last 20+ years. You might help me sell to a Silicon Valley savvy company, but you aren’t helping me in the mainstream enterprise.
This post will get the usual lineup of critical Tweets and comments. It’s fine. Once again the fact that I’m trying to help will be lost on believers. You will be more successful if you are honest about how the cognitive and tangible workload is being shifted here. You are refusing to do the hard work to properly define and organize your schema, and provide meaningful imperative API capabilities that any developer can easily use, over providing a single declarative interface (and some tooling) to empower consumers to make sense of the schema, and access platform capabilities on their own. This works well with folks who are willing to take on the cognitive load of knowing the schema, knowing GraphQL, then are willing to accept the real work of crafting queries to get at what they desire. There are a whole lot of assumptions there that do not apply in all situations. I’d say about 12% of people I’ve worked with in my career would sign up for this. The rest of them, just want to get their task accomplished—get out of their way and give them an interface that is capable of accomplishing it for them.
Nobody wants to do data shit work. If you do, get help. It is a job that is only growing because our ability to generate, harvest, and store data has grown. There is a belief that data provides answers, without being really honest about what it takes to actually clean, refine, and organize the data, let alone any truthfulness regarding whether or not the answers are ever even there after we do invest in doing the dirty data work. Everyone is drowning in data. Everyone is chasing more data. Few are managing it well. This type of environment makes new data tooling very sexy. However, sexy tools rarely change the actual behavior on the ground within the enterprise. People still aren’t going to change behaviors overnight. GraphQL tooling will not solve all of our data problems. Ideally, we would see more interoperability of tooling between GraphQL and other API design, deployment, management, testing, monitoring, mocking, and client tooling. Like we are seeing with IBM Loopback, Postman, and others. Ideally, we would see less rhetoric around GraphQL being the one solution to rule them all. Ideally, we’d see less investor-driven rhetoric, and more real world solutions for applying through the mainstream business world. But, I’m guessing I’ll see the same response I’ve been getting on these posts since 2016. ;-(
