4 ms·

What exactly is the simpler solution that doesn’t result in your same cons mentioned?

• JohnHaugeland 4y ago
  Making a regular api
  • endisneigh 4y ago
    A regular api poorly implemented will have all the same cons and none of the pros.
    • geysersam 4y ago
      Just make a perfect api without any drawbacks.
      • deleted 4y ago
        [deleted]
      • endisneigh 4y ago
        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 4y ago
          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 4y ago
      [deleted]
    • JohnHaugeland 4y ago
      > 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 4y ago
        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 4y ago
          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 4y ago
            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 4y ago
              > 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 4y ago
  SQL statements wrapped in function calls.
• thomassharoon 4y ago
  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/localizationextensionkey https://shopify.dev/api/admin-graphql/2022-07/enums/localiza...
  • deleted 4y ago
    [deleted]
  • endisneigh 4y ago
    There a lot of ways to do the same thing as GraphQL. The point is if it’s as easy.