4 ms·

Can't upvote this enough. From what I've read it sounds like GraphQL solves a problem at Facebook where they have so many people working on related data at the

by Touche 9y ago

Can't upvote this enough. From what I've read it sounds like GraphQL solves a problem at Facebook where they have so many people working on related data at the same time that they started seeing duplicate API endpoints, and duplicate requests for the same data from different parts of the team. GraphQL provides a chokepoint to prevent that from occurring. Makes total sense at that scale. Why startups are adopting this without that sort of problem, I have no idea. Because the query syntax is pretty?

deleted 9y ago
[deleted]
CodesInChaos 9y ago
A huge selling point for me is that the client explicitly enumerating all fields they're interested in allows targeted deprecation warnings and finely grained usage statistics.
- boubiyeah 9y ago
  That's nice yes. Isn't it rare to deprecate fields though? And you can't be sure some of your clients are not overfetching "for convenience / just in case", especially if they don't use the full suite of Facebook libs.
- Touche 9y ago
  Another thing that sounds worthy when working on gigantic teams and less so when at a startup / small company.
  - abritinthebay 9y ago
    Chose the right tech early and you’ll have less growth pain. I can’t tell you the number of startups I’ve seen that spend time thrashing on their REST APIs who would be better off using GraphQL as the consumable interface. Would have made many companies supplication development go WAY smoother
    - boubiyeah 9y ago
      You're saying "graphQL is always better than REST for new/small companies"; that's simply not true. It's a tradeoff. Same with (g)RPC. Just like you wouldn't buy and install 20 powerful servers to run kafka on day 1 just in case your startup meet huge success in 2 years.
      - abritinthebay 9y ago
        I did not say that at all, I urge you to re-read what I wrote.
  - CodesInChaos 9y ago
    It's mainly useful if the API consumers are outside your own company. For example my company is a small B2B SaaS startup and our customers integrate themselves into our platform via a web api.
curun1r 9y ago
There's some truth to what you're saying, but I think you're also selling GraphQL a bit short. Don't forget that Netflix also independently developed a very similar technology (Falcor) because of a need somewhat different than what you describe. In their case, there was a need to have a single server-side be able to support literally hundreds of different client-side implementations that often had vastly different capabilities. An implementation for an embedded "smart" BluRay player is going to be very different from the first-party implementation that someone pulls up when they visit the .com in Chrome. Not only will it have different memory/CPU requirements, the BluRay player's client probably won't even be written by Netflix employees. What GraphQL solves, to me, is any situation where the server-side implementation cannot make assumptions about the client-side. Whether that's because there are multiple clients or the client team is not coordinating their delivery with the server team, it's yet another example of the observation that software architecture eventually mirrors the way teams are organized. And I agree that many smaller businesses are probably jumping on the GraphQL bandwagon prematurely/unnecessarily. But I think the problem it solves is broader than you acknowledge and there are far more instances where the organization of the humans writing code favors an approach that decouples the server and client in the way that GraphQL and Falcor accomplishes.
SkyPuncher 9y ago
> Why startups are adopting this without that sort of problem, I have no idea. Because the query syntax is pretty? IMO, we're seeing a trend where the server doesn't necessarily strongly control what's sent to the client. You can build and deploy a simple server then move most complex logic to the client. It seems to make the development process a lot easier since you really only need to write client side data. That being said, I don't intend to use GraphQL anytime soon. It seems to be a bit of a loose cannon.
jrs95 9y ago
The query syntax isn't just pretty. It's simple enough non-technical users can actually use it with very little training.

by Touche 9y ago

deleted 9y ago

[deleted]

CodesInChaos 9y ago

A huge selling point for me is that the client explicitly enumerating all fields they're interested in allows targeted deprecation warnings and finely grained usage statistics.

boubiyeah 9y ago
That's nice yes. Isn't it rare to deprecate fields though? And you can't be sure some of your clients are not overfetching "for convenience / just in case", especially if they don't use the full suite of Facebook libs.
Touche 9y ago
Another thing that sounds worthy when working on gigantic teams and less so when at a startup / small company.
- abritinthebay 9y ago
  Chose the right tech early and you’ll have less growth pain. I can’t tell you the number of startups I’ve seen that spend time thrashing on their REST APIs who would be better off using GraphQL as the consumable interface. Would have made many companies supplication development go WAY smoother
  - boubiyeah 9y ago
    You're saying "graphQL is always better than REST for new/small companies"; that's simply not true. It's a tradeoff. Same with (g)RPC. Just like you wouldn't buy and install 20 powerful servers to run kafka on day 1 just in case your startup meet huge success in 2 years.
    - abritinthebay 9y ago
      I did not say that at all, I urge you to re-read what I wrote.
- CodesInChaos 9y ago
  It's mainly useful if the API consumers are outside your own company. For example my company is a small B2B SaaS startup and our customers integrate themselves into our platform via a web api.

curun1r 9y ago

There's some truth to what you're saying, but I think you're also selling GraphQL a bit short. Don't forget that Netflix also independently developed a very similar technology (Falcor) because of a need somewhat different than what you describe. In their case, there was a need to have a single server-side be able to support literally hundreds of different client-side implementations that often had vastly different capabilities. An implementation for an embedded "smart" BluRay player is going to be very different from the first-party implementation that someone pulls up when they visit the .com in Chrome. Not only will it have different memory/CPU requirements, the BluRay player's client probably won't even be written by Netflix employees. What GraphQL solves, to me, is any situation where the server-side implementation cannot make assumptions about the client-side. Whether that's because there are multiple clients or the client team is not coordinating their delivery with the server team, it's yet another example of the observation that software architecture eventually mirrors the way teams are organized. And I agree that many smaller businesses are probably jumping on the GraphQL bandwagon prematurely/unnecessarily. But I think the problem it solves is broader than you acknowledge and there are far more instances where the organization of the humans writing code favors an approach that decouples the server and client in the way that GraphQL and Falcor accomplishes.

SkyPuncher 9y ago

> Why startups are adopting this without that sort of problem, I have no idea. Because the query syntax is pretty? IMO, we're seeing a trend where the server doesn't necessarily strongly control what's sent to the client. You can build and deploy a simple server then move most complex logic to the client. It seems to make the development process a lot easier since you really only need to write client side data. That being said, I don't intend to use GraphQL anytime soon. It seems to be a bit of a loose cannon.

jrs95 9y ago

The query syntax isn't just pretty. It's simple enough non-technical users can actually use it with very little training.