Viewing profile — megadal

> I don't see how it is related is relevant to this discussion. Because it was brought up as a subtopic in my original comment and someone quote responded directly to it.

It's related to MS contribution to .NET which is the subtopic of this particular thread.

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 (th…

I mean they kind of are. You can find a library in almost every language that transpiles source code ASTs. They're just not core features. In Haxe, it's extremely common :) but Hax…

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

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…

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 al…

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, o…

What BIM formats does it support?

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 i…

The title: "bug exposed up to 255 bytes of server heap and existed since 2011" The post: "Silently sends up to 255 bytes of the client’s heap to the server."

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 p…

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. Whic…

> The whole point of my comment is that with REST Hence your comparison is invalid > you don't have any guarantees about the API and thus it's a much harder target to support. You …

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…

> 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 th…

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 q…

> Why do you mention GraphQL and JSON:API in the same sentence? I usually tend to use words like these in sentences wherein there are phrases or clauses in which those words are th…

> Why are you writing your own restful graph based data access APIs? https://en.m.wikipedia.org/wiki/Nihilism

> 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 niche…

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,…

> you can make all the same claims for REST 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 …

> 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 ther…