How long ago was this? AFAIK the `rm` command in almost every linux distro these days will NOT let you delete `/` unless you add `--no-preserve-root` parameter.
The whole problem seems to be bizarrely defined when it comes to data structures.
Basically the input is `data+config` merged into one object and the return value is `data+config+tranversal_properties` merged into one object with lots of solutions mutating the original input data.
> GitHub was flakey, some things didn’t have error responses
That just seems like API problem rather than GraphQL problem. The equivalent would be REST API that just returns 500 without any additional info. You can be lazy in both stacks, I don't think any one of them particularly prevents you from being lazy about handling errors / typing useful error messages.
> Mutations would screw up encoding “ character and it was just painful.
Interesting, haven't heard about this. Also cant come up with how this is related to GraphQL, as you are just transferring string, just like you would do with REST. It seems more of an problem with some proxy/grapql framework layer that didn't handle the character correctly?
> REST api was much more deterministic and easier to work with. POST/PATCH/PUT/DELETE map well.
I don't see this as a big win, in GraphQL you just have `somethindUpdate` `somethingCreate` `somethingDelete` mutations, it is true that it is up to you to keep the naming consistent but nothing really that would be big trouble, or win for the REST.
> I wish graphql didn’t invent its own quirky language and stuck to good ol json.
If they did that you would end up with some quirky JSON query and schema syntax that would look like json schema or the mongo query schema. It is true that if you do new syntax you lose some json tooling that could be used (eg syntax highlight) but I don't see that much stuff transferable to the problems that GraphQL is solving.. so you would still end up with bunch of custom tooling on top, and when you need that you might as well go the way they did, with new syntax, that is not as quirky as whatever mongo/json schema like thing they would come up with.
> There is a lot of over complication.
This is definitely true and one of the most overlooked things by GraphQL evangelists, the "additional complexity layers" are non negligible.
Actually, just a few days ago, I got fed up with Apple and tried to switch to Microsoft, and make it my main development machine, and so far I have to say I am impressed.
Twitter thread describing the experience: https://twitter.com/PetrHurtak/status/1314854634394185728
I think this is just problem in general with touch devices.
Also the way modern apps are designed, where almost everything is button, does not help.
See mobile twitter, for example, close to 100% of the screen is link of button that does something.
Definitely, compared to Gatsby, Next is much simpler. At least every time I tried Gatsby, I just had to give up after a few hours because of the complexity and massive amount of boiler plate that you had to stitch up yourself from examples.
Isn't that what NOTE is for? The code is fine for now, but here are some constrains/limitations/implementation details that you should know when you want to touch that par of the code.
- Xiaomi Redmi Note 4 - pretty good finger print scanner on the back
- Samsung Galaxy S8 - absolutely terrible fingerprint scanner that was so bad I switched to pin after a while
- Samsung Galaxy S10 - new fingerprint scanner under display, works most of the time but still unreliable, also it is not the quickest.
You would have thought that leading brand (Samsung) would have decent fingerprint scanners on their flagships, but it is just not the case.
The thing with bad fingerprint scanners is that you cant rely on them, so I rather choose reliable slower 3s unlock with pin than unreliable maybe faster 1-10s unlock with fingerprint.