Time to rm that decade old "try graphql" to-do note.

@AvikNayak_

16 күн бұрын

Your profile image makes this comment even more funnier.

@ZM-dm3jg

16 күн бұрын

One thing I've learned is that if i procrastinate on using the hot new thing for a couple years it always goes away 😂

@AvikNayak_

16 күн бұрын

@@ZM-dm3jg I am also skipping on using nextjs let's see what happens

@stoogel

16 күн бұрын

It’s great not being an early adopter in the web world.

@overbyte

16 күн бұрын

Smart. It’s bullshit

I am done with GraphQL after 9 years of not using it

hobbyists are done every 2 days untill they will find a job. after that they will follow the way that company requires

Daily reminder to ignore hype trains: Old is boring, boring is good.

@iraqinationalist7778

16 күн бұрын

What about phoenix vs laravel?

@chrishoppner150

16 күн бұрын

@@iraqinationalist7778 which one is more boring?

@CottidaeSEA

16 күн бұрын

@@iraqinationalist7778 Spring.

@iraqinationalist7778

16 күн бұрын

@@chrishoppner150 don't know, php is hot sh;t rn

@Ktulhoved

16 күн бұрын

This is not true. I can't find a better solution for managing micro services than the graphql federation.

/api/v1 is an emotional support api prefix

@devinjohnson5759

3 күн бұрын

Why do we have a prefix like this at my job too 🤣

graphql are for people who front end and back end hate each other but friends with the middle guy

Maybe I don't understand why anyone would use GraphQL in a public-facing interface, but it sounds no different than putting a button on your front door that instantly blows up the house, or a textbox on your website that runs SQL queries on your server.

@catcatcatcatcatcatcatcatcatca

15 күн бұрын

I think it’s more like a powersocket next to your front door, but with no fuse . Given a correctly shaped piece of metal anyone can burn down your house. But if you or your neighbour you don’t mind borrowing a socket ever need more power than a normal house fuse can provide it is very convinient. There is little convinience in buttons that blow up your house.

@mckidney1

14 күн бұрын

I think the confusion comes from the anyone, the problem is simple resource economy: Is it cheaper to make my house redundant or to make as many mailboxes as there letters. Article (imho correctly) adjusts the needle from some to almost nobody.

@thewhitefalcon8539

13 күн бұрын

Usually they filter the allowed queries to be the exact ones they tested.

The best feature of GraphQL, it can have circular references and this requires the developer to be aware of this issue and write something that would disallow it. Who would have thought that creating a service specification that is effectively giving API level functionality that is equivalent to SQL and that couldn’t be exploited? The first time I implemented a service with GraphQL, I was trying to figure out how to limit a query - which I don’t think many of the libraries had at the time - and this complexity makes the technology so difficult to manage and build that the time it takes to add a REST endpoint to accomplish the same task is so much shorter.

@someman7

15 күн бұрын

As I understand (I don't actually use GraphQL), the whole point of is to be flexible. But I thought you're only flexible during development, and the API gets solidified for a given release. As for your (historic) anecdote about rate limits, figuring that out seems to be a one-time cost, while flexibility in development is a continuous benefit.

@jfftck

15 күн бұрын

@@someman7 You have to protect yourself against circular references, massive data pulls, etc… It is a lot of effort to have that flexibility and, for me, it doesn’t make it worth the hassle. Additionally, since it’s more complex when compared with REST, you will have more chances for security bugs in whatever flavor of GraphQL you’re using. It just feels like a solution for a problem that I can solve in less than an hour using REST and, if you are using a language that has strict typing, it shouldn’t be that big of an issue maintaining type safety at least on the server side and you can fail all requests that don’t conform to the data contracts for each endpoint. But I understand that it is a larger issue if your server is running TypeScript/JavaScript, Python, Ruby, or any other programming language that doesn’t have strict data types. So, it’s fine if this works for some, but I think many will start a project with GraphQL with a feeling that it’s the greatest thing ever and then, months later, find it being a source of pain to maintain it.

@JohnSmith-op7ls

14 күн бұрын

GraphQL is just another one of those poorly thought out things that got popular because so many devs love to crawl up into the butt cheeks of big tech companies and assume if they’re doing it, it must be the best, and also they’ll seem smart if they do it too.

@JohnSmith-op7ls

14 күн бұрын

@@someman7Flexibility is always a trade off, it’s not free. If you don’t know for a fact that you need that level of flexibility, and it’s worth the cost, don’t do it. Way too many devs love to choose stack and design for hypothetical future requirements that 98% of the time never become needed, and they carry that technical baggage around for nothing.

Trust and Safety mentioned, keep flaming that cloud.

prime's absolute refusal to attempt to understand ruby is hilarious

@NostraDavid2

14 күн бұрын

Isn't Ruby pretty much a Functional Programming language, other than all those pesky Objects? Somewhat Lisp based, somewhat Smalltalk based. Makes sense Prime doesn't want to learn. It's too close to Haskell!

@smoked-old-fashioned-hh7lo

14 күн бұрын

@@NostraDavid2 ruby has nothing to do with haskell or any fp language. it's a lot more similar to python and javascript. before node was around, everyone was using ruby and php. it's a very simple and easy language to learn.

@stevenhe3462

12 күн бұрын

@@NostraDavid2 Ruby is an expression language and is nowhere functional-everything is mutable and effectful.

I've been working on a GraphQL API for about 4 years. It's been nice. Our app is fairly large/complex, and a well-organized GraphQL API saved us from maintaining 1000+ dedicated REST endpoints.

@zhoulingyu

15 күн бұрын

Your argument is flawed. What endpoints are to an rest API is what queries and mutations are to gql. They are just same shit in different toilets. Think again. Do you really have 1000 REST endpoints with 1000 entities or 1000 RPC endpoints with 1000 backing callbacks. Gql provides a structured way to subset fields and specify filters etc. Other than these, it is really not that different from REST.

@landonyarrington7979

15 күн бұрын

@@zhoulingyu lmao yeah no, try again 👍

@Th3T1redPanda

15 күн бұрын

That statement is in my opinion not true. GraphQL is REST API with extra steps. You can have identical API, doing the same with the easiest and most common communication method. Queries just won't be so elegant. Needing 1000+ endpoints is a sign of not understanding what one is doing. I was able to build and maintain REST APIs for 20+ mobile apps all by myself. My solution: vanilla PHP (no composer, no autoload, direct lib include) + FatFree "framework", served by nginx/apache with URL -> php file mapping, with file per endpoint. You'll endup with an AWS Lambda like solution. Simple, clean, easy to maintain and scale solution. It will be exactly the same stuff, will just less. You haven't build such stuff before and started from graphql, do you?

@landonyarrington7979

15 күн бұрын

@@Th3T1redPanda lmao

@5epo

11 күн бұрын

​@@landonyarrington7979 I swear this comment section is packed with people who have never used GraphQL uttering nonsense

Good thing I never learned it

@swojnowski453

16 күн бұрын

I just waited till they came to the conclusion it was not it ;). It always happens sooner or later. Bleeding edge dancing is more fails than wins ...

@KevinJDildonik

15 күн бұрын

I make 6 figures programming it. Feels good.

@SpikeTaunt

15 күн бұрын

@@KevinJDildonik random flex on a random comment section,

@swojnowski453

15 күн бұрын

@@KevinJDildonik 6 figs only feels good in places where there is no inflation

@natescode

15 күн бұрын

​@@swojnowski453😂 unfortunately true. Six figures is poverty is San Francisco. "I make six figures" while also on food stamps.

I worked on a large project where we had graphql being called by event pipelines. We dos'd ourselves weekly with all sorts of cascading event triggers, it was a nightmare.

@CKSLAFE

16 күн бұрын

nice

@KevinJDildonik

15 күн бұрын

This is like saying allowing users to type "rm -rf" into a production database causes issues. Just use persisted queries. Tada.

Trust and Safety team mentioned. Upvote!

Ok, that Cloudflare bit about DOS-ing yourself was funny.

Isn't GraphQL supposed to be this flexible only in development, while in production it is restricted to what the official client actually ends up using, meaning that, unless the official client is making nested queries, you can't make nested queries as well?

@KevinJDildonik

15 күн бұрын

Most GraphQL systems literally do not allow nested queries. Like the system stops circular references and returns a null.

I thought GraphQL is for the backend not frontend. What are these people doing? Exposing arbitrary queries to their users?

The attack surface problem is easy to avoid with persisted queries (assuming your API is only intended for known clients). End users aren't able to make arbitrary queries but frontend team get full flexibility

@EikeSchwass

16 күн бұрын

Yeah I wonder why the author completely skipped over that

@Ktulhoved

16 күн бұрын

Authorization is not a problem as well if you have necessary claims in token. Skill issues.

@KevinJDildonik

15 күн бұрын

For anyone who doesn't get it: This is like saying allowing user input without sanitization causes problems. Duh. So all modern GraphQL systems (should) have persisted queries where these rules are harshly enforced.

@dominikvonlavante6113

15 күн бұрын

But what is then the point in using GraphQL when you are only limited to persistent queries? Those I can build with REST. The entire point of GraphQL is to enable highly dynamic queries.

@karakaaa3371

12 күн бұрын

@@dominikvonlavante6113 The point is persisted queries can be created by other engineers in your company, so you don't have to keep adding new REST endpoints because one team wants A and another wants B.

In my company people use GraphQL to make bakend-to-backend integration, and it's been nice since the security part is less of an issue and it would eb harder to make teams stop what they're doing to create new endpoints. But yeah, it's the pattern of "new tech not so new anymore. People are finding out it's not the best for every case".

Really great article, 6 yrs is a good amount of experience in a tool!

Btw, GraphQL recently (maybe a year or 2) added *persisted query* support. It's basically storing a pre-defined set of GQL queries on the server. All these queries will have a unique signature that can be passed to a GraphQL client, which then will run the pre-defined query stored in the server without needing to write the query in the client. Whala, we're back to REST APIs with extra steps and massive request overheads

@ZoranRavicTech

13 күн бұрын

It was not added, you always had the option to define queries on the server side. And it is still nothing like REST, even if you are using persisted queries.

Oh another article about skill issues. Been using graphql in production on multiple apps from small to enterprise size, it's a joy to use once you wrap your head around how to properly do it. The article author is making a big deal over things that could be easily fixed, maybe the ruby framework he's using just sucks.

@ZoranRavicTech

13 күн бұрын

Right. I'm tired of these guys writing about issues that they essentially created themselves.

@Pretagonist

9 күн бұрын

Yeah I feel that unless you're writing your graphql stack from scratch the gql package should have mitigations for many of these issues. But you do have to be very careful about what you expose to your graphql endpoint.

Listening to this while working on higher-level GraphQL code, but we are leaving most issues on the provider of the framework. You don't touch stuff below gateways and subgraphs like the OP did, unless it's really your thing. It's like writing a web application in C.

Isn't there some way to take the set of graphql requests in the code and set them as prepared statements for production deployment? You'd get the flexibility in design and development of the front end, and effectively a standard json API out the other end

@lobovutare

14 күн бұрын

So you mean, a frontend engineer writes the spec for they want to get from the backend and then a backend engineer can implement that spec? That's called OpenAPI.

@orterves

14 күн бұрын

@lobovutare no, I mean the backend engineers implement a graphql service for development, the frontend develops and settles on the set of queries they need, then the build step locks in and optimises for just those queries - and doesn't allow others - when deployed to production

Authorizing fields works much better when you integrate this functionality with you database (e.g. RowLevelSecurity). While that also has to be maintained, you can't accidentally break it if you mess up in a handler somewhere :)

Microservice graphql is the greatest thing that has happened in an enterprise context. Consistency, robustness, responsibility

This guy basically shot himself in the foot by admitting that for 8 years (2018 - 2024 / adoption - disilution) he never had requirement to write performant, secure or maintenable software. That's a real bad professional growth curve.

@ZoranRavicTech

13 күн бұрын

And people eat it up anyway.

I understanc GraphQL being used directly by an SPA is a problematic - but as a method of data access between the backend web app and the DB surely it is a reasonable option. As a language and more flexible replacement for sqlc or grpc for example/ It would surely be better than an ORM?

Squeal light is a cursed phrase. I really hate listening to it. If my colleagues start saying that, I'm switching jobs.

Isn't response 200 "failed successfully" also a practice in htmx? Or is there any good way to get around it? 🤞

I don‘t know about Ruby but the authorization in Go with GQLGEN is as simple as for REST. Normally you add authorization for a whole type and not for every field. But the difference is you can add it for every field in case you need it. Also the point with performance is constructed and not true in most of the cases. Open API is no comparison to a real typed endpoint that GraphQl offers you. TRPC is not an option for every Backend that doesn’t use Typescript and GRPC doesn’t run in the browser. Sorry but GraphQl is for many use cases still one of the best approaches.

A piece of advice to anyone considering GraphQL - just use Relay and Relay spec... and if you feel like Relay is too complex for your use-case then perhaps consider ditching GraphQL altogether and going with a simpler approach like trpc or similar that still gives you type-safety.

Communism comment on point. When people say REST they just mean a GET or POST HTTP endpoint. Very rarely do they mean the full verb set (PUT, DELETE, PATCH, UPDATE,...). This ends up being a lot easier to manage with the various API/security layers that inevitably get baked into enterprise environments, and I'm ok with that, but be better if there was clearer nomenclature.

those non-functional requirements mentioned in the first 2 minutes are also known as "the production environment" :D

We are currently implementing a reporting type thing that needs access to our legacy business logic and can't use SQL queries directly. It's pretty trivial to throw a GraphQL server on top of your existing API. We define our report data fetching as graphql queries, but only allow persisted queries to be run. Adding new reports is trivial and doesn't require changing any code, just insert some more queries into the database and everything works. Because it is build on top of our existing API, auth is solved automatically as well (with some caveats). Providing a general public graphql endpoint sounds difficult to get right, but there are use cases where it really is amazing and building that reporting thing right now is so much fun, because it feels so elegant.

@ZoranRavicTech

13 күн бұрын

What's the advantage of using gql for your case? Can't your reporting thing access the api directly?

@EikeSchwass

12 күн бұрын

@@ZoranRavicTech 1. The data is distributed over a lot of services and the node and edges concept of graphql helps a lot there. 2. N+1 on the client is impossible to solve for our legacy public API (in some cases) 3. Flexibility is really nice. We don't need to change our endpoint to allow newer reports. The more reports (and nodes there already are), the easier it gets to add new reports.

@ZoranRavicTech

12 күн бұрын

@@EikeSchwass sounds like a great use case

With Apollo Router and their flavor of GraphQL you can do a thing called persisted queries which are known queries your client sends saved into a db of sorts. You can then block any unknown queries and only allow the persisted queries to be sent so only known queries can hit your end servers. This stops the whole taking a query, modifying it to request a billion data elements and sucking up CPU time

I've had a lot of success with graphql, but I'm coding in a walked garden where I can trust all the clients that are hitting my apis. Auth has been easy and left at the per-query level. So I haven't had to deal with the complexity described here.

@ZoranRavicTech

13 күн бұрын

They talked about GraphQL like it's completely broken, but I don't think they realize many people wont ever run into those issues.

REST works well for application-defined data types (which suffices for 99% of apps). I use GraqhQL for user-defined data types (extensible schema) and ad hoc queries (reporting, etc). It does pretty well there but still is far from perfect. Paging is terrible/unspecified, and can be impossible for multi-root queries (ex: list all Xs, Ys, and Zs in the same query, where each record type exceeds the page limit). It does have some usefulness to eliminate the number of calls needed for UIs to do joins, but still think doing custom backends that are efficient and fast are worth the trouble 99% of the time. Back-end work is light speed compared to tweaking UIs.

Why not just use J’SON API to create an endpoint?

@semyaza555

16 күн бұрын

21:57 Lmfao

@justanothercomment416

16 күн бұрын

You clearly care more about correctness and robustness than the buzzword technology of the day. How dare you.

@NostraDavid2

14 күн бұрын

I presume "J'SON" is pronounced "Jismal"?

21:58 is implementing a little cache suddenly not a tool in any SWEs toolbag? it doesn't take a library to do in less than a day lol

Soap only

@popcorn245

16 күн бұрын

Who hurt you...

@martinzihlmann822

16 күн бұрын

my eye itches when i remember reading xmlspec and: PUT 200 ok, authentication required.

Why did the GraphQL server send a 200 response code for an error? Because it wanted to say, "I'm successfully letting you know I messed up!"

graphql was such a headache

im guessing it makes sense to still use graphQL between microservices on the same security level in the backend, just anything that faces the public should be REST for safety

*Cries in corporate Microsoft GraphQL interface*

What about SOAP, is this still used - just smooth XML? There is also gRPC, which is more flexible than REST.

@lobovutare

14 күн бұрын

SOAP? That's not hip! We need REST. REST? That not hip we need GraphQL! GraphQL that's a shit show, we need REST with a spec! REST with a spec? How's that not SOAP?

@karakaaa3371

12 күн бұрын

XML is cringe

@TheBadFred

12 күн бұрын

@@karakaaa3371 It's an Extensible Markup Language.

I have only worked with 1 GraphQL endpoint and it only had 1 client who used the exact same query every time

GraphQL is the exact same thing as firebase/supabase. But good luck finding a GraphQL aficionado that wasn't extremely anti BaaS

In terms of suggesting replacements for graphql, this article completely glosses over the graph portion of graphql. If you have a large amount of services that you want to build a single coherent api facade for, openapi provides nothing for you in that area. You’ll have to roll your own service relationship mechanism.

@celchronicles

16 күн бұрын

I mean that's basically an API Gateway plus a Facade.... Which is also what GraphQL framework does anyway

@swojnowski453

16 күн бұрын

do not oversaturate your app with services, if you are a firefighter you are not a policeman, being everything means being a supermarket, but we all know what's wrong with supermarkets, they sell cheap crap ;)

@kasper_573

16 күн бұрын

@@swojnowski453i would also recommend avoiding microservices and graphql for most projects. They are large scale concepts that will drastically overcomplicate things if you choose to implement them before you actually need them. But that doesn’t mean it’s never useful, or a deprecated approach. Our industry is plagued by people who fail to grasp nuance and only remember extremes, ie ”graphql good/bad”. Or people who start projects with a stack and architecture without truly knowing if their choices are appropriate for the project, and they’ve just chosen what’s popular. Sometimes microservices is the right choice. Sometimes you’ll need an api gateway. GraphQL could be benefitial here. Or . This is the nuance and exploration I’m missing in the article.

@josevargas686

15 күн бұрын

@@kasper_573 yeah, people only care about 1 thing: am I using the BEST tool right now?

@bradclements1815

9 күн бұрын

@@swojnowski453 wait, you forgot about "Fire Police" en.wikipedia.org/wiki/Fire_police Yeah, its a thing.

so i'm a bit confused because it seems like most of these problems could be solved by some preprocessing of the query. they mentioned this idea of keeping track of query "complexity" not being an adequate solution but i don't understand why it wouldn't be: you know every data type's number of attributes and the size of each attribute, which could allow you to pretty accurately predict the size of the server response similarly, couldn't you have a greedy algorithm approach with auth so that for each query, instead of authorizing every single object, just figure out the max authentication needed and verify the client has that?

@ZoranRavicTech

13 күн бұрын

That wont mean much for junior devs. If it is not working that way out of the box it may as well be impossible. That's why you see them talking about those all issues that could have been avoided.

@creativecraving

10 күн бұрын

The way I understood it is that estimating the query complexity is easy to get wrong unless you have the skill to rewrite graphql; so it's far more difficult than just making REST endpoints the normal way.

@ZoranRavicTech

10 күн бұрын

@@creativecraving You can skip complexity estimation and instead do the same thing you would do in rest and set a limit on the number of items in a response of a resolver + don't make it possible recursively call resolvers. Also if it is possible to write a rest endpoint then do that. Gql is best for larger or more complex api-s.

Eh, a post from someone who primarily works in Ruby and TS. Skipping this one.

GraphQL would be nice if it were compiled into native SQL and executed on db side, rather than composing a bunch of Resolvers, which execute statements separately. Imagine a SELECT statement that return 20 items and each of them fetches the details over 20 individual SQL statements. 25:34 did he just say: Edge titty pee?

@NostraDavid2

14 күн бұрын

"Aitch titty pee"

@ZoranRavicTech

13 күн бұрын

I think Hasura can auto-generate GraphQL for your db. But you also need to have business logic, so I think you still have to write resolvers somewhere.

14:35 that's why bff should be owned be the same team as ui. Of course, the bff still needs to get data from somewhere, but the same thing applies to graphql if that's the case. So owning bff+fe by the same team solves this issue, and no graphql is needed. Of course the development of be part will take some additional time, but velocity inside one team should be fast enough.

I feel validated by this. I tried on three occasions to make GraphQL make sense vis-a-vis my standard REST patterns and could never make it work. REST always seemed better. I legit felt like I was missing something and had a skill issue.

@ZoranRavicTech

13 күн бұрын

What kind of problems were you running into?

@AaronMartinColby

13 күн бұрын

@@ZoranRavicTech Primarily optimization problems. We could never get our head around the exact way data was flowing like we could with a basic REST endpoint. We could never really understand how to best cache things. And every time we reached a point where we could actually benchmark something, the GraphQL request would be upwards of 10x as slow. Genuinely, we thought we were just too stupid to get it and would need to pay a lot of money for some classes or contractors to show us how it's done. The thing we really wanted was response shape validation, and we got that with JSONSchema and a TypeScript monorepo, so we just sort of dropped GQL. I shared this video with my old coworkers so they could also feel less bad about themselves.

I was done graphql in about 6 days. It was the time it took me to understand the basics of graphql, and to decipher this (somewhat big) project i just entered, that was graphql. Well, the project is basically already in production, so it is what it is.

The over-the-top reaction to a Ruby DSL at ~ 10:30 is definitely annoying to me. It's always a great time when someone reacts to something their seeing like "ahh gross" without even knowing what they're looking at.

Status code 200 Graphql error

Supabase solves this. Postgres extensions can expose both rest and graphql APIs for your database and you can restrict access with row level security. This is quite powerful because for small applications you can remove the “backend” completely and make the database your backend. You can make triggers and have them call into whatever is left of your backend code or make HTTP requests from your database functions. And hopefully all of this without turning your app into a security sh*thole

@jfftck

16 күн бұрын

This is great if your data is only from a DB and doesn’t require external services. My team is building integrations with multiple services and we can’t keep the data in DBs because that would change the source of truth for the data.

@vladimir5935

15 күн бұрын

@@jfftck yeah that wouldn't work very well. in my case I just call into openai's APIs from a serverless function and all the data is in the db. do you use graphql for your use case? sounds like it could work for you

Trust and safety team mentioned 😂

I have a GraphQL project on the backburner for a while, and then I started seeing all sorts of articles about its vulnerabilities.

@ZoranRavicTech

13 күн бұрын

The issues they mentioned can easily be avoided, at least by devs who have had experience with gql.

I've never seen a reason to use graphql. Thus, i never used it. Rest and gRPC is always easier to use

@ZoranRavicTech

13 күн бұрын

Can you batch your REST api requests?

At Facebook where they invented it they were over it in like 2 years. What took dude so long?

@semyaza555

16 күн бұрын

It’s easier to cut bait when you’ve seen how the sausage is made.

@ColinFox

16 күн бұрын

@@semyaza555 I do not think that expression (cut bait) means what you think it means. :)

@juliancorredor1128

16 күн бұрын

Any source? not to doubt you but I would like to read more about that

@trevor2453

16 күн бұрын

@@ColinFox I'm just batin'

@armaandhanji2112

16 күн бұрын

It's okay to dislike a technology, but let's not spread false information. Meta hasn't abandoned graphql at all lol, they still heavily use Relay in critical infrastructure.

If your app needs lots of custom queering functionality driven by unpredictable user requests, then use Graph QL. If your app tends to do the same exact queries every time, just use REST. I've known this since the start.

@natescode

15 күн бұрын

Exactly

@ZoranRavicTech

13 күн бұрын

But then you lose out on request batching.

@thewhitefalcon8539

12 күн бұрын

Oh there's lots of custom queering in this gay as heck app

I get the points, but if my company were to use rest instead of gql for data fetching, out development would be so much slower

The first I noticed when learnt about graphql was the http code and http action thing. If everything is GET and everything is 200, a lot of very usefull middle ware (LB Routing, Caching, etc...) will stop working.

@komfyrion

15 күн бұрын

Small correction; with GraphQL everything is POST.

@ZoranRavicTech

13 күн бұрын

You can still have caching with GraphQL. But you need a library that correctly handles different requests.

@ZoranRavicTech

13 күн бұрын

@@komfyrion Nothing about gql requires you do use POST for everything. The correct method should be GET for queries and POST for mutations. Some libraries only use POST, but that is a limitation of those specific libraries and not anything to do with gql itself.

@komfyrion

12 күн бұрын

@@ZoranRavicTech Right, my bad. That's an Apollo Server implementation detail.

@framegrace1

12 күн бұрын

@@ZoranRavicTech Yeah, some engines had to create a workaround, by (basically) turning specific queries to REST gets. THe problem keeps being the same, is not prepared for the REST world.

Needs a library to secure your data bank objects - NO!

Back in the days we used to call this sql injections, now people just call it a feature and put a price tag on it. What has the world come to.

27:45 is such an awful take haha. Every boundary between two processes has an API. That boundary is what the “Interface” in API means. This API can be explicitly written or learned through tribal knowledge. I would much rather work with the team that documents their APIs.

amazing

GraphQL was the first hype train I ever got on, then once I was using it I was like....why did I do this? Then other junk like Gatsby started using it for no good reason and I steered clear.

Error 200: Task failed, successfully. Lol

It's insane how non functional requirements aka. "just mole hills" are so rare in my job market, I'm gonna turn into alcoholic

6 years!?....i was done after 6 minutes

did I hear "graph-queel"? wtf

@PristinePerceptions

15 күн бұрын

You must be new to Prime's channel 😅. He's all in with "Graph-queel" and "squeal".

@christopherwood6514

15 күн бұрын

Saying sql as squeal has become the default for me

@zyriab5797

15 күн бұрын

That's how you are supposed to pronounce it. It's a nod from GQL creators to SQL.

You, sir, have gotten a like from me on 9th min when you CloudFlared. Yes.

I noticed someone posting the ferret butt emoji. Thor recently got it taken down for "sexual content".

Looks like Liveview has none of these problems.

6:20 and what stops doing this maliciously in REST with a loop?

@popcorn245

16 күн бұрын

Nothing, necessarily, but the only difference is in GraphQL you have a schema, so you have a map of the whole API, which your restful endpoints won't have. My problem with graphql was less about security, but more about promise trees being slow and no built in caching so have to do a lot of work to make it performant.

@mattymattffs

16 күн бұрын

Rest has pretty simple rate request limits and caching is much easier

GraphQL is a good query language with some weird warts and idiosyncracies. 1. People are using it in places they really shouldn't be 2. The most popular implementation is Apollo and Apollo is hot garbage

@macctosh

16 күн бұрын

graphql-request.... it's so simple I don't know why it's not more popular

@josevargas686

15 күн бұрын

did no one tell them that GQL works only for highly relational data?

@ZoranRavicTech

13 күн бұрын

You don't even need apollo. Idk why is it even popular, considering how little it adds.

Falcor mentioned

i think working on front end in general has become a joke. if its not a server side rendered app/company i wont even bother.

why do you pronounce it graph queel ?

What's actually needed in a network API? A compressed byte stream, often consisting of a diff of changes. And end users should never control servers. If you're in a heavy red tape org, I don't know what else to advise other than make execs know what the red tape actually costs, or change jobs.

@ZoranRavicTech

13 күн бұрын

In gql queries the end users control the servers as much as they do with rest requests.

@ricmorris9758

10 күн бұрын

"I need infrastructure??? But I want to just run a report on your server to do my integration"

@ZoranRavicTech

10 күн бұрын

@@ricmorris9758 with graphql you don't need any infrastructure to load data for your report, all you need is a single GET request. It's actually much simpler than having a flood of GET requests you would need if you used rest api.

@Muskar2

10 күн бұрын

@@ricmorris9758 The best part is no part! And for necessary APIs, I want to do 'Designing and Evaluating Reusable Components'

Yo

Dude, the highlighting from the second-to-last to the second character in a sentence/paragraph is like nails on a chalkboard. At first I was impressed how consistently he missed the first and last character so often. Now I see it's really just that odd lisp you don't want to call out in your buddy but can't stand to hear.

Denial of wallet attack

Cyndaquil < graphqil

kzread.info/dash/bejne/inaJ1bSPldOsXZs.html Pretty confident query hashes can mitigate all these DOS issues. The problem is additional complexity working on it.

😢 you are giving me all kinds of anxiety and grief and I don't even use GraphQL for API's 😢

GraphQL tried to solve a problem that didn’t exist imo. REST is the goat and lives on.

😂😂 cloudflare mentioned

If you can read python, you can read ruby.

I mean you should not be using graphql on the client side

@ZoranRavicTech

13 күн бұрын

I'm pretty sure that gql is primarily consumed from the client side of websites and apps.

And here I thought GraphQL biggest sell was performance:)

GraphQL has always had security problems, despite many attempts to fix them.

@ZoranRavicTech

13 күн бұрын

Graphql doesn't handle security, same as rest does not handle security. If you didn't do auth correctly that's on you.

at least make schema introspection authenticated

As an old fart who hasn't kept up... Why would you even need something like GraphQL if you have good API endpoints and frontend developers who make good controllers?

remember folks, facebook gave us react and graphQL, thanks for wasting a big chunk of life writing react and redux boilerplate. I never used graphQL, it never sounds good to me from the beginning. The react and redux hype train were impossible to avoid in the 2015s years.

Hype train pessenger

Better than SQL, that's all I know