7 ms·

It's much easier to debug and observe traffic (browser Network tab). The DX for JSON things is much better. The UX for protobufs is much better (faster, less d

It's much easier to debug and observe traffic (browser Network tab). The DX for JSON things is much better. The UX for protobufs is much better (faster, less data over the wire, etc). Which you optimize for is up to you, but there isn't a straightforward "Use this tech because it's the best one."

ZiiS 4y ago
Assuming your developer time is contained improved DX often also leads to better UX (more features). So even if you are optimizing for UX you may well be better with JSON.
- onion2k 4y ago
  also leads to better UX (more features) More features is not a measure of better UX. In many cases (most cases!?) it's the opposite.
  - ZiiS 4y ago
    Sorry; I meant more polished features as much as more by count.
halfmatthalfcat 4y ago
So does that make GraphQL the best then? JSON + faster/less data over the wire.
- counttheforks 4y ago
  Not when you count the DX of the backend developers. Good luck making a performant GraphQL backend that doesn't suffer the N+1 problem, and have fun whitelisting the GraphQL queries produced by your frontend, because attackers will be supplying their own queries with no regards to performance.
  - halfmatthalfcat 4y ago
    GraphQL has a DataLoader (to avoid N+1) and query complexity utilities to avoid those issues.
    - counttheforks 4y ago
      I know. Good luck implementing it performantly while also considering filtering, pagination, etc. It's doable of course, just not nearly as easy as people like to make it sound.
  - thejosh 4y ago
    Best experience I had with GraphQL was a B2B app where we had a fair amount of users, as well as the "backoffice" app also powered by GraphQL. Bad users we could just ban (the user base were great folks but could barely operate a computer, so it was fine). Backend was with Absinthe+Elixir, so it was great (if I had to do it again today I would instead use Liveview, this was in 2017 where I had to retrofit a React app into something useable). Public user facing is a different story, the last major one I saw was Tableau, though they are also business facing where they can just ban bad users. Github also has deprecated their GraphQL endpoints[0]. [0] https://github.blog/changelog/2022-08-18-deprecation-notice-graphql-for-packages/ https://github.blog/changelog/2022-08-18-deprecation-notice-...
    - foobazgt 4y ago
      Re: GitHub, that deprecation notice appears to be for GitHub Packages specifically. I don't see a deprecation notice on the general API: https://docs.github.com/en/graphql https://docs.github.com/en/graphql
    - janejeon 4y ago
      > Bad users we could just ban To be fair, it sounds like that would just make the DX wonderful no matter which stack you were using?
- azangru 4y ago
  > JSON + faster Only if you have a very competent backend team, who, apart from dataloader, will have to figure out caching. > /less data Graphql responses tend to be pretty deeply nested.
  - halfmatthalfcat 4y ago
    Apollo's Federation makes caching much easier to reason about as you can now selectively cache sub-query pieces at the service level for that specific responsible subgraph.
- philliphaydon 4y ago
  GraphQL isn’t magically faster. The equivalent endpoint in rest will be faster as you won’t need to translate the query to your backend persistence. GraphQLs benefits are not execution speed.
lucideer 4y ago
> faster, less data over the wire, etc. I've always wondered about this. Firstly, I'm fairly sure clientside JSON parsing is significantly faster than protobuf decoding but even data over the wire: JSON can be pretty compressible so surely the gains here are going to be marginal. Surely never enough benefits to UX to warrant the DX trade off, right?
- beastman82 4y ago
  Json parsing is orders of magnitude slower than protobuf decoding.
  - lucideer 4y ago
    I did some brief googling after reading your comment and I did find one article showing clientside protobuf being faster than JSON[0]. However they didn't isolate parsing - the only thing they measure is total request time to a Java spring application, so the JSON slowdown will include the Java JSON serialisation overhead as well as the request size/network overhead. My instinct is that these two will heavily favour protobuf making the JSON parse still likely to be faster. It also shows a difference of 388ms (protobuf) vs 396ms (JSON) which is pretty negligible. Certainly not orders of magnitude. Do you have other sources? [0] https://auth0.com/blog/beating-json-performance-with-protobuf/ https://auth0.com/blog/beating-json-performance-with-protobu...
    - dwmbt 4y ago
      My own search results: [0] https://github.com/boguslaw-wojcik/encoding-benchmarks https://github.com/boguslaw-wojcik/encoding-benchmarks [1] https://github.com/alecthomas/go_serialization_benchmarks https://github.com/alecthomas/go_serialization_benchmarks [2] https://techsparx.com/nodejs/datastore/protocol-buffers.html https://techsparx.com/nodejs/datastore/protocol-buffers.html
      - lucideer 4y ago
        First two links are Go, so not relevant to client-side. Third link is also server-side, but since it's NodeJS it's at least close enough / more relevant to client-side perf. Here's the benchmark from the third link: benchmark time (avg) (min … max) --------------------------------------------------- encode-JSON 342.37 µs/iter (311.93 µs … 1.19 ms) decode-JSON 435.9 µs/iter (384.44 µs … 1.41 ms) encode-PB 946.43 µs/iter (777.38 µs … 3.13 ms) decode-PB 770.79 µs/iter (688.99 µs … 1.78 ms) encode-PBJS 696.75 µs/iter (618.43 µs … 2.43 ms) decode-PBJS 455.36 µs/iter (413.66 µs … 1.09 ms) showing JSON to be significantly faster
mike_hock 4y ago
There's also msgpack. Best of both worlds.
izacus 4y ago
protobufs have a great property of having a schema (and then generating code). Which means that it's pretty easy to setup a system where accidental change of API fails CI tests for mobile apps and web. This is doable with JSON, but I've never seen a JSON based setup actually work well at catching these kind of regressions.
- janejeon 4y ago
  OpenAPI?
nlnn 4y ago
I don't develop in JS so can't comment on DX there, but I've found the DX to be pretty good when using protobuf in other languages. That's mostly been down to having IDE autocompletion for data structures and fields once the protobuf code's been generated. For many JSON APIs I've worked with there's only been human readable documentation, making them more error prone to work with (e.g. having to either craft JSON manually for requests, or writing a client library if one doesn't already exist).

ZiiS 4y ago

Assuming your developer time is contained improved DX often also leads to better UX (more features). So even if you are optimizing for UX you may well be better with JSON.

onion2k 4y ago
also leads to better UX (more features) More features is not a measure of better UX. In many cases (most cases!?) it's the opposite.
- ZiiS 4y ago
  Sorry; I meant more polished features as much as more by count.

halfmatthalfcat 4y ago

So does that make GraphQL the best then? JSON + faster/less data over the wire.

counttheforks 4y ago
Not when you count the DX of the backend developers. Good luck making a performant GraphQL backend that doesn't suffer the N+1 problem, and have fun whitelisting the GraphQL queries produced by your frontend, because attackers will be supplying their own queries with no regards to performance.
- halfmatthalfcat 4y ago
  GraphQL has a DataLoader (to avoid N+1) and query complexity utilities to avoid those issues.
  - counttheforks 4y ago
    I know. Good luck implementing it performantly while also considering filtering, pagination, etc. It's doable of course, just not nearly as easy as people like to make it sound.
- thejosh 4y ago
  Best experience I had with GraphQL was a B2B app where we had a fair amount of users, as well as the "backoffice" app also powered by GraphQL. Bad users we could just ban (the user base were great folks but could barely operate a computer, so it was fine). Backend was with Absinthe+Elixir, so it was great (if I had to do it again today I would instead use Liveview, this was in 2017 where I had to retrofit a React app into something useable). Public user facing is a different story, the last major one I saw was Tableau, though they are also business facing where they can just ban bad users. Github also has deprecated their GraphQL endpoints[0]. [0] https://github.blog/changelog/2022-08-18-deprecation-notice-graphql-for-packages/ https://github.blog/changelog/2022-08-18-deprecation-notice-...
  - foobazgt 4y ago
    Re: GitHub, that deprecation notice appears to be for GitHub Packages specifically. I don't see a deprecation notice on the general API: https://docs.github.com/en/graphql https://docs.github.com/en/graphql
  - janejeon 4y ago
    > Bad users we could just ban To be fair, it sounds like that would just make the DX wonderful no matter which stack you were using?
azangru 4y ago
> JSON + faster Only if you have a very competent backend team, who, apart from dataloader, will have to figure out caching. > /less data Graphql responses tend to be pretty deeply nested.
- halfmatthalfcat 4y ago
  Apollo's Federation makes caching much easier to reason about as you can now selectively cache sub-query pieces at the service level for that specific responsible subgraph.
philliphaydon 4y ago
GraphQL isn’t magically faster. The equivalent endpoint in rest will be faster as you won’t need to translate the query to your backend persistence. GraphQLs benefits are not execution speed.

lucideer 4y ago

> faster, less data over the wire, etc. I've always wondered about this. Firstly, I'm fairly sure clientside JSON parsing is significantly faster than protobuf decoding but even data over the wire: JSON can be pretty compressible so surely the gains here are going to be marginal. Surely never enough benefits to UX to warrant the DX trade off, right?

beastman82 4y ago
Json parsing is orders of magnitude slower than protobuf decoding.
- lucideer 4y ago
  I did some brief googling after reading your comment and I did find one article showing clientside protobuf being faster than JSON[0]. However they didn't isolate parsing - the only thing they measure is total request time to a Java spring application, so the JSON slowdown will include the Java JSON serialisation overhead as well as the request size/network overhead. My instinct is that these two will heavily favour protobuf making the JSON parse still likely to be faster. It also shows a difference of 388ms (protobuf) vs 396ms (JSON) which is pretty negligible. Certainly not orders of magnitude. Do you have other sources? [0] https://auth0.com/blog/beating-json-performance-with-protobuf/ https://auth0.com/blog/beating-json-performance-with-protobu...
  - dwmbt 4y ago
    My own search results: [0] https://github.com/boguslaw-wojcik/encoding-benchmarks https://github.com/boguslaw-wojcik/encoding-benchmarks [1] https://github.com/alecthomas/go_serialization_benchmarks https://github.com/alecthomas/go_serialization_benchmarks [2] https://techsparx.com/nodejs/datastore/protocol-buffers.html https://techsparx.com/nodejs/datastore/protocol-buffers.html
    - lucideer 4y ago
      First two links are Go, so not relevant to client-side. Third link is also server-side, but since it's NodeJS it's at least close enough / more relevant to client-side perf. Here's the benchmark from the third link: benchmark time (avg) (min … max) --------------------------------------------------- encode-JSON 342.37 µs/iter (311.93 µs … 1.19 ms) decode-JSON 435.9 µs/iter (384.44 µs … 1.41 ms) encode-PB 946.43 µs/iter (777.38 µs … 3.13 ms) decode-PB 770.79 µs/iter (688.99 µs … 1.78 ms) encode-PBJS 696.75 µs/iter (618.43 µs … 2.43 ms) decode-PBJS 455.36 µs/iter (413.66 µs … 1.09 ms) showing JSON to be significantly faster

mike_hock 4y ago

There's also msgpack. Best of both worlds.

izacus 4y ago

protobufs have a great property of having a schema (and then generating code). Which means that it's pretty easy to setup a system where accidental change of API fails CI tests for mobile apps and web. This is doable with JSON, but I've never seen a JSON based setup actually work well at catching these kind of regressions.

janejeon 4y ago
OpenAPI?

nlnn 4y ago

I don't develop in JS so can't comment on DX there, but I've found the DX to be pretty good when using protobuf in other languages. That's mostly been down to having IDE autocompletion for data structures and fields once the protobuf code's been generated. For many JSON APIs I've worked with there's only been human readable documentation, making them more error prone to work with (e.g. having to either craft JSON manually for requests, or writing a client library if one doesn't already exist).