3 ms·
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 whitelistin
by 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 agoGraphQL has a DataLoader (to avoid N+1) and query complexity utilities to avoid those issues.
- counttheforks 4y agoI 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 agoBest 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 agoRe: 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?