Remix.run Logo
gethly 2 days ago

GQL was always one of those things that sound good on the surface but in practice it never delivers and the longer you're stuck with it the worse it gets. Majority of tech is actually like this. People constantly want to reinvent the wheel but in the end, a wheel is a wheel and it will never be anything else.

trueno a day ago | parent [-]

i do a lot of data shenanigans and it's just annoying to work with when some saas goof doesn't consider that orgs are in the business of warehousing the piss out of entire platforms worth of data that they are paying saas guys a million dollars a year for just so they can marry it together with other reporting. all roads lead to damn reporting. so if you want to woo clients but only have graphql then you should probably build some connectors they can use elsewhere they can easily retrieve all their data from. i straight up don't meet business analysts who use graphql to fetch reporting data. it's always me and my engineers sidequesting to make that data available in a warehouse env. my prob with graphql is it forces me to get intimately familiar with platforms i want to just plug into the butt of some object storage container so it can auto ingest into the warehouse and walk away. this is easy to do when the platform who knows their data and their data structure well serves up a rest api that covers all your bases. with graphql the onus is on me to figure out what the f all data i might even need and a lot of platforms have garbage documentation. so much fun since every service/app designs their db differently. no matey, postman is not the time or place for me to familiarize myself with your data model. i shall do that in the sql gladiator arena once ive ironically over fetched and beat the shit out of your graphql resolvers and stuck the data back in a database anyways. if im developing an apps or tools to interface with some platform graphql is fine but it ends there. in situations where i need to bring data pipelines online for my org its just annoying to work with. syntactically im annoyed, my engineers are annoyed, it just amuses me to no end that platforms dont know how big reporting is at orgs they seem surprised not everyone is developing some front end app to their "modular commerce solution" and sometimes they dont even know how to answer when we ask if theres anything we should consider because we're about to hang out at the ceiling of our allowed rate limits when we bring these data pipelines online. they seem surprised that we're interested in reporting, like wtf we pay you a million a year so we can do your whatever as a service thing of fkn course we'll be reporting on the data there. how else are we gonna smoke that proverbial value add on quarterly calls? graphql brings a query language over http. it takes a resolver that's well designed, configured and resourced. i'd rather just rawdog a sql query over the net and have postgres or whatever transpose that to json, return that and let me figure the rest out myself. ive never needed this exactness and freedom out of an api that graphql enjoyers love. i can take whatever there you throw at me and polish into the turd needed for the job, but i generally prefer vendors who have a well thought out and comprehensive and reliable set of rest endpoints. in that scenario its just easier for me to real time it into a warehouse and immediately push off to a stream or queue that populates a postgres instance if i need to build a high traffic web app. reporting needs and application needs are met and i dont have to don't need to do bespoke jujutsu sitting in a rest client and staring at json requests to determine what data i need before i architect out some one off gql query. i look at ton of data, graphql is the most overengineered and unintuitive way to review a lot of it.

its a data retrieval setup that specifically caters towards front end dev. i've done plenty of fe and i will design an app with whatever data when its needed when im building the front my headspace is completely impartial to whether or not im working with gql rest or a podunk db. so im here wondering why no one is just saying this: its nice and convenient when you're on the front, but its hardly a requirement to need a gql api. some like to think it solves for an organizational rift between front and backend devs, and that's just kicking the can down the road. im not sold on the empowerment of fe at the expensive of teams working well together. yeah isolate them more well never need to talk to fe again. great strat

since i happen to also work backend and on enterprise data i see a lot of angles that tightly scoped front end graphql enjoyers do not see and will likely never have to deal with ever. but we deal with it all the time, at least it's convenient for one of us. sucks that it isn't me

gethly a day ago | parent [-]

@grok: summarise this post in two sentences.

FrustratedMonky 20 hours ago | parent [-]

GPT: "GraphQL is fine for frontend apps, but it’s a pain for enterprise data pipelines where the real job is bulk ingestion, warehousing, and reporting—work that REST APIs handle far more cleanly without forcing engineers to reverse-engineer undocumented schemas and babysit resolvers and rate limits. Organizations pay SaaS vendors to extract value through reporting, not to do bespoke GraphQL gymnastics, and the industry seems oddly surprised that data teams just want to ingest everything, dump it into a warehouse, and get on with their lives. "

gethly 20 hours ago | parent [-]

:thumbs_up: :)