8 ms·

Wait, people are using graphql for private, not exposed, backend apis? Who would torture themselves like that? Isn't the whole point that your frontend can ma

Wait, people are using graphql for private, not exposed, backend apis? Who would torture themselves like that? Isn't the whole point that your frontend can make the exact queries it needs and load the exact data it needs? Namely, last I checked, client libraries for working with graphql are only good with JS. I tried working with graphql a few years ago in python and the only two client libraries absolutely sucked. Server libraries were great, but python clients sucked, badly. I ended up writing bare requests with a hardcoded heredoc for the query and endless square brackets to get the fields for the little data I needed. Maybe the situation improved dramatically in the last three years, but I can't imagine so dramatically. I wouldn't pick graphql as a private backend API in a million years. Well, maybe if ever single service was written in nodejs with no possibility of using other languages.

tossandthrow 2y ago
Pothos + graphql Zeus gives us the ability to expose a prisma like interface to the clients with the ability to curate what fields are exposed and maintain the ability to setup field level security. Oh, and we get DB schema to frontend propagation of changes to the type. This is by far the best experience I have had for private APIs - Where we don't need to maintain backwards compatability. I do get that the HN crowd is super adverse to graphql, but I fail to see other arguments than matters of taste.
- vosper 2y ago
  Would you consider this solution for a public (enterprise/B2B, not public-on-the-internet-for-anyone) API? I may need to build a public API that lets customers select certain fields from a variety of objects with many fields.
  - tossandthrow 2y ago
    Hmm, this is a really good questions and would definitely require a bit more information about the customer relation to fully answer. In a setup where you can deprecate fields and remove them after X weeks I think it could wor well - My impression is just not that enterprise works like that? I would probably go the route of having fully versioned APIs in the specific setup (GraphQl or not) - which is something that would be a hassle with a tight coupling between the Prisma schema and the GraphQl schema as proposed. Thinking about it, all the situations where I have successfully used GraphQL, there has been a relatively tight coupling between the database schema and the graphQl schema. Previously it has been Ecto + Absinthe + Zeus (Elixir on the backend).
    - vosper 2y ago
      Thank you for that. You’re right that there will need to be long-term support of API versions (or at least the current one and maybe the previous one). My instinct is to give the users the full objects and let them select the fields they want on their side. It’s less work on our side. Also I’m not sure about customer comfort with GraphQL.
      - tossandthrow 2y ago
        Where GraphQL really shines is in the synthetic fields - the ones that are just too expensive to compute for all requests, but kind of make sense to have en the entity. Most interesting applications have some type of properties of entities that transcent a static object.
doughnutsonly 2y ago
I had the same thought. Genuinely curious to hear of anyone that has used it for a private API and why.
joeldo 2y ago
I think there is some confusion with the term 'public' here. The Graphql server itself is still publicly exposed to the internet, but the ability to query is not. Queries have to be whitelisted ahead of time (persisted queries).
jiggawatts 2y ago
You’d be amazed at how much self-inflicted difficulties developers are willing to subject themselves to in the name of doing things in the same way that a FAANG does.
doctor_eval 2y ago
This is nonsense. GraphQL queries are simple HTTP requests, with no more complexity than REST. You POST a query string and some JSON and it’s done. If your client makes it harder than that, don’t use it. Here’s my workflow for creating an API with Postgraphile: create view graphql.object as select some,columns from table; (That’s it) It’s trivial to query it with curl, I’d give an example but I’m afk rn. I’ve been using GraphQL for about the same amount of time as in the article and it solved a bunch of problems for me. It’s so easy to use, and saves so much time - once you spend the time to understand it.
- dudus 2y ago
  I've veen reading about graphql forever and never understood it. Your comment finally made it click for me. Do you happen to have any more documentation around your method of working?
  - doctor_eval 2y ago
    Unfortunately I’m on a bus to the airport for a couple of days so I’m a bit constrained. If you know Postgres, I would recommend taking a look at Postgraphile. It’s awesome, and comes with an explorer web UI that really helps (GraphIQL with extras). Everything happens in real time. so if you update a view, the UI updates. There are lots of GraphQL clients but many of them do all sorts of crap you don’t need. I just use graphql-request which is super simple. But of course you can just use fetch() too. There are also lots of “standards” for GraphQL that make it seem more complex than it is. Ignore that stuff and just start playing with a good server like Postgraphile. Good luck!
- megadal 2y ago
  > This is nonsense. GraphQL queries are simple HTTP requests, with no more complexity than REST. You POST a query string and some JSON The complexity of GraphQL in fact begins there, and also sort of explains a lot of why GraphQL is all but simple: Why am I using a query language instead of just passing an AST via JSON, a data format every general purpose language supports very well these days? The answer to the above question, and most of GraphQLs other complexities: Some arbitrary design decision. Another example: GraphQL could've easily been expressed as a REST API, even an Open API. From what I have seen, with the help of VC backing and FAANG endorsement, GraphQL mostly rose to replace JSON:API, which accomplishes pretty much all of the same goals in just JSON (and is RESTful). One big issue of GraphQL is also that API clients tend to suck. That's not a problem for OpenAPIs. And again, why is this the case? Some arbitrary design decision. I feel like in general, someone creating a new DSL where it's not needed (and is obviously designed to look cool rather than actually be expressive), is a good sign they're just writing the software to stroke their ego rather than reach a meaningful end. That's why in all the promo material for GraphQL you only see the query language, and not all of the actual setup required to send a request or even what an actual GraphQL HTTP request looks like. GraphQL, the framework, is not actually as simple and elegant as GraphQL the query language attempts to portray it as. It's almost like someone came up with a query language for fun then came up with all the details of how a web server would utilize it afterwards. Even today, GraphQL markets itself only as a query language (A query language for your API). When, as you have already mentioned, it is more than that. That's why most developers know vaguely what GraphQL is ("Oh, that one language") but not how it actually works in practice. And when they actually encounter it, it feels almost like a betrayal, because it's nowhere near as simple, sleek or elegant as all the marketing they saw suggested. At least, this was my experience when having to deal with a third party GraphQL API (funny enough, they migrated from REST, see ShipHero).
lijok 2y ago
Can’t understand people’s obsession with client libraries. What need is there for a graphql client? Why is writing raw queries insufficient?
- valenterry 2y ago
  Because people like to use typed languages and in that case writing raw queries makes you work against the typesystem essentially.
  - lijok 2y ago
    I see, so bindings for gql constructs is what we’re after?
    - valenterry 2y ago
      Yeah. But since gql is very flexible, you then also want to combine them in an adhoc way but still get the right structure/types back. Then there is also batching, reusing inputs and so on, so ultimately a library saves a lot of time and effort when things grow bigger.
  - JoeyJoJoJr 2y ago
    If you use OpenAPI/Swagger you can most likely generate the client code along with the types. I use the npm package below, and it just seems to work simply without any headaches. https://github.com/hey-api/openapi-ts https://github.com/hey-api/openapi-ts
    - tossandthrow 2y ago
      so .. a matter of taste? Sure you enjoy swagger over the numerous GQL code gen alternatives.
      - JoeyJoJoJr 2y ago
        I was responding to your point specifically about manually writing code in typed languages, highlighting that there are solutions to avoid that. I am not dismissing your use of GraphQL.
rapsey 2y ago
> Who would torture themselves like that? Because people love chasing tech fads.
alexchamberlain 2y ago
I wrote a series of backend, internal GraphQL APIs. I think the argument of "make the exact queries it needs and load the exact data it needs" actually applies _more_ to internal APIs than to frontends, where I personally prefer a well schema'd BFF pattern. We did face some performance issues with some of the server libraries, unfortunately, but the backend development team were extremely productive in comparison to supporting multiple API shapes.
rtpg 2y ago
I think the public/private distinction here is more in "officially allowed for public use" vs "API your frontend uses but is not documented for public use". Obviously security is still a thing, but having good ergonomics for your frontend devs means your frontend devs can just work forward and backend people can focus on other things instead of going back and forth on perf issues downstream of REST APIs
- troupo 2y ago
  > and backend people can focus on other things instead of going back and forth on perf issues downstream of REST APIs Instead they now focus on perf problems of downstream federated GraphQL queries. And query complexity. And unbounded queries. And extreme overfetching of data that all clients inevitably do. And...
  - rtpg 2y ago
    If anything REST APIs encourage overfetching, because you are almost never getting exactly the set of data you need. Unbounded queries and extreme overfetching in general are problems that are ... easy-ish to solve when it's totally internal. Just be measuring perf, tag queries you are making to the frontend page you're making them from, and coordinate with frontend people if there's a problem. Performance doesn't magically improve if you're using REST. And joins don't magically make things slower than "join via HTTP request" either. There might be patterns that are dangerous in GraphQL but honestly I feel like most internal APIs would benefit from easier scoping of fields and the like (rather than everyone re-inventing ad-hoc expansion and filtering)
    - troupo 2y ago
      > Performance doesn't magically improve if you're using REST. And joins don't magically make things slower than "join via HTTP request" either. In REST you know the exact query and can optimise the hell out of it. Not so in GraphQL, where each query is potentially a new, never before seen request. Unless you use and optimise for persisted queries which just makes it REST with extra steps. And for large companies even that may not be an option since every query will end up being a persisted query once you deploy to production.
JoRyGu 2y ago
We use it for an application that aggregates data for consumption by several different teams that all consume different subsets of the data. When you have a pretty simple use-case it's really not that bad to get a decently functioning API off the ground, and because it's self-documenting we can spend our time on more mission critical work.
deergomoo 2y ago
I remain unconvinced that GraphQL is the tech we should have chosen, but we’re using it privately to mesh together subgraphs from different teams’ various areas of concern and it seems to be working pretty well. There’s been talk of opening it up to clients, but the idea of trying to apply a permission/access control layer is nightmare material. As for language support, I’ve used a couple of libraries on both the client and server side for both Go and PHP, and they seem pretty good. JavaScript/TypeScript definitely seem to be the first-class citizens though.
- throwaway3306a 2y ago
  > but the idea of trying to apply a permission/access control layer is nightmare material. In your case of many disparate services, the nightmare is just the same with REST.
  - megadal 2y ago
    Comparing GraphQL to REST and not a RESTful Graph-based data access API like JSON:API is just being disingenuous. For GraphQL, you know it will be a nightmare. For REST, you don't, because you don't know what the actual API is. It could be a stopwatch API, obviously a stopwatch REST API is not comparable to GraphQL.
    - throwaway3306a 2y ago
      That doesn't matter at all. Handling authorization at the federation gateway point is a nightmare in any case. At least with GraphQL the scope is limited.
      - megadal 2y ago
        GraphQL literally is a "federation gateway point." It's literally meant to be a gateway to a bunch of different external systems working in federation. It's the exact same scope if you used a RESTful graph based data access API that connected to external systems.. Outside all the GraphQL jargon and gobbledygook you'll see that GraphQL is not some groundbreaking, unique or foundational product... The concept of generating graph based data access APIs from schemas is probably older than the concept of phones that can send emails. The only "innovation" is the "query language"... > That doesn't matter at all. I honestly don't know why I'm taking this seriously. Yes, it matters, your entire point was a comparison.. that your comparison is foundationally invalid matters when assessing the validity of your entire argument..
ecjhdnc2025 2y ago
> Who would torture themselves like that? It's not really torture. I do. I have built a private federation API in a system where there's a "mothership" service that needs to talk to individual websites. Those websites are WordPress at the moment but they may be Magento, PrestaShop or whatever in the future. GraphQL means I can template the API calls used to keep them in sync with the mothership. It's awesome. I also use it for the frontend/backend connection of a couple of admin APIs and an intranet app. Nuxt frontends, Laravel/Lighthouse headless backends. The only pain point is the unnecessarily complex Apollo stuff in the client, but that gives you really nice smart queries in Nuxt 2; it may not be that crucial in Vue 3/Nuxt 3.
- chuckadams 2y ago
  > that gives you really nice smart queries in Nuxt 2; it may not be that crucial in Vue 3/Nuxt 3. It's even better with Vue 3 (or Vue 2 with the composition API anyway), especially when you combine it with graphql-codegen. Smart queries become just another composable, no `this.$apollo` to be seen. Got that going with API Platform on the backend myself, which has really nice integration with symfony, though it speaks only a bare-bones dialect of graphql as opposed to Lighthouse with all its crazy directives. No persisted queries either, but it's an internal app with bandwidth to burn. Been eying wp-graphql for my one wordpress project. From my dabbling with it, the DX feels a lot nicer than the WP REST api, though I'm sure you know that's an awfully low bar to clear.
  - ecjhdnc2025 2y ago
    > especially when you combine it with graphql-codegen. I did not know about this, thank you. > Been eying wp-graphql for my one wordpress project. From my dabbling with it, the DX feels a lot nicer than the WP REST api, though I'm sure you know that's an awfully low bar to clear. Yes on both scores. There's a reasonably useful Woocommerce binding: https://github.com/wp-graphql/wp-graphql-woocommerce https://github.com/wp-graphql/wp-graphql-woocommerce Which is what I was using for the federated storefronts, with the API locked down so it could only be accessed from a back-office client I hooked up with a Laravel worker. At the time it was very early days, but wp-graphql has quite a sane interaction with the hooks/actions model, so it's not awfully difficult to add/patch/override the things you need.
1vuio0pswjnm7 2y ago
Gratuitous complexity is a strong attractor for today's "developer".
- bsaul 2y ago
  After 25y of dev xp, my only focus now is on simplicity (as in, making code obvious). However this is by far the most difficult thing to accomplish.
  - nxicvyvy 2y ago
    In my experience the focus should be on avoiding incidental complexity. Essential complexity born from business problems are counter intuitively often better left complex.
    - bsaul 2y ago
      Depends on where you're working on the stack. Humans processes ( accounting, HR, etc) are complex by having evolved in world of murky definitions, but they work because people generally understand things and fill the gap. When trying to model those, then yes for sure things are going to look complex and you don't have much choice. However, for all technical things, then i've noticed that things can be made quite obvious if you really focus on the exact problem you actually have to solve, and have a good understanding of its nature.
  - norman784 2y ago
    When I was younger I was eager to experiment with things, abstractions, etc, now I want to write (in the web development context) as much html, vanilla js and raw sql.
rbalicki 2y ago
> backend APIs Using GraphQL for service-to-service communication isn’t the sweet spot if you can deploy both services together. Rather, it’s great if the services are deployed on their own schedule. This is the case if one service is someone’s browser, where forcing a refresh whenever the backend is redeployed isn’t tenable. For service-to-service communication, where you can deploy both together, gRPC or something is a better option.
hleszek 2y ago
As the current maintainer of graphql-python/gql, the most popular python client, I have to say that you should definitely try again to get an accurate opinion. A lot of changes have been made around that time and we are quite feature-full and stable right now, with 100% code coverage and good documentation.
gregors 2y ago
Graphql is by far the most painful DX and least productive thing I've seen cargo-culted. Like most things there's a time and place for Graphql but I think it's vastly overused. For backend services in particular literally anything else is probably a better choice - rest, grpc, soap, a socket. I honestly don't know why more people don't give twirp a shot. https://github.com/twitchtv/twirp https://github.com/twitchtv/twirp
- tossandthrow 2y ago
  Do you have anything to back your pain? How do you use it since you have arrived at such poor DX?

tossandthrow 2y ago

Pothos + graphql Zeus gives us the ability to expose a prisma like interface to the clients with the ability to curate what fields are exposed and maintain the ability to setup field level security. Oh, and we get DB schema to frontend propagation of changes to the type. This is by far the best experience I have had for private APIs - Where we don't need to maintain backwards compatability. I do get that the HN crowd is super adverse to graphql, but I fail to see other arguments than matters of taste.

vosper 2y ago
Would you consider this solution for a public (enterprise/B2B, not public-on-the-internet-for-anyone) API? I may need to build a public API that lets customers select certain fields from a variety of objects with many fields.
- tossandthrow 2y ago
  Hmm, this is a really good questions and would definitely require a bit more information about the customer relation to fully answer. In a setup where you can deprecate fields and remove them after X weeks I think it could wor well - My impression is just not that enterprise works like that? I would probably go the route of having fully versioned APIs in the specific setup (GraphQl or not) - which is something that would be a hassle with a tight coupling between the Prisma schema and the GraphQl schema as proposed. Thinking about it, all the situations where I have successfully used GraphQL, there has been a relatively tight coupling between the database schema and the graphQl schema. Previously it has been Ecto + Absinthe + Zeus (Elixir on the backend).
  - vosper 2y ago
    Thank you for that. You’re right that there will need to be long-term support of API versions (or at least the current one and maybe the previous one). My instinct is to give the users the full objects and let them select the fields they want on their side. It’s less work on our side. Also I’m not sure about customer comfort with GraphQL.
    - tossandthrow 2y ago
      Where GraphQL really shines is in the synthetic fields - the ones that are just too expensive to compute for all requests, but kind of make sense to have en the entity. Most interesting applications have some type of properties of entities that transcent a static object.

doughnutsonly 2y ago

I had the same thought. Genuinely curious to hear of anyone that has used it for a private API and why.

joeldo 2y ago

I think there is some confusion with the term 'public' here. The Graphql server itself is still publicly exposed to the internet, but the ability to query is not. Queries have to be whitelisted ahead of time (persisted queries).

jiggawatts 2y ago

You’d be amazed at how much self-inflicted difficulties developers are willing to subject themselves to in the name of doing things in the same way that a FAANG does.

doctor_eval 2y ago

This is nonsense. GraphQL queries are simple HTTP requests, with no more complexity than REST. You POST a query string and some JSON and it’s done. If your client makes it harder than that, don’t use it. Here’s my workflow for creating an API with Postgraphile: create view graphql.object as select some,columns from table; (That’s it) It’s trivial to query it with curl, I’d give an example but I’m afk rn. I’ve been using GraphQL for about the same amount of time as in the article and it solved a bunch of problems for me. It’s so easy to use, and saves so much time - once you spend the time to understand it.

dudus 2y ago
I've veen reading about graphql forever and never understood it. Your comment finally made it click for me. Do you happen to have any more documentation around your method of working?
- doctor_eval 2y ago
  Unfortunately I’m on a bus to the airport for a couple of days so I’m a bit constrained. If you know Postgres, I would recommend taking a look at Postgraphile. It’s awesome, and comes with an explorer web UI that really helps (GraphIQL with extras). Everything happens in real time. so if you update a view, the UI updates. There are lots of GraphQL clients but many of them do all sorts of crap you don’t need. I just use graphql-request which is super simple. But of course you can just use fetch() too. There are also lots of “standards” for GraphQL that make it seem more complex than it is. Ignore that stuff and just start playing with a good server like Postgraphile. Good luck!
megadal 2y ago
> This is nonsense. GraphQL queries are simple HTTP requests, with no more complexity than REST. You POST a query string and some JSON The complexity of GraphQL in fact begins there, and also sort of explains a lot of why GraphQL is all but simple: Why am I using a query language instead of just passing an AST via JSON, a data format every general purpose language supports very well these days? The answer to the above question, and most of GraphQLs other complexities: Some arbitrary design decision. Another example: GraphQL could've easily been expressed as a REST API, even an Open API. From what I have seen, with the help of VC backing and FAANG endorsement, GraphQL mostly rose to replace JSON:API, which accomplishes pretty much all of the same goals in just JSON (and is RESTful). One big issue of GraphQL is also that API clients tend to suck. That's not a problem for OpenAPIs. And again, why is this the case? Some arbitrary design decision. I feel like in general, someone creating a new DSL where it's not needed (and is obviously designed to look cool rather than actually be expressive), is a good sign they're just writing the software to stroke their ego rather than reach a meaningful end. That's why in all the promo material for GraphQL you only see the query language, and not all of the actual setup required to send a request or even what an actual GraphQL HTTP request looks like. GraphQL, the framework, is not actually as simple and elegant as GraphQL the query language attempts to portray it as. It's almost like someone came up with a query language for fun then came up with all the details of how a web server would utilize it afterwards. Even today, GraphQL markets itself only as a query language (A query language for your API). When, as you have already mentioned, it is more than that. That's why most developers know vaguely what GraphQL is ("Oh, that one language") but not how it actually works in practice. And when they actually encounter it, it feels almost like a betrayal, because it's nowhere near as simple, sleek or elegant as all the marketing they saw suggested. At least, this was my experience when having to deal with a third party GraphQL API (funny enough, they migrated from REST, see ShipHero).

lijok 2y ago

Can’t understand people’s obsession with client libraries. What need is there for a graphql client? Why is writing raw queries insufficient?

valenterry 2y ago
Because people like to use typed languages and in that case writing raw queries makes you work against the typesystem essentially.
- lijok 2y ago
  I see, so bindings for gql constructs is what we’re after?
  - valenterry 2y ago
    Yeah. But since gql is very flexible, you then also want to combine them in an adhoc way but still get the right structure/types back. Then there is also batching, reusing inputs and so on, so ultimately a library saves a lot of time and effort when things grow bigger.
- JoeyJoJoJr 2y ago
  If you use OpenAPI/Swagger you can most likely generate the client code along with the types. I use the npm package below, and it just seems to work simply without any headaches. https://github.com/hey-api/openapi-ts https://github.com/hey-api/openapi-ts
  - tossandthrow 2y ago
    so .. a matter of taste? Sure you enjoy swagger over the numerous GQL code gen alternatives.
    - JoeyJoJoJr 2y ago
      I was responding to your point specifically about manually writing code in typed languages, highlighting that there are solutions to avoid that. I am not dismissing your use of GraphQL.

rapsey 2y ago

> Who would torture themselves like that? Because people love chasing tech fads.

alexchamberlain 2y ago

I wrote a series of backend, internal GraphQL APIs. I think the argument of "make the exact queries it needs and load the exact data it needs" actually applies _more_ to internal APIs than to frontends, where I personally prefer a well schema'd BFF pattern. We did face some performance issues with some of the server libraries, unfortunately, but the backend development team were extremely productive in comparison to supporting multiple API shapes.

rtpg 2y ago

I think the public/private distinction here is more in "officially allowed for public use" vs "API your frontend uses but is not documented for public use". Obviously security is still a thing, but having good ergonomics for your frontend devs means your frontend devs can just work forward and backend people can focus on other things instead of going back and forth on perf issues downstream of REST APIs

troupo 2y ago
> and backend people can focus on other things instead of going back and forth on perf issues downstream of REST APIs Instead they now focus on perf problems of downstream federated GraphQL queries. And query complexity. And unbounded queries. And extreme overfetching of data that all clients inevitably do. And...
- rtpg 2y ago
  If anything REST APIs encourage overfetching, because you are almost never getting exactly the set of data you need. Unbounded queries and extreme overfetching in general are problems that are ... easy-ish to solve when it's totally internal. Just be measuring perf, tag queries you are making to the frontend page you're making them from, and coordinate with frontend people if there's a problem. Performance doesn't magically improve if you're using REST. And joins don't magically make things slower than "join via HTTP request" either. There might be patterns that are dangerous in GraphQL but honestly I feel like most internal APIs would benefit from easier scoping of fields and the like (rather than everyone re-inventing ad-hoc expansion and filtering)
  - troupo 2y ago
    > Performance doesn't magically improve if you're using REST. And joins don't magically make things slower than "join via HTTP request" either. In REST you know the exact query and can optimise the hell out of it. Not so in GraphQL, where each query is potentially a new, never before seen request. Unless you use and optimise for persisted queries which just makes it REST with extra steps. And for large companies even that may not be an option since every query will end up being a persisted query once you deploy to production.

JoRyGu 2y ago

We use it for an application that aggregates data for consumption by several different teams that all consume different subsets of the data. When you have a pretty simple use-case it's really not that bad to get a decently functioning API off the ground, and because it's self-documenting we can spend our time on more mission critical work.

deergomoo 2y ago

I remain unconvinced that GraphQL is the tech we should have chosen, but we’re using it privately to mesh together subgraphs from different teams’ various areas of concern and it seems to be working pretty well. There’s been talk of opening it up to clients, but the idea of trying to apply a permission/access control layer is nightmare material. As for language support, I’ve used a couple of libraries on both the client and server side for both Go and PHP, and they seem pretty good. JavaScript/TypeScript definitely seem to be the first-class citizens though.

throwaway3306a 2y ago
> but the idea of trying to apply a permission/access control layer is nightmare material. In your case of many disparate services, the nightmare is just the same with REST.
- megadal 2y ago
  Comparing GraphQL to REST and not a RESTful Graph-based data access API like JSON:API is just being disingenuous. For GraphQL, you know it will be a nightmare. For REST, you don't, because you don't know what the actual API is. It could be a stopwatch API, obviously a stopwatch REST API is not comparable to GraphQL.
  - throwaway3306a 2y ago
    That doesn't matter at all. Handling authorization at the federation gateway point is a nightmare in any case. At least with GraphQL the scope is limited.
    - megadal 2y ago
      GraphQL literally is a "federation gateway point." It's literally meant to be a gateway to a bunch of different external systems working in federation. It's the exact same scope if you used a RESTful graph based data access API that connected to external systems.. Outside all the GraphQL jargon and gobbledygook you'll see that GraphQL is not some groundbreaking, unique or foundational product... The concept of generating graph based data access APIs from schemas is probably older than the concept of phones that can send emails. The only "innovation" is the "query language"... > That doesn't matter at all. I honestly don't know why I'm taking this seriously. Yes, it matters, your entire point was a comparison.. that your comparison is foundationally invalid matters when assessing the validity of your entire argument..

ecjhdnc2025 2y ago

> Who would torture themselves like that? It's not really torture. I do. I have built a private federation API in a system where there's a "mothership" service that needs to talk to individual websites. Those websites are WordPress at the moment but they may be Magento, PrestaShop or whatever in the future. GraphQL means I can template the API calls used to keep them in sync with the mothership. It's awesome. I also use it for the frontend/backend connection of a couple of admin APIs and an intranet app. Nuxt frontends, Laravel/Lighthouse headless backends. The only pain point is the unnecessarily complex Apollo stuff in the client, but that gives you really nice smart queries in Nuxt 2; it may not be that crucial in Vue 3/Nuxt 3.

chuckadams 2y ago
> that gives you really nice smart queries in Nuxt 2; it may not be that crucial in Vue 3/Nuxt 3. It's even better with Vue 3 (or Vue 2 with the composition API anyway), especially when you combine it with graphql-codegen. Smart queries become just another composable, no `this.$apollo` to be seen. Got that going with API Platform on the backend myself, which has really nice integration with symfony, though it speaks only a bare-bones dialect of graphql as opposed to Lighthouse with all its crazy directives. No persisted queries either, but it's an internal app with bandwidth to burn. Been eying wp-graphql for my one wordpress project. From my dabbling with it, the DX feels a lot nicer than the WP REST api, though I'm sure you know that's an awfully low bar to clear.
- ecjhdnc2025 2y ago
  > especially when you combine it with graphql-codegen. I did not know about this, thank you. > Been eying wp-graphql for my one wordpress project. From my dabbling with it, the DX feels a lot nicer than the WP REST api, though I'm sure you know that's an awfully low bar to clear. Yes on both scores. There's a reasonably useful Woocommerce binding: https://github.com/wp-graphql/wp-graphql-woocommerce https://github.com/wp-graphql/wp-graphql-woocommerce Which is what I was using for the federated storefronts, with the API locked down so it could only be accessed from a back-office client I hooked up with a Laravel worker. At the time it was very early days, but wp-graphql has quite a sane interaction with the hooks/actions model, so it's not awfully difficult to add/patch/override the things you need.

1vuio0pswjnm7 2y ago

Gratuitous complexity is a strong attractor for today's "developer".

bsaul 2y ago
After 25y of dev xp, my only focus now is on simplicity (as in, making code obvious). However this is by far the most difficult thing to accomplish.
- nxicvyvy 2y ago
  In my experience the focus should be on avoiding incidental complexity. Essential complexity born from business problems are counter intuitively often better left complex.
  - bsaul 2y ago
    Depends on where you're working on the stack. Humans processes ( accounting, HR, etc) are complex by having evolved in world of murky definitions, but they work because people generally understand things and fill the gap. When trying to model those, then yes for sure things are going to look complex and you don't have much choice. However, for all technical things, then i've noticed that things can be made quite obvious if you really focus on the exact problem you actually have to solve, and have a good understanding of its nature.
- norman784 2y ago
  When I was younger I was eager to experiment with things, abstractions, etc, now I want to write (in the web development context) as much html, vanilla js and raw sql.

rbalicki 2y ago

> backend APIs Using GraphQL for service-to-service communication isn’t the sweet spot if you can deploy both services together. Rather, it’s great if the services are deployed on their own schedule. This is the case if one service is someone’s browser, where forcing a refresh whenever the backend is redeployed isn’t tenable. For service-to-service communication, where you can deploy both together, gRPC or something is a better option.

hleszek 2y ago

As the current maintainer of graphql-python/gql, the most popular python client, I have to say that you should definitely try again to get an accurate opinion. A lot of changes have been made around that time and we are quite feature-full and stable right now, with 100% code coverage and good documentation.

gregors 2y ago

Graphql is by far the most painful DX and least productive thing I've seen cargo-culted. Like most things there's a time and place for Graphql but I think it's vastly overused. For backend services in particular literally anything else is probably a better choice - rest, grpc, soap, a socket. I honestly don't know why more people don't give twirp a shot. https://github.com/twitchtv/twirp https://github.com/twitchtv/twirp

tossandthrow 2y ago
Do you have anything to back your pain? How do you use it since you have arrived at such poor DX?