[blueslurpee]

I haven't read enough about GraphQL (or even used it) to debate its relative merits, but I find it very interesting from "business architecture" point of view.

For instance, assume the future of IT looks like it does today, only ramped up x10. Imagine the majority of business value is driven disparate API's/Services managed by companies or organisations, with numerous and diverse clients that can "plug in" for their respective needs.

GraphQL essentially allows you to simplify the work that any client (internal or external) needs to do to tap into your interface, provided that you invest the appropriate resources on the backend. (which you would, if that were your core business proposition and a piece of your competetive advantage)

If companies continue to digitalize (is there any doubt) then a company's value will be encompassed and driven by the quality of its API, and importantly, it's relative use of connecting with many diverse clients. Therefore backend API's that support and interface to digital products the best will win.

I see GraphQL supporting this in that it trades simplicity and a uniform mono-interface on the front-end for complexity on the backend. I think a lot of firms will look at that trade and call it a great deal.

[ericb]

Ugh, no. The problems of just exposing your database really come out after you try living with it.

We wanted to make schema changes on the back-end, but the front-end queries were tied to it. Those queries were in apps run by different groups, with different goals and timetables, but we couldn't break them. If we had a defined API, we could be free to modify any back-end implementation details that weren't directly exposed. We couldn't because every detail was baked into consuming apps. What was our API, and where did it end? Now it was the entire database!

When we had to source data from elsewhere, or provide it via logical abstraction, we ended up piling hacks on top of the data structure's "API" from the back end that was now replicated in the front-end in order to "maintain it". Maintaining it really meant "providing an API that was the haunted ghost of our previous database schema "API" because now other apps/clients expected that "API".

[orf]

Who’s exposing their database? Why? You’re exposing a view over your data that may or may not live in a database.

None of your points apply directly to grapple, all apply to a REST based architecture. More so, I’d say.

[littlestymaar]

You're not exposing your database though (or at least you shouldn't be): you're exposing views. The set of views that you expose are your API. But it's not tied to your database schema than any kind of API (not less either though, if your database schema really doesn't match your API, your performances are likely to suffer sometimes, but that's true with any kind of API).

(I am in no way a GraphQL evangelist btw)

[8note]

AWS makes it way to easy to connect a database directly to an API, both for API gateway and app sync.

[8note]

It sounds like your main problem is that you cant get your callers prioritize making changes.

Using rest doesn mean you can stop supporting a call pattern because you feel like it. Somebody else still needs to do work before you can drop your translation layer

[pjmlp]

We don't need to imagine, that was the scenario being sold for CORBA/DCOM, then it was sold for SOAP/XML-RPC webservers,...

We even got stuff like Bizztalk and BPEL to orchestrate API calls with graphical workflows.

The circle of IT fashion.