Yes, but I think the point is practically every high level language can already do this pretty trivially.
If it's scripted you can typically just get a string representation of the function.
If it's Java, JAR inspection/dynamics have been a thing for a long time. And in other languages, they usually directly support metaprogramming (like Rust) and plugging code into the compilation logic.
If it were trivial you'd see LINQ-like providers implemented in "practically every high level language".
Source code of the function means you have to implement the parser/lexer to convert it into a usable AST which is bad for both runtime performance and library size.
Very much doubt this is available in Java, which Java ORM lets you use native Java language expression syntax to query a database?
You're replying to a thread about what it takes to implement a LINQ provider, which was dismissed as every high level language implements it with iterables, then proceed to give non-equivalent examples.
IQueryable<> manipulation has other tools available to it than brute-force iteration, like streams do. Streams may be the closest thing java has, but it's still a fundamentally different thing.
Wait what? Am I gonna include a source code parser and AST analyser to my JavaScript library for example, to examine the provided expression source and do this? This reads like the infamous Dropbox comment from when it first got released.
You could also bundle your JS. Or pretend like any number of other solutions like caching parsed ASTs exist instead of being as obtuse as possible, or something idk
It's just an API for JIT, basically metaprogramming. It's cool but you can definitely do a similar thing in pretty much every high level language.
With scripting languages, it's all JIT :)
The C# teams progress on this has been slow. Keep in mind the CIL bytecode has had such capabilities for at least 20 years now and only in the past like decade are we seeing more features and optimizations around LINQ and System.Reflection.Emit.
Dynamics were extremely slow in C# and if you look at the CIL generated you see why. It's possible for example to use something like a Haxe anonymous types[1] to optimize Dynamics so that CallSite caching is way more performant.
I am pretty sure in C# the only way to accept an anonymous type is as a dynamic value, so even though the type of the structure is well-defined at compile-time, it will still rely heavily on runtime reflection/DLR with no additional caching beyond what DLR does for any other dynamic type.
Anyways, this leads to niche libraries being built for handling dynamic data like JSON performantly.
Which leads to annoying things like .NET libraries/apps being incompatible (without some adapter) if they use for example, different JSON libraries under the hood. (See [2]).
Problems like these (the lack of actually good JIT/dynamic code support) in my opinion significantly slow down the .NET ecosystems development, that's why it always feels like .NET is just catching up with features other popular languages have.
To be fair though, much of C#'s lag is owed to Microsoft's contribution to .NET being mostly technical debt. Almost everything good that came out of .NET came from open source/non MS teams (like Mono).
> It's cool but you can definitely do a similar thing in pretty much every high level language.
No. When it was release (circa 2007), very few mainstream languages embraced "Code as Data" the way C# did. In Java, there was no way to pass an expression (as an AST) to an SQL library. Which is why LINQ is so much more ergonomic than Hibernate. In C#, you could use language features you're already familiar with (such as "order.id > 100 && order.id < 200") in your queries, whereas Hibernate made you learn the framework's specific patterns (add Criteria etc etc, I don't recall now). Java just wasn't expressive enough for this.
In fact, you couldn't do this even today in a language like say Python or JS. I mean, not without running it through something like babel to get an AST, and having arbitrary rules on what's code and what's data. C# had this in the spec; based on whether it was IQueryable.
> Almost everything good that came out of .NET came from open source/non MS teams (like Mono).
My team adopted Mono very early - like in 2005. Your statement is not true at all. C# and the Framework was a very good spec irrespective of what Open Source / Mono did, and while Mono existing might have accelerated .Net's transition into Open Source, it would have happened anyway due to the definitive swing towards Open Source in the 2000s. Linq-to-SQL, Asp.Net MVC, EF etc didn't come out of Mono.
Have you ever read the source code for Microsoft's ilasm compared to Mono ilasm?
Anyway, EF is cool, but probably every .NET dev has an EF/LINQ performance related horror story (the generated queries are ridiculous).
A self compiling language is more impressive to me than ASP.NET MVC.
And C# is just lacking for what is actually capable in CIL bytecode. Or _was_ when I last used.
There have definitely been improvements, but in my opinion, they have just been kind of slow.
When I think of Microsoft's impact on .NET and it's culture, I think of stuff like SOAP, the SmtpClient, breaking changes in APIs every year and the technical debt left by it, the dogmatic fanboys, etc...
I don't see how it is related is relevant to this discussion. Is there a specific point you would like to make?
> probably every .NET dev has an EF/LINQ performance related horror story (the generated queries are ridiculous)
> There have definitely been improvements, but in my opinion, they have just been kind of slow.
> much of C#'s lag is owed to Microsoft's contribution to .NET being mostly technical debt. Almost everything good that came out of .NET came from open source/non MS teams (like Mono).
Do you actively use .NET (any modern target in the last, say, 3-4 years or so)?
this comment further confirms my belief that GraphQL is a cult.
> this completes the move from the server side to the client side
OK, how does that benefit end users, developers, or administrators? I have never had a person approach me to make a website with a client side database.
> REST (so called, see[1]) was the first step, GraphQL the second step and now this completes the move of pushing the expressiveness found on the server side over to the client side.
Again, I don't see the point..? Who does this benefit..? Front-end only devs who want think doing everything on the front end makes a website more modern/app-like..?
Web architectures aren't separated in front end/back end because of technological limitations. We could've been running databases in the browser for decades now. We don't because of Separation of Concerns...
The front end is for presentation tier logic.. the backend is for business logic.
Just because you can do something doesn't mean you _should_, and when something has been possible for a long time but hasn't been done very often, you should ask yourself why that is.
Of the 3 big US based clouds, Azure was the worst I dealt with. AWS comes close second to worst. GCP is the best UX but pricing is probably comparably crazy.
Azures biggest issue is it inherits most of the same technical debt most Microsoft products suffer from. It's slow, glitchy, and at times unforgiving. Also I find I often have to have the network tab open as errors aren't reported to the UI. They just happen and stuff hangs.
I really wonder how despite all of this, they still get business... It's been a demonstrably terrible Cloud from the start. Even Equifax avoided Azure during their lift and shift, which is surprising given a lot of their stack is super legacy Microsoft tech... I guess they learned their lesson.
> I really wonder how despite all of this, they still get business...
I suspect that in large part Azure gets business from companies that already have microsoft environments and utilize O365 and AzureAD or whatever they’re currently called.
I could be wrong but I think a good way to have an edge is pricing. Email is generally a low bandwidth service with lots of cold storage, yet for most personal email services the price doesn't seem to reflect this.
Like for example Google One is $2/100GB and $10 for 2TB yet you can definitely get storage much cheaper than this, and bandwidth is close to, if not free on bare metal clouds.
I've been considering this myself. That or some IRCv3 offering.
If you go the commercial route you'll almost certainly end up building an ERP/CRM, as it's what a lot of companies seem want: a personalized ERP/CRM (not sure why, though it does kind of feels like just outsourcing an IT dept whenever this has come up in the past)
> With the right team, with the right use-case it's excellent. So please don't take it as GraphQL=bad.
If a framework requires you to be just as, if not more competent in its niches to achieve the same end you could've achieved without it, I think that makes it bad.
That's like if an HTTP framework could only be effective at the protocol level with a team competent in HTTP. The whole point of a framework is abstraction.
I have never once seen how GraphQL (the language) provides any sort of abstraction that the general framework itself doesn't, and the little abstraction GraphQL the framework does provide you can mostly sum up by just generating an OpenAPI over a set of schemas, with a whole host of benefits and few trade offs (on the implementation side, which is where your 10x devs usually live anyways).
It's weird. It's like the main benefit of GraphQL is that there are groups of developers who understand it, but the biggest drawback is that it is needlessly complex, which again, seems to indicate GraphQL is bad. It's an abstraction that creates needless complexity (that you necessarily can't reverse because it's apart of the spec..)
If you don't need to write resolvers by hand, from experience I can tell you writing an OpenAPI over an ORM/ODM is trivial and will accomplish the same end. It's schema-first and quick and simple (it's as simple as defining the schema in your ORM library, your generator will handle the rest)
If you do need them, as you said it's going to be complex either way.
Comparing GraphQL to REST and not a RESTful Graph-based data access API like JSON:API is just being disingenuous.
For GraphQL, you know it will be a nightmare. For REST, you don't, because you don't know what the actual API is. It could be a stopwatch API, obviously a stopwatch REST API is not comparable to GraphQL.
That doesn't matter at all. Handling authorization at the federation gateway point is a nightmare in any case. At least with GraphQL the scope is limited.
GraphQL literally is a "federation gateway point."
It's literally meant to be a gateway to a bunch of different external systems working in federation.
It's the exact same scope if you used a RESTful graph based data access API that connected to external systems..
Outside all the GraphQL jargon and gobbledygook you'll see that GraphQL is not some groundbreaking, unique or foundational product... The concept of generating graph based data access APIs from schemas is probably older than the concept of phones that can send emails. The only "innovation" is the "query language"...
> That doesn't matter at all.
I honestly don't know why I'm taking this seriously. Yes, it matters, your entire point was a comparison.. that your comparison is foundationally invalid matters when assessing the validity of your entire argument..
The whole point of my comment is that with REST you don't have any guarantees about the API and thus it's a much harder target to support. You're limiting it to json:api which is nice but I have never even seen a company use that. What happens in reality is that I get 20 apis from 20 teams, each of them completely different principle - and am supposed to build an universal auth layer for that. That's much more painful than in the companies that decided to go for GraphQL only.
> you don't have any guarantees about the API and thus it's a much harder target to support.
You won't find a developer worth hiring who thinks OpenAPIs are more difficult to work with than GraphQL.
Every REST API can be an OpenAPI
Practically every popular general purpose language has an OpenAPI client gen implementation.
And supporting a GraphQL API is not easier than supporting a REST API. All I have to do for my stopwatch API is handle one route.
> You're limiting it to json:api which is nice
Certain constraints do come with valid comparisons, comparing like things is a requirement of a valid pros/cons comparison, not a niceity.
It makes no sense to explain the pros of using one thing over an other when no one is thinking about using one thing as a replacement for another.
It's like talking about the pros/cons of using your proprietary web based chat platform vs. using UDP. Not using UDP for the chat or anything. Just comparing the chat with UDP itself, the whole protocol. No one considering your chat is going to step back and go "wait why am I using a web chat when I can just use UDP?"
> I have never even seen a company use that
My point isn't that a company does/doesn't use it. I mentioned JSON:API because it's a valid basis of comparison, no other reason.
> What happens in reality is that I get 20 apis from 20 teams, each of them completely different principle - and am supposed to build an universal auth layer for that. That's much more painful than in the companies that decided to go for GraphQL only.
But you have by your own admission never seen another company use JSON:API.. therefore you don't actually know that it is more painful than it would be for all REST APIs.
For all I know you could, again, be talking about my Stopwatch REST API... hence your comparison is invalid. By the way, auth is easier for my stopwatch API than it is for GraphQL. :)
Lol... Again, the point is that unrestricted is harder than restricted to something g specifically designed with this in mind. You go make your own comparison, I compare things that matter in my work. Your Stopwatch api is probably simple, the api to generate PDFs of financial projections that I have to support is not.
So then your argument isn't that GraphQL is better than REST. It's that you need something specifically designed for graph based data access to handle graph based data access.
Which a REST API can do.
This argument is quite a goalpost shift from your original point: that it is easier to implement authz/access control in GraphQL than for a REST API.
An API to generate PDFs is not comparable to GraphQL, because it's not a Graph based data access API...
You're so disingenuous and unserious it's insane. This is why people hate GraphQL and it's devs: 100% of your talking points are non-sequitur copy paste arguments. It doesn't matter how much context is provided to prove what you're saying is nonsense — you'll just bulldoze right along with said nonsense anyways. It's like I'm talking with a zombie.
For the purpose of accountability I'm pointing out that so far you've:
- made an invalid comparison
- tried to elaborate on that comparison only to make several other logical errors
- goal post shifted to a totally different point than your original point after being called out
you've already pointed out that you have zero experience with JSON:API and that you can't come up with anything good to compare GraphQL with sort of demonstrates that your reasoning behind using it is not based on anything other than marketing as you have never actually used an alternative to GraphQL... Everything you've said I've only ever seen in GraphQL promo material.
So basically you got shilled and turned into a shiller.
> 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?
If it's scripted you can typically just get a string representation of the function.
If it's Java, JAR inspection/dynamics have been a thing for a long time. And in other languages, they usually directly support metaprogramming (like Rust) and plugging code into the compilation logic.