The good news is GraphQL is very quick and easy to pick up and it gives that inbuilt functionality to fetch exactly the amount of data that we need. On top of it, it also has enough flexibility to integrate with your business logic.
So it can be a straightforward replacement for a traditional REST API that you would have to manually build.
For the disadvantages, I cannot think of any. It is a bit slower than hand rolling your own REST API, but the difference is not severe enough to make you give up on it.
GraphQL APIs can easily DOS your backend if you don't configure extra protections (which are neither bulletproof nor enabled by default), they suffer from N+1 inefficiencies by default unless you write a ton of extra code, and they require extra careful programming to apply security rules on every field which can get very complex very fast.
On the plus side, it does have offer communication advantages if you have entirely independent BE and FE teams, and it can help minimize network traffic for network-constrained scenarios such as mobile apps.
Personally, I have regretted using GraphQL every time.
My biggest gripe is losing the entire layer of semantics that HTTP gives you. POST is the only verb and different error states are conveyed via error objects in the returned JSON.
This is probably true, and it can only be uncovered by rigorous testing. There is a bunch of layers of abstraction that won't be very obvious if you are using GraphQL as opposed to rolling your own REST API.
Where is this getting the docs from? It's a lot of work for FLP/Courtlistener to get stuff, and even they don't have 100% of records (not sure if this site is claiming to have 100%, it's unclear)
All court records are not copyrightable so once one person gets a document from PACER they are free to upload it to things like RECAP. Allegedly PACER is only allowed to charge enough to cover the infra costs of operating it, and has a pretty generous free tier nowadays so it’s mostly law firms that end up having to pay.
> almost no one uses a debugger, yet everyone, including me, goes deep into the mines, debugging with their printf pickaxe and console.log lantern, everyday, getting frustrated over it and losing everyone’s precious time, which would be better spent:
I use an actual debugger all the time, and so do many other engineers I have worked with (though a surprising number do constrain themselves to print debugging only)
I think it really depends a lot on the bubble of programming you spend time in
In mine, which is more fullstack web, I rarely meet someone who does. I list a bunch of reasons in the article.
Have been looking for something like this and planning on making one, but one of the main things I need is ability to query a local container with no auth. Too many options for Dynamo clients need AWS creds, etc.
Unfortunate. I was a subscriber, though not an avid reader.
But never a paid subscriber. In retrospect, I could and maybe should have been. I was a paid subscriber at one point for both The Economist and The New Yorker. But for those, I got physical copies. Paying for something purely digital is the only aspect of my not paying for Quartz that I remember.
One of the fundamental tenets of the US legal system (and, at one time, its culture) is that rights like due process are more important than helping facilitate the government's will at scale.
The one place this has been debased and eroded has been NatSec, and that's part of why the government wants to use that justification for its immigration enforcement.
Damn really lol
What does it do then, just block "breaking" deletes?
reply