[HN Gopher] GraphQL kinda sucks
___________________________________________________________________
GraphQL kinda sucks
Graphql is great, but is totally over hyped. This is probably more
of a rant or a frustrated dev outburst. but beginner to mid level
developers are lead down the path of USE GRAPHQL especially on
youtube... and this is just unfair and wrong. The good: - It
makes working with describing the data you want easy - It can save
you bandwidth. Get what you ask for and no more - It makes
documentation for data consumers easy - It can make subscription
easier for you to use - Can let you federate API calls The bad -
It is actually a pain to use, depending on the backend you are
using you'll have to manage two or more type systems if there are
no code first generates in your language - It doesn't support
map/tables/dictionaries. This is actually huge. I get that there
might be some pattern where you don't want to allow this but for
the majority of situations working with json api's you'll end up
with a {[key: string] : T} somewhere - No clear path for Api
versioning you'll end up with MyQueryV1.01 MyQueryV1.02
MyQueryV1.03 Don't use Graphql unless you're managing a
solution/problem set that facebook intended graphql for Invest
your time in a simpler solution then running to GraphQL first
thanks for reading my ted talk please any senior dev's drop your
wise words so that any new dev's can avoid tarpits
Author : randytandy
Score : 505 points
Date : 2022-08-06 10:25 UTC (12 hours ago)
| randytandy wrote:
| Hey all, didn't think this would be anything more than 1 or 2
| comments.
|
| I appreciate everyones passion and level of thought going into
| the replies. I will try read most of them.
|
| Please note that if you reading this.
|
| My intention of this post was to get a little rant off my chest
| and find out about potential solutions and gotchas about using
| GraphQl. It's unproductive attacking me or anyone else for
| character like "clearly not a senior developer" or "clearly never
| used API's before" because if anything this is about trying to
| find a solution and to save each other time.
| NonNefarious wrote:
| I was psyched to hear about GraphQL, but when I looked at it and
| found no apparent way to do joins... I wondered what the big deal
| is.
| vlod wrote:
| I think the general idea is that it's a graph rather than
| relations.
|
| You "join" by using the parent ID (e.g. employerID of parent
| container to get employees). This can (and often) introduces an
| n+1 problem unless you watch for it and use dataloaders.
|
| Not saying this is great or anything. :)
| NonNefarious wrote:
| Thanks. The issue is what if I want to pull all the employees
| from the table of all customers, to determine how many
| employees have made purchases under our employee-discount
| plan?
|
| I just made that up as something that would likely require a
| join without really thinking it through too much...
| cletus wrote:
| My usual experiene is that people use GraphQL wrong. GraphQL's
| primary use case is to homogenize access to a bunch of
| heteregenous backend services. If you find yourself just taking
| your Postgres database and creating a 1:1 mapping between your
| tables and GraphQL, this probably isn't a good fit as you'r ejust
| adding another layer for no reason.
|
| > No clear path for Api versioning
|
| GraphQL came about as a way for mobile clients to call backend
| services. At Facebook, once a version (of th emobile app) was
| released, it was essentially out there forever. Some people would
| simply never upgrade until they absolutely had to.
|
| So the point of GraphQL is that you want to get away from
| thinking about versioning your API and cleanly upgrading because
| you probably can't. You can do versions but you don't have clean
| divisions. You'll mark a given field as "since v2.1". And fields
| that you ahve added can basically never be removed. The best you
| can do is make them return null or an error.
|
| So if you want to do versions it probably means you have control
| over the server and the client such that you can deploy them
| almost simultaneously. If so, GraphQL isn't really designed for
| your use case. If not, get out of the mindset that client and
| server versions can move in lockstep.
|
| I will say I think GraphQL made one mistake and that's baking in
| string values into the API. You can't change a field name without
| breaking your API. Same with enum values.
|
| Protocol buffers (including gRPC) instead went for numbering. The
| name is just a convenience for reading the IDL and data
| definitions and for code generation but it doesn't translate to
| the wire format at all.
|
| This can have downsides too but they're fairly minimal. For
| example, if you accidentally renumber your enums by inserting a
| new value in the middle, the whole thing can break (side note:
| always explicitly number your enum values in protobuf! That
| should've been the only way to do it).
|
| Another issue is that fragments seem like a good idea for code
| reuse but they can get really out of hand. It's so much easier
| just to add a field to an existing fragment. If that fragment is
| used in a bunch of places you may find yourself regenerating a
| ton of code. You will never be able to remove that field from the
| fragment once added.
|
| Disclaimer: Ex-Facebooker.
| hamandcheese wrote:
| My company has many backends federated together, but a
| monolithic, web-based frontend. It's actually really easy to
| remove a field from graphql.
|
| 1. Remove all uses from the frontend. 2. Deploy. 3. A day
| later, delete it from the schema.
|
| If deleting it causes relay compiler errors, go back to step 1.
|
| (The less lazy way to do it would be to actually pull some
| stats about how long-lived frontend bundles are)
|
| Not being able to delete fields only really applies if you have
| a huge number of clients that you can't easily force to update
| on a whim. Plenty of folks just have web clients.
|
| My company doesn't have this, but I'd love to get per-field
| usage stats about our schema.
| cletus wrote:
| That affirms my point: you have complete control over the
| front end.
| kehrin wrote:
| > It doesn't support map/tables/dictionaries.
|
| I don't understand this point. Is this talking about implementing
| GraphQL on the backend? Because consuming GraphQL you get a map,
| you get JSON! Do you mean a more specific data structures like a
| Set or Stack?
| the_mitsuhiko wrote:
| GraphQL has no native map type which means if you have a map
| data structure you cannot represent it within the type system.
| nawgz wrote:
| I think they were complaining that you couldn't get back a
| query with unknown keys like a "select * from my_table" GQL
| equivalent
| drcode wrote:
| That also doesn't make sense: No matter what, you're going to
| have to parse the returned document linearly, everything in
| it is therefore equivalent to a list in performance.
|
| Random-access structures like dictionaries, hashmaps make no
| sense in this context: It would be stupid if you had to do
| extra work to tell graphql what your preferred key
| parameter(s) are so that it can create a dictionary, and then
| you get list-like performance anyway.
| kehrin wrote:
| But can't you? During development I had this with errors,
| where I just enter "error" as a key in my query, but the
| actual data was JSON. So it had keys that I didn't specify,
| but that I received non-the-less.
| legalcorrection wrote:
| Ignore all the noise and just use an RPC model between your
| backend and frontend. All these stupid trends and overengineered
| abstractions will come and go, but people will still be using
| plain RPC in 5, 10, 100, and 1000 years.
| mark_and_sweep wrote:
| But before you use RPC, try rendering your markup on the
| server. That, too, reduces a lot of complexity.
| [deleted]
| runald wrote:
| and let all the non-browser clients parse html?
| samarthr1 wrote:
| At cost of reducing cache ability though no?
|
| It is cheaper for me to put my react app in front of a cdn,
| split out my app into an api and front end than for me to
| have my site be entirely uncacheable.
|
| I can also cache certain endpoints behind the cdn that are
| mostly invariant for users. And, the network egress of json
| is much lesser than the egress of markup.
| jddil wrote:
| What? Server rendered content is infinitely more cacheable,
| maybe I'm not understanding what you're saying.
|
| In the boring old days we just did it all on the server and
| used the semantics of HTTP to handle caching ... it worked
| great.
| jddil wrote:
| The longer I do this the more I realize the part of engineering
| most of us enjoy is solving a problem in a novel way. Which
| means if left to their own devices engineers will recreate the
| entire tech stack every few years instead of using the shit
| we've already built 20 years ago cause it's too boring.
| x86x87 wrote:
| Resume driven development. It's the same shit: reinvent
| stuff. Use "cutting edge" tech. Get credit, move on. Who has
| time to just solve the problem and build something that just
| works?
| bryanrasmussen wrote:
| In the systems where I designed both front and backend and the
| API I did not need graphQl, but in many of the large companies I
| have come in to where things have been developed by many people
| over a significant length of time GraphQL really improved the
| frontend performance and time to release new functionality once
| it was introduced.
|
| Perhaps it would have been the case if they just cleaned up and
| released a new Rest endpoint, but I'm not so sure.
| [deleted]
| alexnewman wrote:
| I usually agree with stuff like this, but this one is wrong. It
| is true that graphql is overused, but frankly stuff like
| thegraph.com make graphql Freaking amazing! it's totally
| eliminated our need for anything like a backend to make stuff
| like https://dashboard.humanprotocol.org/
| nazka wrote:
| I feel 2 critical points are missing in the bad things: some
| control and security on the backend side, and more importantly
| scaling. Did these things got fixed? What is the cost on the
| cloud versus the same backend with an API (I saw a horrible story
| about that). Can I cache queries efficiently? Is it efficient and
| fast with high throughput of RPS? Or tell GraphQL to use Redis
| for some data? Etc...
| maximilianburke wrote:
| One of the things I dislike about GraphQL is that though the
| standard doesn't really specify a format all the implementations
| are closely tied to JSON.
|
| Between that and the (at the time, anyways) abysmal serialization
| performance of Juniper we ended up abandoning GraphQL.
| wzy wrote:
| GraphQL: A whole lot of work to do REST differently
| x86x87 wrote:
| A whole lot of work to do REST poorly.
| speedgoose wrote:
| Which is a good thing, because REST is not that great outside
| basic CRUD apps with tiny models.
| electrondood wrote:
| We use GraphQL at my current company, but it's a service that
| sits between the backend and the frontend and just munges
| together several different API requests from one. It's... I
| really hate it. The way we're using it, it simply adds a layer of
| opacity that makes debugging a client-server issue a giant PITA.
|
| I've worked at a few companies that used GraphQL poorly. I've yet
| to see it done in a way that makes me think it's the right tool
| for the job. And I understand the benefit of allowing the client
| to choose what they want to get back.
| gabereiser wrote:
| I tried graphql in a microservices environment and had huge
| headaches over schema stitching.
|
| Turns out, if you have lots of objects from disparate sources,
| graphql don't like that. Now you must stitch these schemas
| together into an uber schema roll query and use with graphql.
| Maybe we missed a step. Maybe we misunderstood. Maybe it was a
| bad decision.
| vlod wrote:
| I think Apollo Federation is for that:
| https://www.apollographql.com/docs/federation/
|
| Worth watching some youtube tutorial videos. Here's one I
| watched recently (~26mins):
| https://www.youtube.com/watch?v=v_1bn2sHdk4
| gabereiser wrote:
| Not everything is a graphql api
| locutous wrote:
| I used graphql at one place and our stitching was a disaster.
| I'm thinking bad decision.
|
| We also had micro services. It was the most unstable backend
| I've ever worked with.
|
| Yet the architects who picked all these techs were mostly
| lauded and didn't stick around to deal with the mess.
| soccersofia15 wrote:
| Same! We've been using WunderGraph to help with schema
| stitching and integrating other data sources
| PUSH_AX wrote:
| And good luck doing that in a language that isn't JS. All our
| GQL services were Go, but were forced to use JS for any
| stitching needs.
| stickfigure wrote:
| The biggest problem with graphql is that you have to do a lot of
| non-obvious work to harden your system against DOS attacks or
| people that want to fly by and download your whole database. It's
| easy to construct a query which puts unreasonable load on your
| system.
|
| The more fine-grained nature of boring REST calls makes it more
| easy to control client impact on the system.
|
| If you want to see the kind of work you actually need to put in
| to make a graphql API, look at Shopify. They have rate limits
| based on quantity of data returned. Cursors and pagination. The
| schema is a huge ugly mess with extra layers that never show up
| in the pretty examples of GraphQL on the internet.
|
| Note that even if you use graphql for a private api to your web
| client, folks will reverse engineer it and use it for their own
| purposes. There are no private apis on the web.
|
| I'm not a fan of graphql for anything that the public could see.
| It's somewhat akin to exposing a SQL interface; it opens up too
| many avenues of trouble. Keep public communication channels as
| dumb as possible.
| SnowHill9902 wrote:
| > It's easy to construct a query which puts unreasonable load
| on your system.
|
| Can you give an example?
| pdpi wrote:
| Details will depend on your schema, but the moral equivalent
| of "SELECT * FROM master_table" is a good start.
| withinboredom wrote:
| Have you seen the "turn your database into a graphql
| schema" products? I shudder at the poor souls who used
| those products. I mean, I assume they are decent products,
| but man, it's got to be so easy to screw it up and
| literally expose too much...
| throwawaymaths wrote:
| Hasura seems to be fine which we use internally in our
| company, though to be honest I don't do any complex
| queries and I don't think anyone is doing aggressively
| nested joins.
| lazyasciiart wrote:
| https://payatu.com/blog/manmeet/graphql-exploitation-part-4
|
| query dos { allDogs(onlyFree: false, limit: 1000000) { id
| veterinary { id dogs { id veterinary { id dogs { id
| veterinary { id dogs { .....
| pan69 wrote:
| > Note that even if you use graphql for a private api to your
| web client, folks will reverse engineer it and use it for their
| own purposes. There are no private apis on the web.
|
| How is this a GraphQL specific problem?
| crabmusket wrote:
| It's not, but the OP is saying this to pre-empt the "just use
| GraphQL for private APIs" defence.
| agucova wrote:
| At least compared to classical REST, usually access is
| limited to whatever the programmer explicitly chose to add,
| instead of being open by default.
| thr0wawayf00 wrote:
| It's also not that hard to implement attribute filtering with
| REST endpoints. People make a big deal about being able to
| control the shape of your API responses with GraphQL, but this
| completely achievable with standard REST APIs as well.
| tshaddox wrote:
| Sure, you could have a syntax for requesting (potentially
| recursive) nested resources in the query string of a REST
| API, and there are some systems that do something close [0],
| but if you do it's probably a less friendly syntax than
| GraphQL and has all the same problems as GraphQL regarding
| performance and rate limiting.
|
| [0]
|
| A very simple convention for including nested resources in a
| JSON API: https://www.jsonapi.net/usage/reading/including-
| relationship...
|
| A totally cool but kinda over the top library that exposes a
| REST API over your database with a very GraphQLesque query
| string syntax that supports recursively nested resource
| inclusion, filtering, etc.:
| https://postgrest.org/en/stable/api.html#nested-embedding
| softfalcon wrote:
| We avoid this by statically analyzing the queries that are used
| by the client, generating id'ed persisted queries for them, and
| only allowing those to be run if you're un-authenticated/a
| regular user.
|
| We also have user roles, which, if you're an admin, you can run
| raw queries of whatever you want, but basic users are locked to
| the persisted query options.
|
| It's pretty cool, definitely adds complexity to our
| builds/permissions, but it works. We rolled our own, but I
| think Apollo GraphQL supports this out of the box now.
|
| Not saying people should use GraphQL for everything though.
| It's kind of overkill for a lot of apps.
| humbleMouse wrote:
| thdxr wrote:
| Be careful with anyone with a take that says some technology is
| 100% bad always. Given enough experience / skill you can make any
| technology fairly enjoyable so I've only ever seen mixed
| reactions at worst from people giving things a fair try.
|
| GraphQL is a way to describe not only your API but also the
| entities and relationships in it. This enables certain useful
| things for client heavy applications, like cache normalization.
| If you look at clients like URQL they enable high quality
| features in your app that are otherwise extremely difficult.
|
| You can also do this with JSONAPI but the GraphQL ecosystem is
| more developed.
|
| Setting up GraphQL to minimize its rough edges is incredibly
| difficult. I've currently landed on a combination of Pothos +
| Genql + URQL to enable me to do everything in typescript instead
| of untyped strings.
|
| It takes very high skill to use GraphQL well. Few teams get there
| because they don't have the upfront time to do all the research.
|
| But if you pull it off it can be an incredibly productive system
| that is friendly to iteration and refactoring. I can send you
| some content we've produced on this if you're interested.
|
| That said, if I'm not working on a client heavy app, I'd just use
| a less featureful RPC framework.
| deltasevennine wrote:
| >Be careful with anyone with a take that says some technology
| is 100% bad always. Given enough experience / skill you can
| make any technology fairly enjoyable so I've only ever seen
| mixed reactions at worst from people giving things a fair try.
|
| So what does this mean?
|
| You're saying that in the universe we live in there is
| absolutely nothing that is 100% bad always. Everything is good
| for something? There is no concept of bad or obsolete things
| because it's all good for something?
|
| Let's restrict this to programming languages and frameworks and
| apis.
|
| Are you saying that in the universe of ALL programming
| languages, ALL frameworks and all APIs, None of them are at all
| bad and they are all good for something?
|
| I don't agree with this sentiment at all. In fact I think it's
| a sign of two possibilities:
|
| 1. that the person saying it is highly biased and unable to
| detect things that are genuinely bad.
|
| 2. The person saying it is just being temporarily illogical,
| there are clearly things in the programming world that are bad.
| He knows this but is so biased that he's incapable of
| processing this concept while promoting his favorite
| language/api/framework.
|
| Scenario 2 is the most likely scenario here. Not saying graphQL
| is bad. But to love graphQL so much as to say Nothing in the
| universe is actually bad?
|
| Let's be real, I am not against graphQL. However you cannot
| actually say that people against graphQL have invalid opinions
| because there is nothing in the programming universe that is
| definitively bad. This argument does not make any sense at all.
| Kaze404 wrote:
| The point is that "bad" isn't a useful descriptor of anything
| regarding their real-life applications, because it simply
| doesn't mean anything. Without more context, saying something
| is bad is just saying you dislike it with intent to present
| it as objective rather than subjective.
|
| For example:
|
| 1) "Haskell is bad because it's too theoretical" 2) "Haskell
| is bad in corporate environments, as its roots in
| mathematical and academia make it harder for people to get
| productive with it compared to something like Java or C#"
|
| The difference is clear. In my opinion it's best if people
| who care about what they're saying avoids #1, and instead
| frames their criticism like in #2.
|
| Note: those examples don't reflect my actual opinion on
| Haskell, it's just something I came up with while writing
| this.
| deltasevennine wrote:
| Hard disagree.
|
| >The point is that "bad" isn't a useful descriptor of
| anything regarding their real-life applications, because it
| simply doesn't mean anything.
|
| This is just a complicated way of saying "Bad things have
| no meaning and don't exist in the universe."
|
| Without getting too pedantic, in general, nobody agrees
| with this concept. Sure if you get pedantic you may find a
| couple people in this world who enjoy punching themselves
| in the face, but in general the overwhelming majority agree
| that punching yourself in the face is a pretty bad thing.
|
| Note: Punching yourself in the face is just an example of a
| universally "bad" thing. I'm not personally against
| punching yourself in the face, it's just something I came
| up with while writing this.
| Kaze404 wrote:
| Maybe I failed to express myself properly, but my point
| is that saying "X is bad." (emphasis on the period) is
| not really saying anything. It's much more productive if
| you explain why, how and in what environment X is bad,
| either before or after, like I did in example #2.
|
| In my experience when someone says "X is bad", the
| response is often either "haha" (which the subject then
| changes), or "why" (which leads to person #1 actually
| saying what they want to say). I'm personally not
| interested in someone's remarks about some technology
| completely devoid of context or nuance, and would rather
| hear about their opinion on such technology in tangible
| scenarios.
| deltasevennine wrote:
| >Maybe I failed to express myself properly, but my point
| is that saying "X is bad." (emphasis on the period) is
| not really saying anything.
|
| This logic also works for "X is good." or "GraphQL is
| good". This doesn't really say anything either and is an
| equally garbage statement following your logic. But your
| biases focus on the "bad" because you have a bias towards
| GraphQL.
|
| Either way I don't agree. Saying something like criminals
| are bad is not an invalid statement.
|
| If you want an explanation you can ask for it. If you
| don't care to know about the explanation then you don't
| need to ask for it. But just because somebody makes a
| statement without an explanation doesn't automatically
| make it invalid.
|
| For example "The plane is about to crash, please pull
| up." This is a statement without an explanation (emphasis
| on the period). Should I demand an explanation or comply
| without one? In your words, was this statement "really
| saying anything?" Yes it was.
|
| When you come to threads on HN it's mostly people looking
| for confirmation of their biases. They don't realize it,
| but almost everyone is doing this. If you weren't biased
| you would ask for deeper explanations. You would try to
| unravel the other persons reasoning and understand it in
| such a way so that you find a mistake in his
| understanding or your own. That's mainly why I'm here,
| but this thread is littered with posts following the same
| logical path as you.
| Kaze404 wrote:
| There are way too many assumptions in your post. Yes,
| you're right that I like GraphQL, but:
|
| 1) Nowhere in my comments did I say that's limited to
| negative comments. I think "GraphQL is good" is just as
| useful (meaning not at all).
|
| 2) "Criminals are bad" is not an invalid statement, and
| neither is "GraphQL is bad" or "GraphQL" is good. But if
| the purpose is to discuss criminality, and not just add
| noise to an ongoing discussion, it is also a useless
| statement. Imagine there's a debate panel going on,
| someone in the crowd stands up and says "criminals are
| bad!". Where does that lead the conversation?
|
| 3) "The plane is about to crash, please pull up" is an
| expression of fact, not an opinion, and not even
| something that warrants or is said in a discussion so I
| don't think the comparison makes sense. Either way,
| "GraphQL is bad" is an opinion, not a fact, and thus
| needs more context to be useful in a discussion.
|
| I'm not going to acknowledge the last paragraph because
| I'm presuming good faith from you, and I'd rather not
| turn this discussion into speculation about other
| comments in this thread or why you're here.
|
| That said, you're definitely right that I'm biased
| towards GraphQL, but I think we're having different
| discussions if you think we're discussing GraphQL's
| merits.
| lf-non wrote:
| Agree with everything here, but something that often gets
| missed is that you don't have to use all that GraphQL enables
| from day one.
|
| It is perfectly fine to start with an early implementation that
| treats GraphQL as mostly an RPC, with only resolvers for Query
| & Mutation types. You still benefit from GraphQL's type-safety,
| batching and code-generation.
|
| Once you have more familiarity with dataloaders, query
| complexity etc. update your output objects to have links to
| other output objects building the graph model.
|
| The issue is that too many people get fascinated with GraphQL
| early, then build deep & complex topologies and expose it in
| inefficient and potentially insecure way.
| chpmrc wrote:
| > Be careful with anyone with a take that says some technology
| is 100% bad always.
|
| THIS 100%.
|
| > It takes very high skill to use GraphQL well. But if you pull
| it off it can be an incredibly productive system that is
| friendly to integration and refactoring.
|
| I could not agree more. It's like any other piece of tech: once
| you internalize the mental model and are able to translate
| those abstractions in your language of choice everything
| clicks. And then it's hard to imagine going back to something
| more "primitive" (i.e. what's conventionally called "REST").
|
| After building "RESTful" APIs for years I can confidently say
| GraphQL (with a decent implementation) is a step up across
| almost every possible dimension (performance aside because of
| the additional parsing).
| throwawaymaths wrote:
| Eh I think "rest for external API access, graphql for
| internal frontend use" is probably a good thing.
| mccorrinall wrote:
| I love consuming graphql as a client. But writing resolvers and
| all that stuff on the backend? God, I hate it!
| adra wrote:
| I don't know your language of choice, but in the JVM
| ecosystem, Netflix DGS is so damn simple to build new
| resolvers.
| nawgz wrote:
| Hasura :)
| ant1oz wrote:
| Have you every tried to version your permissions on Hasura?
| Not cool. Product polish is amazing, and I love the
| postgresql integration.
| cpursley wrote:
| Interesting point. What sort of approaches out there do
| you know about for versioning permissions?
| endisneigh wrote:
| > Be careful with anyone with a take that says some technology
| is 100% bad always. Given enough experience / skill you can
| make any technology fairly enjoyable so I've only ever seen
| mixed reactions at worse from people giving things a fair try.
|
| Completely agreed. Without knowing the team experience,
| greenfield project or not or in general more information about
| the task at hand, how can anyone say GraphQL is good or not?
|
| One thing I've noticed among some people who've failed to move
| up in their career is that they carry these extreme opinions
| due to a proper understanding or a bad experience. Right tool
| for the job and all that.
| PainfullyNormal wrote:
| > Be careful with anyone with a take that says some technology
| is 100% bad always.
|
| On the flip side, you should also be careful of anyone who says
| some technology is 100% good always. It's far more common to
| see people talking up the advantages of some trendy new
| technology without ever mentioning the downsides. All
| technologies have tradeoffs.
| meesterdude wrote:
| > Given enough experience / skill you can make any technology
| fairly enjoyable
|
| Have you never used MongoDB?
| thdxr wrote:
| https://twitter.com/thdxr/status/1394903426023272452?t=BjMUo.
| ..
| mst wrote:
| The other thing to note is that early on the default
| configuration was optimised to score really well on trivial
| benchmarks rather than production workloads - including
| having important safety features turned off.
|
| A crashing MongoDB instance in default configuration was
| more likely to lose data irrevocably than a MySQL 3.23
| MyISAM setup.
|
| (note that while I still don't particularly enjoy using it,
| post-WiredTiger MongoDB is a different story so take this
| as a criticism of the people making choices in the early
| days, not at all of the current state of affairs)
| mdaniel wrote:
| https://threadreaderapp.com/thread/1394903426023272452.html
| Kaze404 wrote:
| That's a great thread. It mimics my (admittedly limited)
| experience with MongoDB and it's interesting to hear that
| wasn't an outlier.
| eduction wrote:
| > Be careful with anyone with a take that says some technology
| is 100% bad always.
|
| This isn't that though; the first sentence starts "GraphQL is
| great, but" and then the post lists first "the good" and then
| "the bad." Even the provocative headline hedges with "kinda."
|
| I wish there was more of this sort of balanced discussion on
| HN. There is a tendency among devs at least in public toward
| trying to get others to use the tech they use and are excited
| about, which is understandable, but everything involves trade
| offs and it would be nice to hear more of those up front (as
| opposed to one day "mongo is the bomb" and the next "actually
| mongo is terrible to back to postgres for everything).
| minusf wrote:
| > balanced discussion
|
| while the discussion can be balanced the real world outcome
| is normally binary: use it or drop it.
|
| i will not start investing huge amounts of time to learn
| graphql if it has very specific use cases for specific
| environments. so i naturally look for red flags and
| objectively negative experiences to see if those might be the
| roadblocks i would run into 2 months down the line.
|
| imagine a PM coming in all happy "i know nothing about
| graphql besides the hype but i think it's a great fit for our
| next project". where will balanced discussion take you there?
| thdxr wrote:
| was referring to some of the replies
| eduction wrote:
| Ah ok I definitely misunderstood, thanks for clarifying.
| endisneigh wrote:
| What exactly is the simpler solution that doesn't result in your
| same cons mentioned?
| JohnHaugeland wrote:
| Making a regular api
| endisneigh wrote:
| A regular api poorly implemented will have all the same cons
| and none of the pros.
| geysersam wrote:
| Just make a perfect api without any drawbacks.
| endisneigh wrote:
| GraphQl has a set of trade-offs. REST also has trade-
| offs. Bespoke RPC calls have trade offs. It's as if the
| entire discipline is an exercise in selecting trade offs
| or something.
| anotherhue wrote:
| Well put. Problem is we can get emotionally invested and
| tie our identities to these systems in a way that we
| couldn't if we were comparing the trade-offs between
| 18/10 and 18/12 inox steel.
| [deleted]
| [deleted]
| JohnHaugeland wrote:
| > A regular api poorly implemented will have all the same
| cons and none of the pros.
|
| Okay, so don't make a poorly implemented one?
|
| Also, no, it kind of won't. Let's look at what they are
| again
|
| .
|
| "It is actually a pain to use"
|
| Not an API characteristic
|
| .
|
| "you'll have to manage two or more type systems if there
| are no code first generates in your language"
|
| Not an API characteristic
|
| .
|
| "It doesn't support map/tables/dictionaries."
|
| Not an API characteristic
|
| .
|
| "No clear path for Api versioning"
|
| Not an API characteristic
|
| .
|
| Looks like it's actually zero for four
| gabereiser wrote:
| In order to build a properly implemented one, one must
| first learn to build one. I find most people jump onto
| graphql because they see the volume of work to create
| crud endpoints for all of their models and decided to
| punt.
| legalcorrection wrote:
| It's a false promise. You're just moving the complexity
| elsewhere, into wiring this ridiculous graphql
| infrastructure together and making it actually do what
| you want in all but the simplest/tutorial-like scenarios.
| intelVISA wrote:
| Seriously. I sometimes think I'm visiting a satirical
| alter realm when I see these obtuse systems that end up
| requiring more cognitive energy to glue together than the
| regular version in <lang of your choice here> being
| praised rather than derided.
| lelanthran wrote:
| > I sometimes think I'm visiting a satirical alter realm
| when I see these obtuse systems that end up requiring
| more cognitive energy to glue together than the regular
| version in <lang of your choice here> being praised
| rather than derided.
|
| You're lucky, you're only visiting. I'm working in that
| alternate reality :-)
| hestefisk wrote:
| SQL statements wrapped in function calls.
| thomassharoon wrote:
| There are patterns that can get you the same benefits without
| having to use GraphQL.
|
| Even on a REST API, you can achieve the same pros
|
| > - It makes working with describing the data you want easy > -
| It can save you bandwidth. Get what you ask for and no more
|
| You can describe the fields you need (and I assume that is what
| reduces the bandwidth)
|
| GET /users?fields=name,addresses.street,addresses.zip
|
| > - It makes documentation for data consumers easy
|
| I don't think so in practice. You can see Shopify's GraphQL
| documentation [1]. If anything it is more complex than their
| REST API docs
|
| > - It can make subscription easier for you to use
|
| Not too different from using something like SSE or even
| websockets and every decent web framework seems to have a
| decent implementation
|
| > - Can let you federate API calls
|
| So many ways to achieve this at the application layer (which is
| what GraphQL federation does with a Router). In the python
| world this could be separate WSGI apps or racks in ruby? And
| makes no difference if done at the load balancer level.
|
| [1] https://shopify.dev/api/admin-
| graphql/2022-07/enums/localiza...
| endisneigh wrote:
| There a lot of ways to do the same thing as GraphQL. The
| point is if it's as easy.
| [deleted]
| jeroenhd wrote:
| My problem with GraphQL: it doesn't support generics.
|
| I'm fine with request batching/complexity overloads/all that
| craziness. Most GraphQL libraries have some kind of protection
| mechanism in there, or allow you to artificially split up the
| request and forward it to your application load balancer.
|
| I'm also fine with a lack of API versioning, especially for
| internal services.
|
| Hell, I'll even tolerate the lack of dictionaries/maps because
| you can replicate the same data interchange by putting the key in
| the object you're requesting most of the time.
|
| What I really want is to do not have to write a custom pagination
| wrapper type every time I write an API. Let me write a
| Paginated<T> that contains a list of T and some metadata, dammit!
| I don't want to dump BookPaginated/PagePaginated/AuthorPaginated
| into different schemas!
|
| Another thing that bothers me is how types extending an interface
| need to have each and every field repeated. If I declare
| interface Car with wheels: Int! then I don't want to have to
| specify wheels: Int! again inside SportsCar. Any kind of
| inheritance creates giant schemas and adding new types to the
| super type means you have to re-insert the same parameter a
| million times.
|
| Combined with a well-integrated ORM, GraphQL can have serious
| performance improvements over REST and similar so I definitely
| prefer it for big applications, but there are so many things that
| annoy me to no end.
| csnweb wrote:
| I think you may be should give a code first GraphQL a try, you
| can pretty much everything you want that way. You can write
| high level functions for pagination or whatever that way and
| have a base object that you can extend for all Types
| implementing the interface. I really don't know why schema
| first seems to be the default, it's really unflexible.
| BLanen wrote:
| Graphql gets hyped by people who have seriously no idea what the
| hard problems in apis are.
|
| It quite literally solves many easy issues and pretends solve the
| hard ones, but does nothing to actually do this and just says
| that you "can".
|
| I designed a typical JSON api that had customizable fields and
| filters and joins and authorization on orm level on classes(could
| easily be extended to do authorization on fields of the orm
| classes.) This was years before Graphql came along and pretends
| to solve these issues, while actually just leaving them up to the
| implementor of the resolvers. As if the idea itself of resolving
| per fields in so special.
|
| And then you have people that think graphql = the semantic
| web(web3 before crypto shit stole the term). Inventing the same
| cyberpunk dreams from 40 years ago...
|
| Nobody is even actually doing REST, just Rpcs over http with
| json. If they read the REST paper they'd know this is what they
| actually want but I fear it's a pipedream.
| zoover2020 wrote:
| I'm all for piggybacking off of Fielding's work, but HATEOS
| isn't practical and the industry reflects this.
| jongjong wrote:
| Some other bad things:
|
| - Makes caching more challenging since there are now more
| possible permutations of the data depending on what query the
| client uses. A hacker could just spam your server's memory with
| cache entries by crafting many variations of queries.
|
| - Makes access control a lot more complicated, slower and error-
| prone since the query needs to be analyzed in order to determine
| which resources are involved in any specific query in order for
| the server to decide whether to allow or block access to a
| resource. It's not like in REST where the request tells you
| exactly and precisely what resource the client wants to access.
|
| - Adds overhead on the server side. It requires additional
| resources to process a query rather than just fetching resources
| by ID or fetching simple lists of resources. A lot of work may
| need to happen behind the scenes to fulfill a query and GraphQL
| hides this from the developer; this can lead to inefficient
| queries being used. I have a similar complaint about database
| ORMs which generate complex queries behind the scenes; this makes
| it difficult to identify performance issues in the underlying
| queries (since these are often completely hidden from the
| developer). Hiding necessary complexity is not a good idea...
| Maybe worse than adding unnecessary complexity.
| endisneigh wrote:
| > - Makes caching more challenging since there are now more
| possible permutations of the data depending on what query the
| client uses. A hacker could just spam your server's memory with
| cache entries by crafting many variations of queries.
|
| You could use something like https://stellate.co/.
|
| > - Makes access control a lot more complicated, slower and
| error-prone since the query needs to be analyzed in order to
| determine which resources are involved in any specific query in
| order for the server to decide whether to allow or block access
| to a resource.
|
| Hasura and Postgraphile can do this - in the case of
| Postgraphile it obviously requires Postgres.
| the_mitsuhiko wrote:
| If the solution for caching problems turns out to be a hosted
| API proxy then there are still not enough tools available. If
| you put some third party infrastructure in front of your API
| then your availability is exactly that company's
| availability.
| krschultz wrote:
| It shifts the complexity to the server side. The additional
| logic you are describing currently lives on the client, where
| it's harder to update and likely duplicative across platforms.
| dmitryminkovsky wrote:
| Some nits:
|
| > It doesn't support map/tables/dictionaries. This is actually
| huge. I get that there might be
|
| It does. You can define, say, an "any" or "json" type in your
| schema and emit anything you want at a field with such a type.
| For example https://stackoverflow.com/a/63588485
|
| > No clear path for Api versioning
|
| Some options include:
|
| - Prefixes (`/v1/graphql`, `/v2/graphql`)
|
| - Backward compatibility: only adding and not subtracting things
| you want to support.
|
| Lots of fair criticisms though. My two cents:
|
| There are very few cases for starting a GraphQL based project by
| writing a GraphQL server (resolvers, queries, etc). This is where
| devs waste time instead of exploring their concepts. Instead, use
| GraphQL with something like Hasura that generates the GraphQL
| service for you based on database schema.
| Lapsa wrote:
| when I talked about drawbacks of graphql like 3 years ago - I got
| ridiculed. there surely are some nice perks but overall - I find
| the maintenance of that tricky abstraction layer way too
| exhaustive. then there's that (weird) architecture in which all
| the data goes through single focal graphql endpoint. I mean -
| there's already painful client/server division in web world but
| now the server knows near nothing about the client intent.
| criley2 wrote:
| GraphQL has advantages that make it great in certain situations
| but it can be very difficult to wrangle it at large scale and you
| basically need to hire Facebook GraphQL engineers once you get to
| a certain size.
|
| If you are using Typescript on backend and frontend
| (react/reactnative ok, native ios/android app no) then checkout
| tRPC. https://trpc.io/ tRPC is basically: you just call your
| backend functions on your frontend, and TRPC handles the API that
| makes it work. It shares types and when you define a type for
| your backend, and call that function, you get the type on your
| frontend.
|
| Incredible for small apps/teams, but has it's limitations
| (especially before the most recent version) and probably not the
| solution for a big honkin app.
|
| I've been playing with create-t3-app and it's pretty nice, great
| way to launch a basic typescript/trpc/nextjs/prisma app.
| https://github.com/t3-oss/create-t3-app
|
| I use GraphQL at work and it's fine, it's just a lot of code and
| codegen and work for a small team, we'd be faster on tRPC but
| tRPC didn't even exist when this codebase chose graphQL lol
| pikdum wrote:
| PostGraphile works really well for us. We had a lot of issues
| when we were previously trying to wire things together ourselves,
| though.
| noname120 wrote:
| Add the fact that the cache performance is unpredictable and
| inconsistent.
|
| GraphQL queries select specific fields for "performance reasons"
| so each request is custom and you can't cache at the edge. This
| is ridiculous because SQL joins are costly but fetching a few
| extra textual fields is basically never a bottleneck.
|
| So in order to save a few bytes or KBs (which nobody care about
| anyway), you ruin your caching abilities...
|
| ...Well unless you manually cache your GraphQL queries with more
| fields than needed but then what's the point of using GraphQL at
| all?
|
| That's very often a terrible compromise.
| svnpenn wrote:
| > It can save you bandwidth. Get what you ask for and no more
|
| I don't, and never have believed this argument. I would bet that
| JSON with Gzip or Zstd is just as small, or close enough that it
| doesn't matter.
| itsdrewmiller wrote:
| If you have any data sets with an open text field that you
| don't care about, or where you really only need to get the ID
| from a wide table, it will definitely save a ton of bandwidth.
| How often that really matters on the other hand...
| horsawlarway wrote:
| And in this case usually you can easily opt to exclude the
| troublesome field with a param, or an endpoint that returns a
| minimum version of the entity.
| speedgoose wrote:
| A graphql query is usually sent inside a JSON document and a
| graphql response is usually a JSON document sent over HTTP with
| compression. You do have to upload the query but you can select
| only the data you need, and you can also do that in a single
| query compared to a classic almost REST API. That's the part
| that saves bandwidth, sometimes.
| locutous wrote:
| Nothing prevents you from compressing the smaller response of
| what you asked for.
| Kalanos wrote:
| it' a hack substitute for a graphdb
| alerighi wrote:
| To me is not that great either. I find it simpler and more robust
| a well designed REST API, where with well designed I mean that
| the semantic of the methods is respected and it works on
| resources.
|
| The thing is that GraphQL is an RPC mechanism, contrary to REST
| that is a protocol to do CRUD operations on resources, and that
| has all the complexity associated with an RPC itself.
| willjp wrote:
| I think graphql is fantastic, and solves tricky design decisions
| (versioning, precise rest queries). However, I don't believe all
| graphql client libraries are created equally, and I strongly
| prefer those that are simpler, and closer to graphql's own syntax
| (ex. ariadne). This is an opinion though, my preference is
| generally explicit > implicit.
| scottwick wrote:
| GraphQL is nice from a consumer's perspective but results in a
| lot of extra complexity on the backend IMO. It sounds nice in
| theory for the frontend to just request whatever it needs but
| there are often performance considerations that make this easier
| said than done. You end up either tailoring the database queries
| for particular GraphQL queries (i.e. eager loading certain things
| you know will be fetched) or implementing some sort of more
| generic dataloader pattern. The fields and data types become more
| explicit through the schema but there are still implicit access
| patterns in play. Definitely a tradeoff vs. a REST API where each
| endpoint can be highly optimized since you know exactly what's
| being returned.
| mattbillenstein wrote:
| IMHO, it's a better contract with frontend apps than REST, but
| you have to be mindful of the backend implementation and the
| shape of the GQL schema more or less matching your DB schema.
| Guid_NewGuid wrote:
| Hmm, I feel weird reading all this criticism of GQL. It reminds
| me of when our place switched to it and I was constantly slagging
| it off until my friend/colleague said "do you actually hate it or
| you just don't understand it?".
|
| Default hostility to new concepts and frameworks can save a lot
| of time, energy and mistakes in software but sometimes for some
| use cases the new (variation of an old) solution can be superior.
|
| We use it as the API we expose for our React and mobile clients
| and it's just, so good. I'd never want to consume it for a non-FE
| client but it's night and day versus stitching the results of
| multiple API calls together using some godawful chunk of mess
| like Redux.
|
| We have a C# backend and Typescript frontend. We write our
| backend resolvers of the form `public async Task<SomeResultType>
| GetSomeNamedField(TypedParams pq)` and it just works, Apollo
| generates type safe client code and we define the schema in a
| single place. We still write backend code to implement each
| resolver method, exactly how we did in a normal API but... that's
| just the same.
|
| I wonder how bad other backend devx must be for all these people
| to hate it, it seems more like a language specific implementation
| flaw than a genuine problem.
| jddil wrote:
| You haven't actually described any of the unique parts of
| GraphQL though. Generating a typesafe API whose schema is
| defined in a single place is trivial with an OpenApi spec and a
| client generator
|
| What I've noticed is people get their first taste of a type
| safe api and automatic client creation via GraphQL and don't
| understand that exists without it.
| MisterSandman wrote:
| > What I've noticed is people get their first taste of a type
| safe api and automatic client creation via GraphQL and don't
| understand that exists without it.
|
| I mean, yes, you can technically write any project in C if
| you're smart and dedicated enough, but data scientists still
| use Python because it's easier to work with for the things
| they need to do. The fact that GraphQL is _inherently_ safe,
| while REST is inherently not, is why people like GraphQL.
| OpenAPI is hardly the standard in Rest APIs.
| aleclm wrote:
| We recently had to design an HTTP API, and we wanted to have as
| much automatic stuff as possible. I mean:
|
| * Autogenerated documentation
|
| * Autogenerated wrappers for scripting languages
|
| * Autogenerated validator for requests and responses
|
| For a REST API, you can get most of these things with swagger or
| stuff like that, but clearly it's an afterthought. If you have a
| schema, it's all much more natural and elegant.
|
| But the most important thing you get with GraphQL is batching.
| For our use case (a decompilation pipeline) if you make 10
| requests one after the other or 10 requests altogether it makes a
| _huge_ difference in terms of performance.
|
| If you need batching and design a REST API, for every nice
| endpoint you have you need to make a _bulk_ version of the API.
| You 're likely going to do that POST'ing a JSON. Now, once you're
| at that point, you're reinventing the wheel with six sides.
|
| If your backend is in C/C++ and I suggest to make a C API for
| Python and use ariadne:
| https://ariadnegraphql.org/
|
| Don't do GraphQL in C/C++.
| loosescrews wrote:
| > But the most important thing you get with GraphQL is
| batching.
|
| Doesn't HTTP/2 make this mostly obsolete? One of its big
| features is request multiplexing.
|
| Regarding the auto-generated code bit, are auto-generated
| GraphQL clients a thing? It seems like it would be doable, but
| I haven't found any (at least for the languages I'm using).
| kortex wrote:
| I believe by batching they mean operating on collections of
| entities instead of single ones. So you may have POST /pets
| to create a single pet from a json object, but what if you
| want to add a hundred pets at once? Even with multiplexing,
| this is often way less efficient. Often the solution is to
| have POST /pets/bulk which takes a list of objects.
| nogridbag wrote:
| I suppose it depends on the domain, but in all the APIs
| I've created bulk operations are fairly rare. I guess if
| you know upfront that your API would involve heavy bulk
| operations then seeking a tool that makes that more
| performant would be beneficial.
| ant1oz wrote:
| I totally agree, the list of frontend pro is super cool,
| especially the subscribe real time API, but on the backend, it is
| a pure nightmare, either using very cutting edge third parties,
| the authorization is a super big pain in the butt to implement.
| Cool you got a graph, now you need to make sure only user a can
| edit row b, there is the shortest path, but the data storage is
| still centralised.
|
| And I doubt there will ever be any PWA POSSIBLE with graphql, so
| no offline usage, no local storage , nothing cool toward the web6
| decentralised stack.
| lfauve wrote:
| There is: https://rxdb.info/replication-graphql.html
| VoidWhisperer wrote:
| As far as the versioning goes, the prevailing wisdom seems to be
| that it just isn't needed on graphql apis - on graphql.org they
| say the best practice is to avoid breaking changes. [1]
|
| That said, versioning of a graphql api has been done at scale
| before. Shopify has done it, using versioning in the URL,
| specifically their admin data api, using month-year release dates
| as the versions [2]
|
| [1]: https://graphql.org/learn/best-practices/
|
| [2]: https://shopify.dev/api/usage/versioning
| JohnHaugeland wrote:
| > As far as the versioning goes, the prevailing wisdom seems to
| be that it just isn't needed on graphql apis
|
| In reality, of course API versioning is needed.
|
| The "prevailing wisdom" is people who like the tool, don't like
| its limitations, and want to pretend it isn't a problem.
|
| .
|
| > That said, versioning of a graphql api has been done at scale
| before. Shopify has done it
|
| Perl people will happily point out that object systems exist
| for Perl.
|
| Having it not be a standard, uniform part of the core tool is a
| severe limitation. Shopify needed this rudimentary feature, and
| tried to give it away because others need it to, and the tool
| vendors aren't willing (or able) to deliver.
| PUSH_AX wrote:
| > In reality, of course API versioning is needed.
|
| I'd recommend not picking a technology that is versionless by
| design if you think you're going to need it. Also I'd dispute
| that versioning is needed as a rule.
| krschultz wrote:
| FB is pretty much on V1 of its GraphQL API with tens of
| thousands of engineers editing it for over a decade. Every
| single query is its own version, that's the point. If you
| want to change the semantics of a field, make a new field and
| leave the old one for the existing clients. What else would
| you have to version?
| hu3 wrote:
| We're not Facebook
| chrischen wrote:
| Facebook intended it to be used with Relay... so a lot of
| problems can be avoided by using Relay.
| cube2222 wrote:
| Having had experience with it from a "backend for the frontend"
| perspective, GraphQL is nice because it gives you an API for free
| and does partly decouple the frontend team.
|
| At the same time, with most backend GraphQL frameworks the
| decoupling will be very illusory, as in practice you'll have to
| tune the backend to the frontend use cases or you'll just end up
| with a ton of N+1 queries and terrible performance.
|
| In other words, application-specific http endpoints have their
| advantages and let you have fine tuned queries for each use case,
| which makes sense for app-style frontends.
| nip wrote:
| N+1 queries performance in GraphQL is solved problem with
| dataloaders [1]
|
| [1]: https://sixfold.medium.com/reducing-database-queries-to-a-
| mi...
| chpmrc wrote:
| > It is actually a pain to use, depending on the backend you are
| using you'll have to manage two or more type systems if there are
| no code first generates in your language
|
| This is a shortcoming of the language, not of GraphQL.
|
| > It doesn't support map/tables/dictionaries. This is actually
| huge. I get that there might be
|
| If you ever tried to cram a JSON like payload in a GraphQL field
| you'll know why this limitation is in place. It quickly starts
| getting abused by clients and you end up adding validation, which
| you might as well have codified in a properly structured type.
| For blobs you can just send encoded strings (JSON, base64,
| binary, you choose).
|
| > No clear path for Api versioning you'll end up with
| MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
|
| The whole point of using something like GraphQL is that you don't
| need or even want versioning. You can still deprecate fields (and
| remove them according to your deprecation policy) but in general
| you can just keep adding fields/types without removing the old
| ones until you are sure consumers don't need them any more. So
| there's no breaking change and consumers can transition to the
| new fields whenever they want. Something else you start
| appreciating when you have multiple, heterogeneous consumers of
| your API.
|
| Or you can just add the version to your schema URL, e.g.
| `/graphql/v1/` and then route your queries based on that, which
| kind of defeats the purpose.
|
| > Invest your time in a simpler solution then running to GraphQL
| first
|
| GraphQL is as simple to set up as anything else, assuming the
| language has good support for it. If it doesn't that's, again, a
| limitation of the language, not of GraphQL.
|
| GraphQL solves _a ton_ of problems related to typical JSON APIs '
| conventions, since JSON isn't inherently "schemable" unless you
| generate something like an OpenAPI spec which is, arguably, more
| complicated. There might be superior alternatives (I've never
| tried JSON schema) but I think all the pain points you described
| can be easily solved one way or another.
| Justsignedup wrote:
| Personally I've used JSONApi
|
| Pros:
|
| - front-end implementation is near-trivial. I re-wrote half of my
| framework because I wasn't happy with it in a few days.
|
| - can use some cookbooks for some good front-end patterns
|
| - overall very easy to use, and very easy to extend front-end
| stuff
|
| Cons:
|
| - Poor back-end implementations. JSONApi Resources kinda sucks.
| Graphiti might be significantly better.
|
| - No clear pattern for submission of data. You don't want your
| front-end to contain operational logic, dumb front-ends are the
| way to go (front-ends do what they are told, they don't make
| decisions).
|
| - Not the "IT" thing, so not too much big corporate money backing
| it. :( This is actually kind of a big deal.
| krschultz wrote:
| - It shifts the complexity where it belongs - out of native apps
| deployed to user's phones and onto the backend that you control.
| It doesn't eliminate any complexity.
|
| - There's really no need for API versioning in GraphQL. Just keep
| iterating on the fields.
| oznog wrote:
| It's another postmodern web development fuck-up.
|
| I saw it coming for miles and evaded it.
|
| Your complexity is my competitive advantage. Please continue to
| be followers of any new shit.
| OmarIsmail wrote:
| Yes, graphql does indeed suck. Or rather it is not the best
| solution for all client-server communication that people treat it
| as, so it ends up being used in a lot of situations where it does
| suck.
|
| Backend to backend communication is almost never graphql (is that
| changing in a big way?) which would indicate the main reason for
| graphql in a client-server situation is data saving but at the
| cost of complexity and other downsides. Almost certainly the data
| savings in many cases is not worth it.
|
| Oh and then you have things like Apollo having cache bugs that
| result in incident level problems.
| eurasiantiger wrote:
| Does Apollo really have cache bugs? Usually it's the data
| itself which doesn't have a unique id field, or the client
| hasn't been configured to know about the proper id field.
|
| Granted, it's a problem to have to do that. But such is life
| with entity-level caching.
| jddil wrote:
| I'm glad the tide seems to be turning against GraphQL.
|
| Your company is not Facebook, you don't have an impossibly large
| graph dataset that needs querying
|
| I've used it 3 times, each time it was a nightmare. REST with
| some additional params to query extra data is so much easier and
| safer ... that's just not very cool I guess.
| scottwick wrote:
| A frontend application that I work on has each component making
| separate tiny GraphQL queries to render just what it needs. The
| result is often 5-10+ GraphQL requests to render a single page.
| Is this a common practice?
|
| It seems like a lot of overhead to me since the backend has to
| perform some redundant queries (i.e. fetch and authorize the
| user, etc.) in order to serve each of those requests. I had
| thought one of the main selling points of GraphQL was that the
| frontend could make a single API request and have everything it
| needs to render the entire page. Any thoughts?
| wes-k wrote:
| Use Apollo, it can stitch all those queries together into one
| deduped query. It's awesome!
| mabbo wrote:
| Whether it was the intention or not, I find GraphQL solved a
| fascinating problem: it let front end developers move faster by
| greatly decoupling their data needs from the backend developers.
|
| Backend developers describe the data model, expose it via
| graphql. Front end developers, often ones who never met those
| backend developers, can see the data model and just use it. They
| can change what they're querying on the fly, get more or less as
| they see fit.
|
| It lets everyone move faster.
|
| But as a backend developer, I actually fucking hate it, myself.
| grumple wrote:
| Curious as to why you hate it specifically. Because what you
| could be doing is exposing every table / field automatically
| based on permissions (which you could set up a system where you
| don't even have to be involved).
| mabbo wrote:
| Honestly it's mostly just lack of familiarity, which is
| getting better every day.
| toolz wrote:
| because either the boilerplate is massive or the libraries do
| so much for you that you have to specialize in understanding
| the libraries magic - front-end plus back-end code for
| graphql is almost always more than a traditional REST api and
| I mean a lot more code, not just a bit more, so more code is
| strongly correlated with more problems. The exception is when
| you use heavy libraries that have magical APIs. Then you end
| up with teams who understand the API and have no idea how
| graphql actually works, which is probably an even worse
| problem.
| mattbillenstein wrote:
| What tooling are you using that requires a massive amount
| of extra code? You need to define the schema and write
| resolvers, but that's sorta similar to what you might do in
| REST on the backend.
|
| On the frontend, you have a choice to use some of the
| heavier libraries that support all of the features (like
| subscriptions) - but otherwise, you can just POST a gql
| query to the server and it will return a blob of json,
| which really isn't so much more than REST.
| syastrov wrote:
| e.g. postgraphile
| NonNefarious wrote:
| I thought it was supposed to do this, but then discovered that
| it has no way to express joins.
|
| Has this been addressed? I don't see how you can decouple the
| back-end data from front-end queries without that.
| vikR0001 wrote:
| You can do something like this. This query can be created and
| run on the client:
|
| ``` const SAMPLE_JOIN_QUERY = gql` query ($main_data_id:
| String!) { mainData( main_data_id: $main_data_id) { id
| main_data_field_1 main_data_field_2 main_data_field_3
| related_data{ related_data_field_1 related_data_field_2
| related_data_field_3 } } } `; ```
| mdaniel wrote:
| https://news.ycombinator.com/formatdoc may interest you
| const SAMPLE_JOIN_QUERY = gql` query
| ($main_data_id: String!) { mainData(
| main_data_id: $main_data_id) { id
| main_data_field_1 main_data_field_2 main_data_field_3
| related_data { related_data_field_1
| related_data_field_2 related_data_field_3 }
| } }`;
| NonNefarious wrote:
| Thanks!
| platz wrote:
| in other words, it's up to the folks writing the resolvers
| to manifest and implement that join as a nested field.
| zoover2020 wrote:
| Dataloader does this IIRC
| mst wrote:
| Which means a lot of the time they end up just caching as
| hard as they can and hoping that's good enough.
|
| (which is often, honestly, an entirely rational decision
| in terms of prioritising limited resources, but still
| makes me sad)
| breckenedge wrote:
| I get specialization, but are there any other good reasons to
| divide product teams between frontend and backend? I guess it
| also helps establish patterns and contracts, but I think those
| are only helpful above a critical mass that I haven't reached
| in my career yet.
| dasil003 wrote:
| The reason is to scale teams. It's not the only way to do it
| --you can also have vertical teams--but it's a common one
| because frontend and backend have different technical
| considerations. The downside is the product can lose cohesion
| as developers get tunnel vision. Of course all big teams
| suffer from a version of that problem depending how the lines
| are drawn.
| endisneigh wrote:
| In a small organization there isn't generally any reason to
| divide the teams between front and back end. As you've
| alluded - once you have many clients you'll want to separate
| responsibilities in order to increase velocity.
| withinboredom wrote:
| This is something I've wondered as well. Coming from the
| military and occasionally working with spec-ops, I would say
| having a few "full stack" teams would be the way to go. I am
| just a lowly dev though, so what do I know?
|
| The separation of front/backend has always been mildly
| entertaining to me and I've worked on both teams. Btw, if you
| ever want to cause a political mess, just submit a PR to add
| a new API endpoint to the backend team that "doesn't have the
| time" to work on it. Woah boy, they will get mighty pissed.
| As a backend engineer these days, it would be a blessing to
| get free work from another team... I don't know why they were
| so pissed that one time.
| [deleted]
| TheAceOfHearts wrote:
| It depends on the kind of application and scale. Consider a
| large and complex application like Discord or Figma. Past a
| certain point, it's hard for anyone to know how every single
| detail works.
|
| You should probably be comfortable enough to work with both
| ends of the spectrum, but specialization allows you to do a
| much deeper dive into complex subjects.
|
| A backend engineer probably has a much deeper understanding
| of every little nuance of their prefered database. A great
| backend engineer can make sure that you're getting near-
| optimal performance from every important query.
|
| A frontend engineer probably knows about various UX
| techniques along with how to avoid unecessary reflows and
| repaints. A great frontend engineer can implement a UI
| toolkit as well as advanced techniques such as windowing.
| breckenedge wrote:
| Right, that's specialization. IMO those people still belong
| on the same feature implementation team for most
| organizations out there.
| TedDoesntTalk wrote:
| > good reasons to divide product teams between frontend and
| backend?
|
| People specialize in different things. A great React
| developer may not be a great Java developer, and vice-versa
| satyrnein wrote:
| From a management perspective, the fiction of the full stack
| developer that is equally skilled at everything is the
| easiest. You stick with that until you complicate your
| architecture (wisely or not) to the point where having
| specialists outweighs having to manage multiples queues of
| work and dependencies.
| ant1oz wrote:
| Worse approach imo.
|
| Nowadays a full stack dev is an intermediate Fe dev, with
| junior backend skills. He will make your backend un-
| maintainable. Get a proper master on a proper contract rate
| to design your architecture.
| [deleted]
| adra wrote:
| Frontend teams are often feature partitioned at least in
| larger orgs. There will need to be some level of feature
| level backend knowledge to be had somewhere, but backend
| problems are often feature agnostic. Many companies conflate
| backend with platform, which have subtle differences, but end
| up working with similar results. Specialized backend teams
| work to develop a really good "platform" feature while
| frontend teams focus on developing customer/product oriented
| features.
| pragmatic wrote:
| I think you are saying why not combine specialists on one
| team vs the "everyone is fullstack+devops" amateur hour
| dystopia that is becoming all too common?
| breckenedge wrote:
| I think we're all amateurs at some part of the stack. I am
| not the CircleCI dude in my current gig, some other
| competent engineer is, but I've been the Jenkins dude in
| the past because I cared about it the most.
| ipaddr wrote:
| Back in the day we call this role Webmaster. Being able to
| manage your server, write your code and design the website
| was what a true developer tried to achieve.
|
| It is strange to see developers preferring to stay in their
| isolated environments and not wanting to touch the entire
| stack.
| electrondood wrote:
| This actually made sense back in the day. Now there's
| significantly more complexity for each part of the stack,
| tooling, distributed design patterns for scaling, etc. We
| don't really have "websites" any more, for example. We
| have apps that run in the browser.
| moonchrome wrote:
| It's not strange at all - it takes months of work to get
| productive with _insert whatever tech stack here_ even
| when it 's within your experience domain. Problem domains
| are really separate. Toolchains and languages are
| different. It's already hard to find people competent on
| one stack/field - hoping to find a team of competent
| "full-stack", in the broadest sense of the word, is
| probably prohibitively expensive.
| mattbillenstein wrote:
| Why do you hate it? What tooling are you using? I found it
| fairly painless in Python - Graphene/Flask.
| matsemann wrote:
| If all you do is expose simple models, it's fine. But then
| not much different than an auto-generated REST-api. But if
| you want to query deep, list of childrens etc you quickly get
| into queries that are very hard to write on the backend (n+1
| issues quickly pop up etc). To solve those you need to write
| complicated loaders, which all should be very general in
| nature and thus you can't rely on two fields backed by the
| same data sharing a query without doing something special.
| Which is much more hassle than just writing whatever join you
| want for a tailored endpoint.
| quickthrower2 wrote:
| It sounds like it is promoting a siloed cogs in the machine
| type of work ethic. Where you are either front end or back end
| and no one is thinking end-to-end about the system.
| adra wrote:
| Sr enough developers who's role expands beyond a single team,
| architects, product managers, product owners, the list goes
| on for the roles of people who are often task of thinking big
| picture about the health and "end-to-end" picture of any
| given software project. Your narrow synicism makes me assume
| you don't work in a company that has a large dev org. People
| specialize and if you want to be the learn and do everything
| person, you'll find that you're doing less and learning more
| which isn't a good fit for most orgs.
| satyrnein wrote:
| I think the causality runs the other way. Once the frontend
| had gotten so complex that it required a specialized team,
| solutions arose to reduce the back and forth necessary
| between frontend and backend teams.
| locutous wrote:
| That's generally true for sizable companies. Small companies
| can and do use full stack devs.
|
| Segmentation makes some sense but the industry is lacking end
| to end thinking as you point out.
| jayd16 wrote:
| To me it's a weird way to go about this decoupling. Another way
| is you can just keep your own view-model client side and
| abstract the backend data with that.
|
| FFBs and GraphQL is a way to tightly couple to a backend system
| and then have that backend system loosely coupled.
|
| I guess its all 6 of one, half-dozen of the other, but I
| usually prefer to just handle things client side. You can maybe
| get less data transfer optimization but that's down the road
| from the fast development stage, anyway.
| andrewingram wrote:
| _Context: I do front-end and back-end, so I'm usually the one who
| ends up maintaining the GraphQL server_.
|
| The vast majority of people who've used GraphQL haven't used it
| with something like Relay; and in my mind that means they haven't
| used GraphQL in a way that really shows off its strengths. This
| isn't to say that GraphQL doesn't have any benefits without
| Relay, but rather that the cost/benefit scale only really tip
| heavily towards benefits if you're using it to solve the problems
| it was intended to solve -- that of reliably getting a
| component's data dependencies into the component.
|
| Every time I use GraphQL without Relay I find myself questioning
| whether it's adding anything except complexity, every time I use
| Relay (other than the initial architecture build, on-ramp is
| steep) it feels great. Relay's learning curve and poor
| documentation is really unfortunate, because the difference is
| quite pronounced.
| spankalee wrote:
| Among the many problems with GraphQL are
|
| 1) That it doesn't deal in graphs, but trees, and 2) It's not a
| query language, but an RPC language with result subsetting
|
| I would love to see something similar to GraphQL that could
| return actual graphs. Like in the canonical Books/Authors
| example, a query over books that included the authors would
| return Books with _references_ into an Authors collection so that
| authors were not duplicated as children of the books.
|
| I would also love to see real and standard query operations like
| where, limit, groupby, and ideally some sort of cursor. All that
| has to be added bespoke on top of GraphQL severely limiting the
| ability to write generic frontends and interfaces against GraphQL
| APIs.
|
| Then there's the type-system problems like lack of Maps, the
| overly strict input/output separation, paltry scalar types with
| no standard for dates and times, etc...
| nkozyra wrote:
| > 1) That it doesn't deal in graphs, but trees, and 2) It's not
| a query language, but an RPC language with result subsetting
|
| I'll resist pedantry on point one but I totally agree on point
| 2. Plus its syntax poorly reflects the data 'schema' it's
| defining.
| replygirl wrote:
| > It is actually a pain to use, depending on the backend you are
| using you'll have to manage two or more type systems if there are
| no code first generates in your language
|
| hasn't been a problem for years in the ts, python, and .net
| communities
|
| > It doesn't support map/tables/dictionaries. This is actually
| huge. I get that there might be some pattern where you don't want
| to allow this but for the majority of situations working with
| json api's you'll end up with a {[key: string] : T} somewhere
|
| unions, embedded types, and custom resolvers, OR better api
| design
|
| > No clear path for Api versioning you'll end up with
| MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
|
| this one is actually insane. /api/v1/graphql. sounds like you are
| new to apis
|
| ---
|
| all of the complaints i hear about graphql have come from people
| who are early in the process of learning it and/or have built up
| faulty assumptions through malpractice
| valenterry wrote:
| > > It doesn't support map/tables/dictionaries. This is
| actually huge. I get that there might be some pattern where you
| don't want to allow this but for the majority of situations
| working with json api's you'll end up with a {[key: string] :
| T} somewhere
|
| > unions
|
| Then you need to know the keys in advance
|
| > embedded types, and custom resolvers
|
| That is "kind of" cheating. I think OP meant a builtin type.
|
| > OR better api design
|
| Sometimes possible but not always.
|
| It's a valid criticism. Emulating another http endpoint in
| graphql should be super simpel in the best case, but sometimes
| it is not.
|
| Another example where that is true is union inputs - you can
| define and return a union of types, but you cannot accept the
| exact same union in a mutation. Very very unfortunate.
| FpUser wrote:
| All my backend servers expose JSON based RPC api. It does exactly
| what was intended. No more no less. Works like a charm. I can
| hardly imagine why would I want to invest in developing /
| exposing GraphQL layer. Facebook might have their valid reasons
| but businesses/clients I deal with are not FB scale and do not
| really give a flying fuck about what FB does. They just need to
| solve their own particular problems with good ROI.
| rglover wrote:
| Having spent several years working with GraphQL (using it in
| multiple projects and teaching it to others), I've found that in
| the majority of cases just doing a plain JSON-RPC API is
| preferable and far easier to reason about for all skill levels.
|
| When I built Joystick [1], this is why I implemented the API
| system [2] as a JSON-RPC model, but stole the idea of validating
| inputs (optionally) and then on the client, optionally specifying
| tailored output (also optional--like how you can request specific
| fields back in GraphQL but instead of a custom query language,
| just pass an array of paths like
| ['customers.creditCard.expirationMonth',
| 'customers.creditCard.expirationYear'] for the specific data you
| want returned).
|
| What I learned implementing that is that the typing/querying for
| specific fields ideas is brilliant, but much better when it's
| flexible (i.e., I want it sometimes but not _all_ the time).
|
| [1] https://github.com/cheatcode/joystick
|
| [2] https://github.com/cheatcode/joystick#api-1
| stutsmansoft wrote:
| I also had a bad experience with graphQL, or perhaps more
| accurately the Apollo client for it.
|
| I hated the namespaces on the code-generated classes and ended up
| manually wrapping them, obviating the benefit.
|
| It was also super brittle, when the back end would change
| something it would break the clients.
| lofatdairy wrote:
| From what I've read GraphQL makes the most sense in the context
| of large scale teams and large databases. It introduces a large
| amount of overhead to your backend to parse queries, but allows
| those queries to be more flexible and not think about the
| database's schema which is a tremendous boon when you get to the
| scale where communication between teams is more expensive than
| implementation time. For junior and midlevel devs watching
| youtubes and reading blogs it's obviously an exciting technology
| because of what it promises (in this sense GraphQL is hardly
| unique), but there's a practical cost to production workloads.
|
| That said, if I'm not mistaken GraphQL is almost explicitly
| designed with a versionless paradigm in mind. Whether or not
| that's a good decision is up for debate, but it's less "no clear
| path" and more like it's the responsibility of the backend to add
| support for new access patterns without causing old patterns to
| fail.
| NegativeLatency wrote:
| Some libraries offer enterprise features for versioning.
|
| Like you said it makes sense in larger companies. As a consumer
| of a well documented API it's great, as someone who had to
| stitch together 2 microservices to provide the required data it
| sucks.
| jwr wrote:
| "Very Senior Dev" here (though it amuses me to call myself that).
| I had managed to avoid GraphQL for a while, but recently had to
| actually look at it and use it. I was appalled that in this day
| and age, this hyped silver bullet basically requires me to build
| queries using strings.
|
| I was honestly surprised by this: when I first heard about the
| idea behind GraphQL, I was certain that I'd pass in nested data
| structures.
|
| I use it because I have to (external services jumped on the hype
| bandwagon), but I don't consider it significant progress. And
| this "save bandwidth" advantage is totally oversold, I really
| can't see how the savings can be significant in a practical way.
| chpmrc wrote:
| > I was appalled that in this day and age, this hyped silver
| bullet basically requires me to build queries using strings.
|
| That's like saying SQL is crap because you need to build
| queries by hand. Conflating a protocol/spec with its
| implementation and/or the way it's used is not something a
| "very senior dev" should do (not questioning you personally,
| just the validity of what you wrote in this specific comment).
|
| There are plenty of good GraphQL libraries that make writing
| queries/mutations and the whole schema a breeze. I've been
| using graphene for Python for a couple of years and, although
| it has some rough edges, it's actually pretty decent. And
| GraphQL is quite a good mental model to work with that both
| backend and frontend can share.
|
| <rant>Honestly I'm getting tired of seeing these comments on
| HN, it's the same for Kubernetes or other technologies. Often
| written by someone who didn't take the time to actually _study_
| and understand the tech and use it for actual projects. Often
| with no data to back it up whatsoever. The quality of posts and
| comments here used to be a lot higher but it 's slowly turning
| into a plaintext version of dev.to </rant>
| spion wrote:
| The GP is right. GraphQL is especially annoying because it
| looks so close to JS/JSON, yet since no thought was put into
| how it might integrate into existing typed languages its
| actually surprisingly difficult to build a type-safe API
| around it.
|
| And yes, SQL is "bad" because you write query strings. The
| funny bit is that GraphQL may be just as hard to model in a
| type-safe way as SQL is, if not a little harder. At least
| with SQL we have a reasonably good way to model it with
| methods (see LINQ). LINQ was built 15 years ago, so this
| problem was well understood back then.
| chpmrc wrote:
| > yet since no thought was put into how it might integrate
| into existing typed languages [...]
|
| Says who?
|
| > [...] its actually surprisingly difficult to build a
| type-safe API around it.
|
| Again, says who? The consumers of the APIs I work on are
| mostly written in Typescript and constructing types based
| on the GraphQL schema is a completely automated process.
| Are you telling me that it's easier to build type safe APIs
| based on examples of what JSON each endpoint might output?
|
| > And yes, SQL is "bad" because you write query strings
|
| Ok then every single language is bad because every
| language's syntax is based on (conceptually) constructing
| strings. I don't get your point.
| spion wrote:
| > Says who?
|
| Says me, and also any other person that has tried to
| build a type-safe GraphQL query builder
|
| > Consumers of the APIs I work on are mostly written in
| Typescript and constructing types based on the GraphQL
| schema is a completely automated process
|
| Constructing "types" of what kind, and in what way? Types
| for queries? Do you need to rerun the tool every time you
| modify any of your queries? Does it need to watch your
| query strings to generate the right types for them?
|
| > Ok then every single language is bad because every
| language's syntax is based on (conceptually) constructing
| strings. I don't get your point.
|
| Instead of arguing, why not look at what LINQ does?
|
| For the best experience, you should probably try them
| with an editor/compiler: https://github.com/dotnet/try-
| samples#basics
| valenterry wrote:
| It would be helpful if you actually explain how LINQ does
| it better.
| spion wrote:
| LINQ lets you write SQL queries using the language. This
| means you get to take full advantage of the language (and
| language service) features, including the typechecker,
| code completion etc.
|
| Examples: https://www.c-sharpcorner.com/article/writing-
| complex-querie...
|
| The hard bit here is making sure the language type-
| checker is fully aware of the involved types, both while
| writing the query as well as while selecting the results
| to be returned
|
| This approach has since been copied in more capable
| languages. One of my favorite examples lately is Rust's
| Diesel: https://diesel.rs/ (see the "complex queries")
| example.
|
| A query language designer aware of the above lessons
| learned with SQL might take special care to ensure their
| new query language is easier to model in existing
| languages. For example, they might consider an
| alternative OOP or FP based syntax, or to generalize they
| might put some thought into what would make it easy to
| write a type-safe query builder. After all, while SQL was
| developed in 197x and we had a different model for data
| access early on (stored procedures instead of flexible
| language-integrated queries) TypeScript already did exist
| when GraphQL first appeared in 2015.
|
| Yet, we still went the stored procedures route. Tools
| such as graphql-codegen [1] require you to regenerate
| your types every time you edit your query strings
|
| [1]: https://www.graphql-code-generator.com/
| jwr wrote:
| > That's like saying SQL is crap because you need to build
| queries by hand
|
| If we want to use these terms, then SQL is indeed crap,
| because you need put query parameters in-band instead of out-
| of-band. This led to numerous exploits over the years, as
| it's difficult to ensure the data is correctly escaped.
| GraphQL just repeated the same mistakes.
| chpmrc wrote:
| Calling SQL crap just because there's a way to abuse it is
| like saying C is crap because I could do `int * userGuess =
| get_number_from_user(); * userGuess;` with nothing more
| than a compiler warning (if I'm lucky).
|
| Would be nice if we all stopped with these blanket
| statements and just focused on evaluating individual
| pros/cons of things.
|
| EDIT: formatting of pointer
| zokier wrote:
| https://graphql.org/learn/queries/#variables ?
| endisneigh wrote:
| Yeah, if you use something like Postgres and Hasura for a new
| project it's pretty simple. I doubt you could make a REST API
| much easier. Django + Django Admin is close, but that's not
| really an equivalent per se.
| oznog wrote:
| > The quality of posts and comments here used to be a lot
| higher but it's slowly turning into a [..]
|
| You can go on with your GraphQL, Kubernetes, gigantic
| frameworks, and pages with 3MB of JS if you want.
|
| And let's see what stands the test of time.
| chpmrc wrote:
| Well, GraphQL aside I've been using the same stack for
| almost ten years and it's only becoming more and more
| popular so I'd say I'm doing pretty well in terms of
| choosing the tech, thanks for your concern though!
| spion wrote:
| Agreed. I'm working on a typed query builder for GraphQL and TS
| but secretly I'm a little mad that nobody gave some thought to
| making it easier to integrate in a type-safe way at least in
| the client languages
|
| https://github.com/typed-graphql-builder/typed-graphql-build...
|
| No docs yet, that's WIP
| eurasiantiger wrote:
| It looks like a lot more boilerplate than normal GraphQL
| queries.
| spion wrote:
| Not sure what you mean, I added the expected resulting
| GraphQL queries and they're about the same size. They
| aren't really normal queries, because I'm trying to
| exercise all of the features at once in the tests :)
| eurasiantiger wrote:
| Hmm, there's really nothing preventing you from writing a
| library which allows you to pass a data skeleton to an async
| function and get a full body back.
| [deleted]
| sonthonax wrote:
| GraphQL seems to be one of those 'bootcamp technologies'. I see
| it being advertised as a skill a bootcamp teaches more than I've
| ever seen used. I can imagine that for a junior developer the
| endless freedom might be quite paralysising.
|
| What I don't understand about GraphQL, is that the majority of
| data people deal with is simple and relational. It's rare enough
| to have a deep (more than 4 layers) relational data structure
| that needs to be queried at once. And usually those data
| structures are relational to ever smaller relations; think
| user->company->address->country->county. Solving this with
| GraphQL just seems a bit bizarre when you can write a view of
| this data.
|
| Maybe though, it owes its popularity in bootcamps because it
| allows unqualified developer to forget about writing the query
| layer.
| sibeliuss wrote:
| With GraphQL you are making a view of your data. You're using
| types to describe an idealized API response. It's a frontend
| and it can do anything you want.
| jahewson wrote:
| You're right! You don't understand GraphQL.
| pharmakom wrote:
| GraphQL let's you write optimisations once that apply across all
| you queries which is a huge advantage.
|
| I think we can do better than GraphQL but until that solution
| arrives and achieves wide adoption I will keep using it
| InvOfSmallC wrote:
| I admit I never seen a use case that justify the complexity of
| usage. Let's say you have a native app and a web app. I don't see
| these 2 changing that much in terms of data so a an API
| middlelayer is just simpler.
|
| At work we have a use case like: well we create the data layer
| that you can query the way you want and the field you want with
| many clients involved. So like an API where you can make
| composable queries.
|
| To me that sounds like an API with query parameters, do we really
| need to use GraphQL?
|
| Let's see!
| nrb wrote:
| > To me that sounds like an API with query parameters, do we
| really need to use GraphQL?
|
| Do you care about the API being discoverable and the schema
| being well described? Being able to see the relationships
| between the data? The type-safety that comes from the tooling?
| The ability to expose the field once on an entity that allows
| consumers to use it in any variety of queries?
| Kamq wrote:
| > I admit I never seen a use case that justify the complexity
| of usage. Let's say you have a native app and a web app. I
| don't see these 2 changing that much in terms of data so a an
| API middlelayer is just simpler.
|
| It has some benefits when you have multiple different products
| that need different "pieces" of the data, rather than 2
| different clients for the same product.
|
| I never quite understood how much hype it got, but it provides
| some nice benefits in an internal corporate environment,
| especially when data within said environment has an "owner" and
| accessing it from a new place requires an entire process.
| bdlowery wrote:
| Yeah... but Shopify forces me to use it when accessing their
| storefront api.
| Eric_WVGG wrote:
| The syntax of GraphQL drives me utterly mad.
|
| I feel like there's two approaches that one could take to
| approach queries: a series of programming commands (the way most
| ORMs work), or an attempt at "plain language" (SQL and GraphQL).
|
| Both approaches are fine, but if one wanted to take the latter
| approach... why not just use the syntax of SQL? It's better in
| every conceivable way that GraphQL, equally legible but much more
| powerful.
|
| GraphQL is idiot baby talk, I'm baffled by why we have to waste
| time dumbing down expressions for no clear payoff.
| valenterry wrote:
| Yes and no.
|
| SQL also sucks, since you have to SELECT before defining FROM.
| Which means, code completion isn't there for SELECT. At least
| with graphql you get full code completion all the time. I agree
| though that it lacks in other areas. Choice between pest and
| colera.
| zelphirkalt wrote:
| Do not forget, that GraphQL also cannot get you arbitrarily
| nested structure, if the client doesn't know the structure ahead
| of time. Its strength of defining of the structure you want
| returned, also becomes its weakness. If there is some tree
| structure you want to query, you will need to work around it.
| This has been discussed at length on github issues and there is
| unwillingness to change this. Who knows what kind of refactoring
| would be required for that to work.
|
| However, I think GraphQL vs REST is a false dichotomy. One could
| probably maintain a GraphQL endpoint as well as a REST API, and
| use whatever is most appropriate for the use case of the client.
| People really should stop treating GraphQL as some kind of
| complete replacement for a REST API or "the new way of doing
| things" or acting like "the days of REST APIs are counted".
| valenterry wrote:
| Yes, this is a very important point.
|
| One more very annoying shortcoming is that you can define a
| union of types and return them when queried, but you cannot
| write a mutation and ask the client to send the exact same
| union. You'll have to create different standalone mutations.
|
| In general the typesystem is quite lacking. But then again,
| it's better than pretty much everything else language-agnostic
| out there.
| vikR0001 wrote:
| When you say it doesn't support tables, can you provide more
| info? GraphQL can return lists of course.
| phendrenad2 wrote:
| I also refuse to use GraphQL (after seeing it fail utterly and
| spectacularly in a high-profile project that chose GraphQL
| because it was the "new shiny"). But I'm sure it has some niche
| that it works for. After all, people are still using it in 2022.
| jasonhansel wrote:
| IMHO the biggest issue with GraphQL is that it's often used in a
| way that effectively breaks encapsulation. When you use GraphQL,
| it's hard to limit the API surface of a service to avoid exposing
| implementation details. This means it's difficult to modify the
| internals of a service without breaking its clients, and it can
| make things like testing and versioning more of a challenge.
| hamandcheese wrote:
| On the point of maps, I have had success solving this in two
| different ways.
|
| Option 1: return a property list. In other words, a list of
| objects that have a key and a value. It's easy write a getter
| function to search by key, or convert it to a map outright.
|
| Option 2: make a Json custom "scalar", send back whatever dynamic
| structure you want.
| throwawaymaths wrote:
| I'm currently dealing with an openapi schema that declares a
| graphql query route. The mutations are still in rest (but it's
| only one endpoint -- You kind of use it like graphql). The
| graphql output is nonstandard so the reflection tools don't work.
|
| The "cool" features of graphql (treating your data like a graph,
| so you that n+1 queries are not the consumer's issue to deal
| with) are not at all available, I sti have to manually do joins.
|
| I am terrified that since graphql is all "you don't have to
| version your shit" there will be a breaking API change in the
| future that I (or worse, someone not me) will have to watch out
| for, so on that day our supply chain database will be horribly
| broken.
|
| What the hell happened that we got APIs like this?
| philliphaydon wrote:
| > It can save you bandwidth. Get what you ask for and no more
|
| I feel like this a false truth.
|
| Most people are building a web app, or a mobile app and consuming
| an api and displaying all the data they retrieve.
|
| If you have an rest api which returns an object with 6
| properties. And a graphQl scheme which returns those same 6
| properties. You're not saving anything.
|
| Now if you have a website and a mobile app, where the mobile app
| needs 3 fields and the website needs 6 fields. You will obviously
| save on bandwidth with the mobile app.
|
| The problem here is most of us are not building Facebook. The
| data saved is peanuts and the bandwidth cost is probably going to
| be far less than the total cost of doing the work to support
| graphql.
|
| For a company like Facebook which has many different integrations
| as well as 3rd parties integrating, graphql is obviously a
| godsend as integrators and integrations can consume only what
| they require and save Facebook millions of dollars in bandwidth.
| krschultz wrote:
| Every company I've worked for in the last 10 years had multiple
| apps across several platforms, each with many versions, all
| running in production at once. Even if you only care about the
| next version you are shipping and a handful in production
| that's a dozen variations.
|
| In a REST paradigm you over fetch because not all of these
| variations need the same data, or you send less but then the
| clients thicker because they merge API calls and have divergent
| presentation logic, or you have a bajillion API versions.
|
| There's often a lot of back and forth between the various teams
| for each rev of the API.
|
| GraphQL lets the clients drive the definition of the data
| fetching. That's it.
|
| 95% of the criticism of GraphQL is people complaining that
| GraphQL doesn't solve the problem of preparing the API response
| for these different requests. While that's true, that's not
| what it's supposed to provide. Whether you have a REST API with
| 26 versions or a GraphQL API with 26 variations of query you're
| going to have to write a backend-for-frontend style service
| that resolves the results.
|
| GraphQL just standardizes this process.
| chronofar wrote:
| > 95% of the criticism of GraphQL is people complaining that
| GraphQL doesn't solve the problem of preparing the API
| response for these different requests.
|
| This problem is solved by quite a few GraphQL providers
| nowadays. Hasura, DGraph (not true graphql but close enough),
| Prisma. I like Hasura quite a lot for many projects. Just
| define your database and you instantly have a full GQL API
| for the clients to use however they please, no backend
| required really. Doesn't work for everything, but it's pretty
| great for a wide swath of projects.
| grumple wrote:
| > If you have an rest api which returns an object with 6
| properties. And a graphQl scheme which returns those same 6
| properties. You're not saving anything.
|
| You aren't thinking big enough. We have a graphql API where we
| have a bunch of enterprise users all wanting to pull out
| different types of data. They can decide what they want to get,
| and pull exactly that data. They want access to different
| tables, fields, and for different purposes and with different
| filters. We don't have to be involved, we just give them the
| schema.
| vsareto wrote:
| I guess it works, but it still seems like an extra step
| compared to giving them DB access unless they're in some
| weird place where they can learn to use GraphQL but not
| Sql/NoSql
| philliphaydon wrote:
| > We have a graphql API where we have a bunch of enterprise
| users all wanting to pull out different types of data.
|
| That's a great use for graphql. My issue is toooo many people
| are building web apps with graphql where they are the only
| consumer. They are not getting any of the benefits of
| graphql, especially bandwidth savings.
|
| If you have many people integrating and you in vision the
| types of integrations needing very different queries for data
| then graphql is great.
|
| But most companies are a website, maybe some mobile stuff,
| and not enough traffic to warrant the complexity or benefits
| of graphql.
| gorjusborg wrote:
| GraphQL isn't a panacea. It has strengths and weaknesses.
|
| This is true of any technology, so if you think the tech you are
| using doesn't require a trade-off of some sort, you are likely
| missing something.
|
| I've yet to select GraphQL over straight RESTful APIs, but I also
| don't work in an ecosystem where disparate client needs are
| important.
| pharmakom wrote:
| I like GraphQL because it allows me to expose the data once and
| then let front end devs run with it. It's a bit of work upfront
| but it's less work over time.
| didip wrote:
| graphql sucks ass for backend and infra people, the people who
| need to scale it.
|
| It also doesn't speak normal REST dialect so you are missing out
| on basic things like status 200.
| yetanotherloser wrote:
| Always sad at wasted effort but something here feels odd to me.
| Use graph technologies if you genuinely have a graph problem; use
| graph technologies if you have an "almost tree but..." problem;
| don't use graph technologies if you have a strict tree problem or
| a table problem. This all feels like a meta- version of "social
| pressure pushed me to use the wrong conceptual model". All the
| cool kids were doing it...
|
| That said, graphs are dangerous because they are so flexible; you
| can draw a tree or a table in one and it all seems fine but
| you're paying all the time in conceptual load and friction.
|
| Microcosm: graph vs table db. In the middle: social pressure
| dominating data model choices. Macrocosm (relatively speaking):
| The swing of the pendulum between bodgy vernacular attempts to
| describe the world (dev don't need some control freak's schema)
| and esoteric priesthood attempts to describe the world (all
| knowledge graph structural changes must be initiated by our
| ontologist...).
| enahs-sf wrote:
| My main gripe with it is it's an added level of indirection that
| makes debugging just a little more difficult.
|
| Back in the good old days, you could open up the network tab, see
| the request made by the client and copy as curl to debug it.
|
| Now with SSR and graphql, such a workflow is out the window.
| 0x20cowboy wrote:
| If you have one sever with one end point, and never use other
| services, graphql doesn't make sense. Don't use it.
|
| If you work with a bunch of Micro services, and you're only a
| backend developer, you likely don't understand the problem
| graphql is solving. The alternatives are almost always way worse.
|
| > No clear path for Api versioning you'll end up with
| MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
|
| You're not supposed to version it. That's what the @deprecation
| is for.
|
| > It is actually a pain to use, depending on the backend you are
| using you'll have to manage
|
| Do some front end work, or use your companies API as a client.
| Something where you have to talk to several services and try to
| stitch together some sort of combined data with all the latency
| and unreliability of http over a cell phone network. Then
| pontificate about how the boundaries between the services are
| wrong, but never change anything - or better yet change a bunch
| of boundaries then change the UI to cross different boundaries -
| then complain about how the UI should always have to exactly
| match your services because the world should revolve around how
| you've decided to see the problem.
|
| Yikes, where did that come from. That wasn't directed at you.
|
| Don't use graphql. When you figure out what it's for, it'll be
| easier to learn.
| 4dregress wrote:
| Being a good engineer (in any domain) means you have the
| experience to can pick the correct tools for the job and then
| explain why you have chosen those tools.
|
| It all depends on what the end goal is.
| cersa8 wrote:
| I use GraphQL (postgraphile) for my admin backend crud. This
| allowed me to do some incredible fast development with only
| minimal customisation (couple of PostgreSQL functions). Anything
| outside the happy path is handled by a REST API. Maybe we
| shouldn't think in absolutes, eg: only use GraphQL. For the same
| reasons I use an ORM, and raw queries where it matters most. The
| cliche holds true: use the right tool for the job.
| hn_user145 wrote:
| In any fast paced business, APIs constantly change. Versioning is
| not straightforward. Often corners are cut, and deadlines have to
| be met. There just is one version of the API, the one in
| production!
|
| In my experience the most pain around GraphQL was due to a lack
| of care/time. Too often schemas are not strictly defined, are too
| generic (type: any) and fields are not documented. Errors are
| poorly defined etc. Combine that with untyped code, it's almost
| the same as sending blobs of arbitrary JSON around. In the short
| term it works, the feature is live, business is happy. But takes
| double the effort to untangle the code when you need to change
| something....
|
| GraphQL also requires effort to make tooling and monitoring work
| well with it as it deviates from a traditional REST like model.
| yellow_lead wrote:
| > There just is one version of the API, the one in production!
|
| Unless there are multiple in production, i.e /v1/api, /v2/api,
| etc
| humbleMouse wrote:
| charbull wrote:
| What about sparql?
| anotherhue wrote:
| Comparing GQL to REST is like comparing a framework to a
| protocol. Of course it's easier to build up from REST, but if
| you're lucky enough that your project survives it won't be long
| before you're reimplementing the same GQL features you rubbished
| in a half-arsed way.
|
| In an ideal world, we can grow into the tech pulling in features
| as needed, but REST (in its modern form) is all about day 1
| productivity, not day 100.
| yellow_lead wrote:
| > if you're lucky enough that your project survives it won't be
| long before you're reimplementing the same GQL features you
| rubbished in a half-arsed way.
|
| Unless you don't need those features to begin with? I also
| think with this mentality you'd end up with a lot of teams
| saying "lets do GQL in case we need it later" and it ends up
| being a ton of work for no benefit later.
| sebnukem2 wrote:
| I'm happy to read this. I had to use GraphQL once in an old job
| and I hated, hated the freaking thing with a passion, but there
| was so much hype about it I concluded the problem with it was
| caused by myself, a getting older and more close minded self. I
| see now that GraphQL may not be that wonderful, after all.
| datalopers wrote:
| GraphQL's primary feature is enabling data exfiltration for bad
| actors
| x86x87 wrote:
| This nails it. Had the "proviledge" of needing to secure a GQL
| endpoint and it's a mess. AuthZ? What's that? + Runaway queries
| that kill the database? check! + Caching? Lol.
|
| Setting aside security and scalabilty for a second: Ifeel like
| GQL is at its best a complicated database driver, with the data
| types being defined and implemented twice: once in the DB
| layes, once in the backed.
| adra wrote:
| If you're testing gql as anything remotely similar to a
| database facade, you've already lost. GQL is meant to provide
| functionality that generally happens to be data backed. If
| you want to push all your work to the frontend and treat gql
| as a db shim, you're solving the wrong problem in the wrong
| ways.
| geuis wrote:
| It's not an unpopular opinion: it's true. Graphql is a terrible
| piece of software/paradigm.
|
| I've completely avoided it for years. If a potential new job
| contacts me and they use graphql, it's an immediate no from me.
| It's an immediate red flag that the engineering culture at the
| company is poorly run and would be a nightmare to work in.
|
| Run away, as fast as possible.
| eknkc wrote:
| So you are sure that some tech that you avoided completely (and
| I assume have zero experience in) is a terrible piece of
| software.
|
| Great. What is your take on the postal service structure of
| Turkmenistan btw?
| mechanical_bear wrote:
| Their service scope is waaaay too broad, no reason to be
| responsible for quasi banking services, traffic fine payment,
| and utility payment processing.
| publicdaniel wrote:
| It's not an unpopular opinion _on HackerNews_.
| chpmrc wrote:
| > Graphql is a terrible piece of software/paradigm.
|
| Says who, exactly? What data are you basing this on? Or is it a
| completely subjective opinion dictated by frustration likely
| caused by the lack of understanding of it?
| runald wrote:
| Did you try reading the thread? What do you mean by data?
|
| > Or is it a completely subjective opinion dictated by
| frustration likely caused by the lack of understanding of it?
|
| You can ask this this very same question when people say
| graphql is an amazing piece of software/paradigm, except
| s/frustration/hype/
| chpmrc wrote:
| Your argument stops being valid the second you realize that
| a lot of devs who use GraphQL started out as skeptics (e.g.
| me), then spent time actually understanding its nuances
| before coming to a conclusion _for a specific project
| /team_.
|
| And, in general, there's no such thing as a "good" or a
| "bad" technology, there are dimensions and each dimension
| is a spectrum: utility, adoption, availability, cost,
| complexity (although hard to determine), etc. to compress
| all that down to "hype" or "it sucks" just show how little
| time has been spent on understanding the nuances I
| mentioned above.
|
| I don't claim GraphQL is _amazing_ or even _good_ , it just
| proved to be a great way to build APIs for the projects I
| worked on. I'm sure someone who builds firmwares for
| embedded automated plumbing systems would disagree (within
| that context). If you decide not to adopt it I just hope
| you do it after a rational, unbiased review of what the
| tech is capable of and what the shortcomings are, rather
| than "oh it's over hyped".
|
| > Did you try reading the thread? What do you mean by data?
|
| Please don't question whether someone read the thread or
| not (which is irrelevant within the scope of this
| discussion anyway) just because they disagree with you.
| soccersofia15 wrote:
| Based on your logic, you've never worked for Airbnb, Uber,
| Facebook, Twitter, etc... which is also funny cause they have
| fantastic engineering culture. What a strange way to filter
| yourself out of great engineering companies just because of a
| piece of technology
| zmxz wrote:
| Yup, gotta trust the words from some unknown from internet,
| with 0 proof. As if we're all there, up in your head, able to
| hear every single thought you have and determine that what you
| say is pure, unfiltered truth.
|
| If many manage to use GraphQL and be content with it, that
| should be an indicator to you. But, you chose it isn't and that
| you'll merely display how politely negative you can be.
|
| Thank you.
| runald wrote:
| > trust the words
|
| > pure, unfiltered truth
|
| noone is forcing anyone to believe in anything, it's just
| some guy expressing his strong opinions about a subject, but
| no, you act like someone uttered a blasphemy against the
| lord's name
| hn_throwaway_99 wrote:
| > It's an immediate red flag that the engineering culture at
| the company is poorly run and would be a nightmare to work in.
|
| Well, at least I'm glad I know I'll never be working with you!
|
| I'm not giving you shit because you don't like GraphQL, I'm
| giving you shit because of your asinine "if you use GraphQL
| your company is poorly run and a nightmare" comment.
|
| Whenever I see a comment from any developer that says "If you
| use technology X then you are an idiot", then I know that
| developer is either incredibly junior and doesn't understand
| the tradeoffs in choosing any technology, or they're showing
| typical "if you don't like what I like than you don't know what
| you're doing" arrogance that inevitably always makes it a pain
| in the ass to work with that person.
| NonNefarious wrote:
| Yep. I worked at a place that fired almost its entire
| programming staff because they insisted on using Visual C++
| to build a CRUD app, while a team of contractors built a
| prototype in Visual Basic.
|
| Needless to say, the VB app worked fine and became the
| product.
| mechanical_bear wrote:
| Why is this "needless to say", as if it should be apparent
| to anyone?
| NonNefarious wrote:
| Because a CRUD app doesn't require any serious computing
| performance from the application, making C++ unnecessary.
| If another implementation won the race to functional
| completion, then... needless to say... it was the one to
| go with.
|
| Today you'd probably just use browser-based UI.
|
| Also if you've spent time in corporate development
| (rather than a software company), I think this scenario
| is a common one. If you show management a prototype that
| works, they're going to ask why we don't just make that
| the product. And if you don't have a good reason... you
| don't have a good reason.
| diarrhea wrote:
| If you don't mind, would you explain this more? I don't
| understand the implications; VB does sound "worse" than
| Visual C++ for such a job, from an outsider perspective?
| koonsolo wrote:
| In C++ you have to manage your own memory. Why would you
| want to do that when you're simply pushing data around.
|
| I wouldn't choose VB myself, but when it's between VB and
| C++ for simple data pushing, I would indeed choose VB.
|
| Let's say it like this: if you need to move stuff, would
| you choose a F1 car or a minivan. I would pick the
| minivan.
| NonNefarious wrote:
| No problem. At the time, Visual C++ lacked several
| important OCX controls that were included with VB, so
| they had to be hand-coded.
|
| If you were building an application that does little more
| than populate forms with data from a database and then
| update the database, VB was totally adequate. The most
| important part of the job was the DB and query design.
| cudgy wrote:
| You are right that this arrogant attitude is juvenile, but it
| is prevalent amongst humans in all areas. Unfortunately,
| there would be few developers to work with if you apply the
| policy of not working with arrogant, dogmatic developers.
| Kaze404 wrote:
| There's this stereotype of a programmer, that while I think
| can be funny sometimes, still reflects a professional that
| doesn't really exist anymore from my perspective.
|
| Most software engineers I've worked with have been
| incredibly humble and dedicated. The mythical bearded guy
| that showers three times a day, comes to the office with
| shorts and flip flops, and refuses to install Windows on
| the accountant person's machine because it's objectively
| bad is something I've only seen in memes and stories from
| older people I've worked with.
|
| I personally think dissolving this myth, along with the one
| that programming is easy and / or none of us know what
| we're doing, should be a shared goal between people who
| care about what they do and how others perceive it.
| Otherwise we're unknowingly cultivating it into existence,
| and I definitely don't want to work with arrogant, dogmatic
| developers.
| koonsolo wrote:
| For me it signals maturity.
|
| When it's a junior, I remember myself and think they still
| need to learn.
|
| When it's a senior, I know it's not a senior.
| hn_throwaway_99 wrote:
| Strongly disagree, primarily because when this type of
| attitude infects dev teams it is usually a _cultural_
| issue, not an individual one.
|
| The primary, inviolable value I have, and look for, in dev
| teams is "strong opinions, loosely held". Meaning I _want_
| to work with engineers that have the experience, motivation
| and intelligence to have strong opinions about how things
| should be done, but it 's also critically important that
| developers are humble enough to know other developers may
| have other experiences that can inform why a different
| decision can be better.
|
| If you've worked in a dev team that embodies this attitude,
| you know how great it can be and how dev team members will
| naturally work to strongly defend the group dynamic that it
| fosters. Meaning if a developer with a bit too much
| arrogance joins the team, they can often be trained into
| not having to be so judgemental, or making disagreements
| about real issues and not emotional arguments ("GraphQL
| sucks and you're stupid if you use it") If not, the
| existing team will quickly reject that arrogant developer
| because they know how dangerous they can be to a healthy
| group dynamic.
| ttfkam wrote:
| I'm truly saddened to hear that this has been your
| experience throughout your career so far. It is not a
| universal experience. I hope you find a better managed shop
| soon that recognizes that it's easier to teach folks a tech
| stack than to teach someone to be a decent (or honest)
| person.
|
| Too many tech shops sabotage their culture and dozens of
| potentially great contributors in order to keep a few (or
| one) toxic contributors that the powers that be erroneously
| believe are irreplaceable.
|
| Anyone can be a 10x developer when you sabotage the well-
| being and productivity of those around you.
| ant1oz wrote:
| Well said. I would also add that it is perfectly fine to
| have a list of red flags, and it is perfect fine to
| define your own bondaries. Graphql is a red flag for me
| too, as well is React and node.js, and even git to some
| extend. I love simplicity when designing web apps, their
| backend, their frontend and the deployment process in
| between. Although the tech is old , I came up that
| vue3+pouchdb+quasar is an amazing combination for a
| stable replicable dev environment, pwa, supports offline
| usage, and introduces possible p2p replication between
| browser's pouchdb instances trough webrtc.
|
| React , imo, is a good over engineered library suffering
| from fragmentation. Angular is less fragmented, and Vue
| is the most elegant, performant and versatile of the 3.
| Good Devs choose Vue after having worked with both react
| and angular. React Dev never tried Vue, nor Angular Dev
| try React. Vue Dev usually know all 3.
|
| Having a red flag like graphql can tell a lot about
| technical overview and experience in failure.
|
| Graphql solves a caching issue that Facebook has. Makes
| the frontend team life easy, making the backend team life
| hell , big big hello. Scope changes in the backend are
| terrible.
|
| Unless your team is engineered driven, and engineers take
| tech decision, and setup the sprints, going graphql in
| the backend is a recipe for disaster.
| spywaregorilla wrote:
| I felt pretty confident about my conclusions of my first
| dusty old bank job that used a custom shittier homebrew of
| google web toolkit and no source control.
| hn_throwaway_99 wrote:
| But that's very different. "No source control" means they
| aren't following or don't understand the very basics of
| software process management. That's very different from "If
| you use SCM system X, Y or Z you're an idiot."
| spywaregorilla wrote:
| Email and the windows file system is a SCM system if
| you're dumb enough.
| spullara wrote:
| GraphQL can also be a performance nightmare if you aren't
| rewriting every GraphQL query into a single SQL query.
| jahewson wrote:
| Same applies to REST APIs if you don't offer batch endpoints.
| Most of those n+1 query examples I see thrown at GraphQL would
| be n+1 GETs in REST.
| spullara wrote:
| For sure. Don't do that.
| NotTameAntelope wrote:
| Meh, each of your complaints is solved by understanding GraphQL
| better.
|
| If the main issue is you have to learn something complex, sure
| that's probably a little fair, but it's really easy to get
| GraphQL to do what you want once you've gotten over that initial
| learning curve.
|
| Specifically, queries and mutations can literally do whatever you
| want them to.
| dqpb wrote:
| I have only played with GraphQL a little, but from what I could
| tell, the client can't define the structure of the response, they
| can only choose to have some fields missing. Am I wrong, or is
| that basically all it does?
| brillout wrote:
| If you use Node.js, check out Telefunc[1] which enables you to
| seamlessly call Node.js functions from the frontend (in other
| words RPC). Including first-class TypeScript support.
|
| Its guide "RPC vs GraphQL/REST"[2] explains you when to use
| GraphQL and when not.
|
| [1]: https://telefunc.com/ [2]: https://telefunc.com/RPC-vs-
| GraphQL-REST
| chrisweekly wrote:
| IME GraphQL is kinda great on the consuming side, but the
| complexity and maintenance overhead of query resolvers can
| outweigh the benefits. I agree that it makes sense to look
| elsewhere first. For example, react-query can solve many of the
| problems GraphQL aims to solve (eg overfetching), without the
| downsides.
| wizofaus wrote:
| Can you expand on that? If your existing RESTish/JSON Api
| doesn't support the level of fine tuning of what data you want
| back, how can react-query prevent overfetching? I ask because
| I'm currently involved in converting some code over to react-
| query, despite the fact there's a longer term plan to move to
| GraphQL which I'm concerned will obviate the need for the
| current rewrite.
| infinitezest wrote:
| Ive used GQL on several projects for work and its been _OK_ to
| work with but not really worth the hassle in our cases. It ended
| up costing us lots of time to onboard new devs and hasnt given is
| much in return aside from type safety between the front and back
| ends. Im sure there are good use cases for GQL but I have not
| personally run into them.
| vlod wrote:
| > It can save you bandwidth. Get what you ask for and no more
|
| On the other hand, you tend to do "select * from FOO" and get
| more data from the db, because you don't know what the caller
| will ask for.
|
| I don't think I've even seen a codebase filter the SQL based on
| the caller. I think I tried doing it once and it was a pita.
| (Please correct me if it's easy).
| coder543 wrote:
| The typical approach that I've seen is to do "select * from
| FOO" for simple scalar fields that cost very little to retrieve
| from the database. If you have any fields that often contain
| large amounts of data, or any relations, you can provide a
| separate resolver for that field or relation, and then that
| resolver will only get invoked if the caller requested it. It's
| pretty straightforward, at least when using Apollo and
| TypeScript. (Obviously you would modify the original query to
| exclude such expensive fields so that you're not duplicating
| work with the additional resolver.)
|
| I still don't think I would _personally_ recommend GraphQL to
| most companies.
| E2EEd wrote:
| I built an app with a REST API a long time ago, now a defunct
| startup. In an effort to save API calls, the front end devs
| requested that I add various other resources in new endpoints,
| often a subset of another endpoint's response fields. The API
| spec ended up being fairly unwieldy.
|
| I've often thought that this would be a great use case for GQL.
| Seems like a good choice if your front end wants to specify
| exactly what data to get.
| b33j0r wrote:
| I loved the idea, then I found out that _doing_ anything devolved
| into completely custom RPC implementations.
|
| I'm not always RESTful, but in GraphQL the state transfer part is
| left as an exercise for the reader.
|
| I love natural data models. I also think RPC makes sense when
| there are clear verbs in a system.
|
| Poor GraphQL. It's like a Greatish novel where the first half is
| compelling and intricate, and the last half was rushed by the
| publisher.
| jsdwarf wrote:
| GraphQL Performance is abysmal, because query language is
| completely detached from the way data is stored and encourages
| you to select as much as possible.
| ramesh31 wrote:
| It suffers the same peoblem as WSDL, (or "proper" REST for that
| matter), which is inflexibility and boilerplate. It provides a
| mechanics garage worth of tooling when you probably just need a
| swiss army knife.
| mLuby wrote:
| Having worked in big tech and small startups, I think GraphQL is
| a brilliant way to solve an _organizational_ problem that massive
| tech companies have.
|
| It's that the team maintaining the API is different from the team
| that needs changes to the API. Due to the scale of the
| organization the latter doesn't have the access or know-how to
| easily add fields to that API themselves, so they have to wait
| for the maintainers to add the work to their roadmap and get back
| to it in a few quarters. Relevant Krazam:
| https://www.youtube.com/watch?v=y8OnoxKotPQ
|
| At a small start-up, if the GET /foo/:fooId/bar/ endpoint is
| missing a field baz you need, you can usually just add it
| yourself and move on.
| jonhohle wrote:
| If that field isn't populated aren't you in the exact same
| spot?
| vikR0001 wrote:
| Let's say you need to get a field back that is already in the
| database table, but that wasn't previously returned by the
| GraphQL endpoint. All you have to do on the front end is ask
| for it and GraphQL will populate it for you on the server.
| ahepp wrote:
| Why not just query the database directly then?
| eatYourFood wrote:
| _3u10 wrote:
| For external users of the API this can be quite helpful
| when you're looking for the password column on the users
| table.
|
| For some reason I don't think graphql actually works this
| way. Can't quite put my finger on why allowing access to
| any column on a table might be a _really_ bad idea.
| HelloNurse wrote:
| Putting passwords in a database, and that database behind
| some kind of service that allows queries, is a stupid
| mistake that can be implemented with SOAP, CORBA, a
| remote shell, or any other protocol or API style.
|
| I don't think GraphQL makes the problem worse except by
| encouraging experimentation by putting an unusually
| powerful query language in the hands of the users
| jonhohle wrote:
| Ancestors of your post are suggesting exposing entire DB
| schemas (I would assume mechanically). While that could
| also be the case in other protocols, typical an IDL is
| used to separately define the API layer. Of course it's
| completely possible to generate a WSDL, etc. from a DB
| schema, in practice I've never seen it done.
| dragon-hn wrote:
| If your GraphQL schema is just a mapping of database
| tables, in my experience you are in for a world of hurt in
| the future.
| vidarh wrote:
| It's possible to do this without it getting painful, but
| you need to annotate the database schema with a lot of
| meta data.
|
| We don't use GraphQL, but we do use an API that is mostly
| generated from meta data about the schema and permissions
| on a per field basis, with the ability to override on a
| per table basis.
|
| To the API consumer it's invisible if they're referring
| to something that refers directly to a real database
| columns or to a method on a model class that doesn't
| correspond directly to the database (e.g. the user
| "password" attribute is
|
| Effectively there are two schemas: the API schema and the
| database schema, it's just that the API schema is
| "prepopulated" from introspecting the database schema
| using Sequel (Ruby ORM), with the model classes
| translating between the two, with a synthesised default
| mapping.
|
| The "API schema" includes more granular type information
| suitable for the frontend, and permissions, including
| type information returned to the frontend to provide
| default client side form rendering and validations (also
| enforced on the server, of course). It also auto-
| generates documentation pages with example data, inspired
| by Airtable's doc pages.
|
| But key to avoiding what you describe is that these are
| all easily overridable defaults, and the permissions
| default to allowing no columns, so while the db schema
| introspection makes it quick to expose things where a
| direct mapping makes sense, it also makes it easy to
| avoid.
|
| Unlike GraphQL we explicitly avoided allowing you to
| request arbitrary complex sets of data, but what you can
| do is expose queries by defining model metadata for them
| that either wraps suitable views or custom queries. We
| have a UI to allow us to define and store custom queries
| and views for e.g. reporting needs, so we can prototype
| new API needs in the browser writing just queries with
| some metadata annotation.
|
| It gets us the flexibility of being able to quickly
| return exactly the desired data, while retaining control
| over the queries and complexity.
| crispyalmond wrote:
| At my workplace they made this decision before I started
| and I can fully agree with this. It's essentially a typed
| REST without any of the benefits. No joins, everything is
| multiple calls away to perform a "full" query.
|
| I don't even want to think about undoing this mess.
| sholladay wrote:
| A world where the front end can access any database field
| it wants sounds like a security / privacy nightmare to me.
|
| Of course there are ways to prevent data from being
| returned but that's fragile.
| purerandomness wrote:
| How does GraphQL help here?
| netik wrote:
| This isn't remotely a problem. Field by field granular
| security is trivial to implement in GraohQL
| hamandcheese wrote:
| I have to disagree with you there. It is possible, but it
| causes other annoying problems.
|
| For example, field-level security pretty much means every
| field could be null at any time. Depending on your
| graphql server implementation, this might cause an entire
| request to fail rather than just that field to be
| omitted, unless you change your schema to where
| everything is nullable.
|
| Checking every field can also easily lead to performance
| issues, because it's not uncommon for a large, complex
| graphql request to have hundreds or thousands of fields
| (particularly when displaying lists of data to a user).
| dragon-hn wrote:
| > unless you change your schema to where everything is
| nullable
|
| At my current job, this was done before I was involved.
| It isn't a deal breaker, but it throws away one of the
| best features of GraphQL.
|
| In the end you just have every client implement the rules
| that should have been in an API tier (if they are
| competent), or worse no validation that gets you a giant
| mess.
| withinboredom wrote:
| Not to mention GraphQL wasn't designed with security and
| user-state in mind. It was an afterthought that was
| bolted on, varying from framework implementation to
| implementation.
| jfengel wrote:
| How the heck was that not on their minds from day 1? It's
| the most obvious question to ask about a project like
| that.
| withinboredom wrote:
| It's from before the https-everywhere days, or around the
| same time letsencrypt was started up, IIRC. Back then, I
| feel like security wasn't as big of an issue, at least
| for less sensitive things. Like literally the entire site
| would be http until you got to checkout and the only
| reason you had the certs was to be PCI compliant.
| BerislavLopac wrote:
| Assuming the backend actually supports mapping of that
| particular field.
| the_mitsuhiko wrote:
| In many ways you also need to be a massive tech company to not
| create a massive scalability problem. The first time someone
| ships a shitty query to a large user base on a mobile app you
| are now dealing with the consequences of a frontend engineer
| creating a bad query you can not kill quickly any more.
|
| Making scalable, well performing queries work is nontrivial,
| particularly with the current ecosystem of GraphQL libraries.
| The main workaround for this provided appears to be directly
| mapping GraphQL to an ORM.
| makeitdouble wrote:
| I used to see GraphQL (and to an uglier respect Soap like
| interfaces) as complicated solutions to that problem you
| describe.
|
| But more and more, I think Backend For Frontends solve this
| issue in a much better way. And of course that idea isn't new
| and Yahoo for instance had that kind of architecture.
|
| Frontend teams get to adjust by themselves a simple interface
| to their needs, and backend teams can provide more info through
| internal APIs with less restrictions than if it was directly
| exposed to the outside.
| gedy wrote:
| I'm not following if you think GraphQL is a bad fit still,
| but we used GraphQL with the BFF pattern, and it was nice to
| use from Frontend to BFF. The backend services would use REST
| or whatever appropriate behind the BFF.
| makeitdouble wrote:
| I see GraphQL as unneeded if you already have a BFF managed
| by front teams.
|
| Going with basic REST gives you simpler
| caching/optimisation paths, more straightforward mapping
| between the front request and the backend calls, and it
| makes it easier for other teams to look at what you're
| doing and comment on/fix stuff as needed. GraphQL would be
| pure syntax sugar, and I'm not sure it would be worth the
| trade-off.
| kbumsik wrote:
| You can use GraphQL for BFF btw.
| no_wizard wrote:
| Do you have any reference material for the Yahoo
| architecture?
| makeitdouble wrote:
| It was pretty basic so I'm not sure how much it was talked
| outside of Yahoo. I see this presentation
| http://www.radwin.org/michael/talks/php-at-yahoo-
| zend2005.pd... providing an overview, but otherwise the
| basic principle was to have each addressable web server
| host an apache with a routing module, and that module will
| map a request path to a cgi file.
|
| With that structure you can have any number of layers with
| your front call and the different business abstractions all
| representated by an API (let's say you want a user's
| average engagement with a service, you'd hit the high level
| API, which will fetch access stats from another API, which
| rely on a lower level API which goes through another
| separate layer managing DB cache etc.
|
| Most of these call are of course internal to a data center.
| masklinn wrote:
| I think an other thing with graphql is it reduces friction when
| trying to _discover_ what your API should be.
|
| So what you can do is some sort of generative graphql thingie
| when doing your initial iteration, with the client hitting
| whatever is convenient (in that situation you'd just expose the
| entire backend unprotected).
|
| Once the needs have gelled out you strip it out and replace the
| graphql queries by bespoke API endpoints.
| coffee_beqn wrote:
| I just have never had this as a problem having worked on many
| APIs at many companies. Usually we decide what we want to
| work on and the frontend/full stack can read the
| documentation / chat with the backend engineers if it's not
| clear. At no point is "discoverability" a issue
| masklinn wrote:
| The discoverability I'm talking about is not about knowing
| what the API _is_ , it's finding out what the API _should
| be_.
| demarq wrote:
| That's the theory. In my experience at both large and small
| organisations is that NONE of the theory makes it into
| practice.
|
| Some reasons:
|
| - Front end devs save time by.... sharing queries. So component
| B ends up fetching records it has no use for because its
| sharing GQL with component A.
|
| - Backenders never optimise column selection. You may think you
| are really optimising by sending a GQL query for one column,
| but the backend will go ahead and collect ALL the columns and
| then "filter" down the data that was asked for.
|
| - Backenders can also forget to handle denormalisation. If you
| query related many to many records but the GQL only asks for
| related ids of implementations will go ahead and do a full join
| instead of just returning results from the bridge table.
|
| - Frontenders aren't even aware you can send multiple graphql
| GraphL requests simultaneously.
|
| GraphQL is great, but any technology is limited by how well
| people can extract its value. I personally feel sometime we'd
| be better off with REST, or at least make sure people receive
| the training to use GraphQL effectively.
| squidsoup wrote:
| > Front end devs save time by.... sharing queries. So
| component B ends up fetching records it has no use for
| because its sharing GQL with component A
|
| An unfortunate problem that really only exists with Apollo.
| Facebook's graphql client, relay, does not have this issue as
| it requires each component to explicitly declare its data
| dependencies.
| danabrams wrote:
| 100% agree that it's about dependence on other teams. That
| said, I'd much rather that we were communicating across a well
| defined api boundary, rather than a graphql api. You could, of
| course, very easily do this with an api layer in the middle.
| YZF wrote:
| Nobody seems to get the idea of building software out of
| pieces with well defined APIs any more </rant>. I would say
| it's not possible to build large software without adhering to
| this principle but I seem to be proven wrong. You can build
| large poor quality software and just throw more people at it.
|
| The other part about team dependence is very true but it also
| shows a lack of knowledge/thinking/care by whoever formed the
| teams. It seemed for a while Amazon had things right both in
| terms of boundaries of teams and in terms of forcing people
| to use APIs- not sure what they do these days.
| ako wrote:
| What is a well defined API to access a lot of related
| datasets if you have 100s of external users, using it for
| 10s of different types of use cases?
|
| Compare it to a database, what if you couldn't use random
| queries with SQL, but only had the option to call stored
| procedures?
| YZF wrote:
| It's the narrowest abstraction fitting those use cases. A
| database by its nature is a generic component. So sure,
| the piece of your software that's "SQL database" has a
| SQL interface, pretty quickly you'd want some
| abstractions on top of that around the different uses of
| that database.
|
| The problem is when genericity diffuses its way into a
| large system it becomes impossible to maintain. How do
| you refactor a code base when everything everywhere is
| just SQL queries. If you want to change the schema how do
| you know you're not breaking anything? The short answer
| is you don't and so the software becomes incredibly
| brittle. The common workaround is testing but you can
| never test everything and now your tests also become
| coupled to everything else making things even more
| difficult to change.
|
| The database in your example, while being generic is
| already an abstraction of sorts. Now if you're building
| lessay gmail the external users should see "create
| email", "get all emails", vs. issuing SQL queries to the
| database. That makes it easier to change the two pieces
| (client and server in this simplified example).
| [deleted]
| pphysch wrote:
| This is one of the strengths of gRPC, it forces and
| centralizes the (mostly type safe) API design from the get-
| go.
|
| Also tends to use a lot less bandwidth.
| withinboredom wrote:
| The biggest issue with GRPC is that it is only suitable
| for stateful languages (iow, languages that can hold
| values and share them between requests). GRPC is
| basically worthless for stateless languages and unusable.
| These stateless languages also don't work well for
| websockets either, so it is what it is.
|
| Until they solve the stateful part, I'm not using it or
| recommending it to be used anywhere. Bandwidth is cheap,
| type safety is overrated, and compute is expensive.
| YZF wrote:
| What's a "stateful language"? Can you give an example
| here? gRPC is orthogonal to whether an API relies on
| state or not.
| pphysch wrote:
| Is this bait? Lol
| NeedMoreCowbell wrote:
| +1 This is it. Great for internal API's, not so much for public
| facing ones.
| rootext wrote:
| > It doesn't support map/tables/dictionaries. This is actually
| huge.
|
| It's actually easy to implement. Just define custom scalar type:
| scalar JSON type MyObject { myField: JSON }
|
| https://www.apollographql.com/docs/apollo-server/schema/cust...
| randytandy wrote:
| Hey thanks for taking the time to find the resource
|
| I have used this before this works to get past the errors but
| doesn't actually solve the issue GraphQL tries to solve. This
| just hides it so you have to deal with it months later.
|
| - The consumers don't know what the JSON looks like unless they
| test the query or get told what the query is explicitly. This
| means that the schema definitions don't capture the problem
| that the graphql try's to solve "describe your data that you
| want"
|
| - also some of the other languages that aren't Javascript don't
| have GraphqlJsonScalar
|
| I think that supporting dictionaries/maps/tables as apart of
| the Graphql language spec could of been possible as the key and
| value types are static. They are also iterable so it should be
| fairly straight forward for a consumer to deal with the data
| returned.
| raydiatian wrote:
| Check out EdgeDB, and EdgeQL
| anothernewdude wrote:
| You just ignore the main selling point? It solves the latency of
| getting the data you need. The only alternative is to provide
| specific extra APIs.
|
| If it's a pain to use, perhaps you're using the wrong language or
| framework.
|
| You're right that many APIs have maps, those are bad APIs. The
| map should be happening in your API. The alternative was a poor
| workaround to stop latency in a REST api.
| carapace wrote:
| First, s/opinoin/opinion/
|
| Second, there's a reason DBA (Database Administrator, something
| like that) is a formal, separate role.
|
| If you don't have a DBA it's not because that's a good idea, it's
| because you (or your bosses) are too cheap to do things well.
| That's okay, a lot of times cheap is more important than correct.
|
| You're still going to need _schema_.
|
| Both NoSQL and GraphQL seem to throw the baby out with the bath
| water. It was all done before, and Relational Model won. Gotta
| know your history kids:
| https://en.wikipedia.org/wiki/Database#History
|
| - - - -
|
| Tidbit of lore: SQL is not the original language for relational
| model databases, Codd had a language he called Alpha:
| https://en.wikipedia.org/wiki/Alpha_(programming_language)
|
| SQL is the JS of DBs!
| ramesh31 wrote:
| I woyld really love to be able to consume GraphQL API's all the
| time, but I would never ever want to have to write or maintain
| one. That pretty much sums up the problem.
| jensneuse wrote:
| The GraphQL specification doesn't mention HTTP. It's just a query
| language, like SQL, but with a different focus. I understand what
| people complain about in this discussion. It makes sense. Talking
| GraphQL between client and server can be a headache. That said,
| I'd like to propose a completely different use case. Have you
| thought about using GraphQL as a "meta-language" to compose APIs?
| A pure Server-Side solution to manage APIs as "dependencies", and
| turn them into a JSON-RPC API as you need them. I wrote about
| this here: https://docs.wundergraph.com/docs/architecture/manage-
| api-de...
|
| I'm curious what people think about this use case of the Query
| language.
| hn_throwaway_99 wrote:
| > It's just a query language, like SQL, but with a different
| focus.
|
| No, no, no! I love GraphQL, and have been using it on projects
| for many years now, but the thing that is difficult for me to
| forgive the original designers of the spec that they put "QL"
| in the name, confusing so many developers into thinking it is a
| generic query language.
|
| GraphQL is simply a spec and contract for exposing an API. Its
| "competing technologies" are things like RESTful APIs and gRPC.
| It really has nothing to do with a generic "query language"
| like SQL.
| mdaniel wrote:
| It is a query language in that one can select the fields one
| wishes to be returned, including conditional evaluation of
| interior clauses via e.g.
| https://spec.graphql.org/October2021/#sec--skip
|
| The field selection is certainly possible in REST via
| something like /foo?include=a,b,c but starts to get just
| downright silly with /foo?include=a,b.c[1].d,e[*].f which has
| now become its own DSL
| [deleted]
| gsvclass wrote:
| I would say it depends on how you use it. With GraphJin you use
| GraphQL to define your API and GraphJin auto compiles it into SQL
| and instantly gives you a REST and a GraphQL API endpoint to use
| it with.
|
| https://github.com/dosco/graphjin
___________________________________________________________________
(page generated 2022-08-06 23:00 UTC)