While this document starts strong and has some good points, it strongly conflates “scrum” with “agile” and goes downhill pretty quickly.
> wrong answer: what’s a sprint cycle?
You don’t have to have sprints to be agile. What’s important are the four values.
The manifesto says, “Individuals and interactions over process and tools” but this document then goes on to talk a lot about specific processes and tools.
A trap every freaking "Agile" company falls into. Don't get me started on fixed scope + fixed timeline that they all still do anyway, only now broken into "sprints".
> The needs of security are opposed to the needs of a convenient user experience. Improving one typically hurts the other.
I must be Dr Contrary tonight but this strikes me as bullshit.
SSH is more convenient that telnet. Passkeys are more convenient than passwords. TouchID and FaceID are more convenient than passwords.
In general, security is an afterthought that is inconvenient to developers to add back. But in the digital world I haven’t seen many examples of security being less convenient than the alternative.
(I am writing this from an airport and definitely do not assert that this applies to the built environment.)
Safety is not a “luxury enabled by profit”. It’s one of many necessary dimensions for efficiently creating value over time.
If you are a sole trader and you fall off a ladder and hurt yourself because you took some stupid shortcut, the cost is extremely high.
If you work for someone and they make you do something stupid that hurts you, the cost to them has traditionally been relatively low, so they are motivated to push you because that’s better for them. Fortunately, in most modern countries this is no longer the case.
Safety only becomes a “luxury” when capital becomes concentrated into the hands of people for whom other people are disposable.
I bought a chainsaw recently for $10. I then bought about $100 of kevlar armor to wear while I use the saw.
No money => no safety
Take a look at history as far back as it will go. Safety expenses only happen when the money is there.
Next time you see someone using a chainsaw, take a look at their protective equipment. If they work for a company, they're likely wearing:
1. ear protection
2. face shield
3. helmet
4. kevlar gloves
5. kevlar chaps
6. kevlar boots
If they're some rando with a saw, odds are pretty good they have none of that on. They won't spend their own money on their own safety. It's only deemed essential if someone else is paying for it.
This is just rubbish. Safety arises from multiple dimensions - Kevlar-threaded armour is a single, last line of defence that helps only when everything else has failed.
Actual safety comes from training, practice and operations - such as understanding how the tool works, what unexpected dangers exist, what techniques to avoid, the state of the immediate environment, prioritising safety (eg by not creating time pressure) and the design of the tool itself (eg chain guards and anti whip mechanisms)
By the time your Kevlar armour comes into play you are well outside the safety zone and deep into the shit your pants zone.
You're right that the kevlar is the last line of defense. Nevertheless, one would be a fool not to wear it, as machinery fails and people make mistakes. There are photos on the intertoobs of shredded kevlar and no injury to the "thank god I put on my armor!" sawyer.
This is nonsense. GraphQL queries are simple HTTP requests, with no more complexity than REST. You POST a query string and some JSON and it’s done. If your client makes it harder than that, don’t use it.
Here’s my workflow for creating an API with Postgraphile:
create view graphql.object as select some,columns from table;
(That’s it)
It’s trivial to query it with curl, I’d give an example but I’m afk rn.
I’ve been using GraphQL for about the same amount of time as in the article and it solved a bunch of problems for me.
It’s so easy to use, and saves so much time - once you spend the time to understand it.
I've veen reading about graphql forever and never understood it. Your comment finally made it click for me. Do you happen to have any more documentation around your method of working?
Unfortunately I’m on a bus to the airport for a couple of days so I’m a bit constrained.
If you know Postgres, I would recommend taking a look at Postgraphile. It’s awesome, and comes with an explorer web UI that really helps (GraphIQL with extras). Everything happens in real time. so if you update a view, the UI updates.
There are lots of GraphQL clients but many of them do all sorts of crap you don’t need. I just use graphql-request which is super simple. But of course you can just use fetch() too.
There are also lots of “standards” for GraphQL that make it seem more complex than it is. Ignore that stuff and just start playing with a good server like Postgraphile.
> This is nonsense. GraphQL queries are simple HTTP requests, with no more complexity than REST. You POST a query string and some JSON
The complexity of GraphQL in fact begins there, and also sort of explains a lot of why GraphQL is all but simple:
Why am I using a query language instead of just passing an AST via JSON, a data format every general purpose language supports very well these days?
The answer to the above question, and most of GraphQLs other complexities: Some arbitrary design decision.
Another example:
GraphQL could've easily been expressed as a REST API, even an Open API. From what I have seen, with the help of VC backing and FAANG endorsement, GraphQL mostly rose to replace JSON:API, which accomplishes pretty much all of the same goals in just JSON (and is RESTful).
One big issue of GraphQL is also that API clients tend to suck. That's not a problem for OpenAPIs.
And again, why is this the case? Some arbitrary design decision.
I feel like in general, someone creating a new DSL where it's not needed (and is obviously designed to look cool rather than actually be expressive), is a good sign they're just writing the software to stroke their ego rather than reach a meaningful end.
That's why in all the promo material for GraphQL you only see the query language, and not all of the actual setup required to send a request or even what an actual GraphQL HTTP request looks like. GraphQL, the framework, is not actually as simple and elegant as GraphQL the query language attempts to portray it as.
It's almost like someone came up with a query language for fun then came up with all the details of how a web server would utilize it afterwards.
Even today, GraphQL markets itself only as a query language (A query language for your API). When, as you have already mentioned, it is more than that.
That's why most developers know vaguely what GraphQL is ("Oh, that one language") but not how it actually works in practice. And when they actually encounter it, it feels almost like a betrayal, because it's nowhere near as simple, sleek or elegant as all the marketing they saw suggested.
At least, this was my experience when having to deal with a
third party GraphQL API (funny enough, they migrated from REST, see ShipHero).
Why do you mention GraphQL and JSON:API in the same sentence? The latter is at least 10x more difficult to understand with all its edge cases around entity relations and filtering.
These are just assertions with little to back them up. As TFA says, you can make all the same claims for REST. And GraphQL works the same as REST. But instead of a complex mishmash if positional and named parameters, it has a super simple query structure.
When you create a stack of REST APIs, you’re creating a DSL. But it’s a DSL with arbitrary and frequently undocumented relationships between objects, no type safety, and masses of hidden complexity.
GraphQL is simple. If you don’t think it’s simple, you don’t understand it.
> One big issue of GraphQL is also that API clients tend to suck. That's not a problem for OpenAPIs.
The clients are unnecessary. You can get ridiculously complex clients for REST, too. But you can also use GraphQL just using fetch().
The only material difference between the two from a client perspective is:
* REST gives you everything, even if you don’t want it
* GraphQL requires you to request what you want using a minimal query language.
GraphQL also lets you perform multiple queries in parallel, on the server, which REST can’t easily do.
REST is a PITA for any data model that’s more complex than CRUD.
> REST is a PITA for any data model that’s more complex than CRUD.
Also I'd just like to point out that for everything but queries themselves, GraphQL uses JSON. JSON is used in the C and U of GraphQL's CRUD... Explain to me why this couldn't have just been JSON and therefore a REST API again..?
Almost the only thing stopping it from being one is its "query language". I guess technically usage of one endpoint would make OpenAPI doc'ing difficult but I think possible depending on what JSON Schema/OpenAPI version you're using.
But it would also be trivial to just have separate endpoints for each schema.
You could even use all POST requests and only use the request body if you want.
> Also I'd just like to point out that for everything but queries themselves, GraphQL uses JSON.
Most clients send queries as json too, actually, not gql source. The funny thing is that GraphQL doesn't even specify JSON, or any wire format at all. It just has to be able to encode the gql type system, and JSON "just happens" to work (I'm pretty sure they did have json in mind when they wrote it, but it still isn't baked into the spec). The spec is also silent on transport, I think the whole tunneling-everything-through-POST thing came from the reference implementation.
You really seem attached to OpenAPI. I can't speak for everyone, but I for one would would much rather write SDL than json schema in yaml.
That's why I mentioned OpenAPIs, which you certainly can't make the same claims about. I have never had a problem with an OpenAPI, it's almost like a litmus test of web developer competence how simple it is.
> But instead of a complex mishmash if positional and named parameters, it has a super simple query structure.
Have you ever used an OpenAPI or an OpenAPI client? I seriously implore you to look at ShipHero's GraphQL documentation and look at any OpenAPI docs and pretend like GraphQL is simpler.
But if you've ever used an OpenAPI client, you know this is just a problem in theory, not in practice. I have never accidentally passed a parameter to the body, path, query or headers when it should've been elsewhere.
The problem is non-existent, especially since most people don't write OpenAPI requests from scratch.. you can just throw the document anywhere and you will have some easier way to make requests.
And even if that's really a problem, almost every OpenAPI doc UI I've seen has an option to show you the cURL and substitutes in parameters from the UI. You could just fill out the UI and copy the cURL request.
> When you create a stack of REST APIs, you’re creating a DSL. But it’s a DSL with arbitrary and frequently undocumented relationships between objects, no type safety, and masses of hidden complexity.
I'm beginning to think this entire comment is a strawman: my argument is that a graph-based OpenAPI would have been better than GraphQL. Any REST API can be an OpenAPI. You are comparing apples to oranges.
I am comparing a RESTful Graph based data access API (like JSON:API) to GraphQL.
You are taking what sounds like the kind of REST API you'd find in a w3schools tutorial and comparing it to GraphQL.
> GraphQL is simple. If you don’t think it’s simple, you don’t understand it.
That many developers find GraphQL difficult to understand is literally a testament to its complexity. This statement contradicts itself unless you believe I'm the only developer on the internet with this opinion, which I have a hard time believing given this entire comment is filled with strawman arguments you clearly use against others who dislike GraphQL.
> The clients are unnecessary. You can get ridiculously complex clients for REST, too. But you can also use GraphQL just using fetch().
Types are unnecessary. You can get ridiculously complex with strictly typed languages, too. But you can also just type everything dynamically and go crazy if the type system in my wacky language annoys you.
> REST gives you everything, even if you don’t want it
That's completely up to the REST API. I've written several that disagree with you. I've literally written RESTful Graph based data access APIs that don't do this. Multiple. At tech startups.
> GraphQL requires you to request what you want using a minimal query language.
So it requires complexity to enforce low bandwidth, got it. There is definitely no other way to lower bandwidth than enforcing complexity.
Usually I just use ABAC. You get the fields you can see. You can select a minimal list if you want. You don't have to type out 32 field names if you need them all.
I sometimes wish GraphQL just took a chapter from SQLs book. What you described here is not a feature.
> GraphQL also lets you perform multiple queries in parallel, on the server, which REST can’t easily do.
Ironically, that is up to the GraphQL implementation. ShipHero's does not support this, and requires N+1 queries in many common cases. I suspect that's not uncommon with GraphQL APIs, but I have no evidence for this.
But my suspicion is based on the fact that rigging up a GraphQL API implementation is a daunting enough task on its own, and multiple queries feels like it would be an after-thought to someone doing a quick-and-dirty setup. Which is how most people set up bleeding-edge infrastructure (which is what GraphQL was when it was largely popular), because there's not much knowledge, documentation or expertise readily available.
> REST is a PITA for any data model that’s more complex than CRUD.
Again, you're strawmanning. You're arguing against REST, not a RESTful Graph based data access API, like JSON:API.
REST is not an API. GraphQL is. It is basically an API proxy with a query language disguised as a graph based data access API.
”I've literally written RESTful Graph based data access APIs that don't do this. Multiple. At tech startups.”
Okay mr startup man, fact is you don’t know what you’re talking about and your head is so far up your startup ass you no longer know what’s good engineering.
Why are you writing your own restful graph based data access APIs?
I don’t disagree with you in principle, but this history is not quite right. IIRC the IE6 team was shut down. Basically only Mozilla and Apple were building browsers at scale until Chrome came along.
Yes, you are definitely missing a decade here. The internet explorer/edge team was shut down long after Google grabbed most of the market share.
Chrome was launched 2008; Safari had its first release in 2003. And I was using the early Phoenix builds (later the name change to Firefox happened) in 2001. The version of internet explorer around the time Chrome launched was v7. IE 6 was already old news by then. And IE 8 launched soon after the Chrome launch. 9, 10, and 11 followed. And then the switch to Edge happened; which was a complete rewrite of their browser engine. Only in 2020, MS announced switching to Chromium. So, that's about 12 years of MS trying to hold on before they finally gave up.
A friend of mine had an art studio at the Nicholas Building, and I got to speak with a jeweller who told me that he still did a lot of bespoke work in wedding rings, especially for tradies who would otherwise wear down store-bought rings because they were solid gold and therefore softer. I don't remember the details, but he specialised in harder alloys that are nevertheless mostly gold, and therefore "good as gold" for a wedding ring.
Why smart people continue to say this is beyond me. There were so many problems with the USSR - central planning, corruption, bureaucracy, secrecy, misaligned incentives - and it's just not true that everyone was equal. Very few rational people would agree that the USSR is something that we should aspire to.
As far as I can tell, "look how well it worked for the USSR" is just a trope that's trotted out by people who don't want to accept that alternatives to the status quo might be possible.
Are you asking why an arbitrary group of American companies, popularized in an American TV show about the American stock market, has only American companies? I don't know. That's a good question. Why didn't they include others like Tencent, Alibaba, TSMC, Samsung, or BYD?
It's like asking why are the Fortune 500 companies all American companies. In contrast, Fortune Global 500, using the same criteria but in a wider pool, has companies from other counties.
The US has the worst health outcomes in the OECD - in particular for life expectancy, infant mortality, healthcare access, and chronic disease. So if you care about health, “another example” is literally any other OECD country.
And every one of those FAANGs would not exist without ASML, a European company.
You obviously don’t know what you’re talking about. I’m checking out of this thread.
I don't understand how you can see videos like https://youtu.be/925wmb-4Yr4 of skid row and conclude, y'know what? American Capitalism is the best thing ever and there's no possible way theres anything wrong with it so anybody trying to say that, hey, it's not perfect, is automatically a Stalinism Communist because that's the only way there could remotely be any sort of problems with American Capitalism.
There's a housing problem everywhere and your vaunted free market hasn't been able to solve the problem, but that's okay because we can just blame the victims for wanting life, liberty, and the pursuit of their happiness in a place of their choosing, in a manner of their choosing. As if anyone in their right mind would choose to live like they do in the video linked above.
Isn’t the only real difference that the yield function is being passed into the iterator instead of being a reserved word? I don’t think it’s clunky, although it took a few minutes for me to get it.
No, before C# got generators, some of the machinery had to be manually implemented, with yeld, the compiler generates the necessary implementation for IEnumerable.
> wrong answer: what’s a sprint cycle?
You don’t have to have sprints to be agile. What’s important are the four values.
The manifesto says, “Individuals and interactions over process and tools” but this document then goes on to talk a lot about specific processes and tools.
It’s a trap!
reply