[HN Gopher] Absinthe for Large Elixir Applications
       ___________________________________________________________________
        
       Absinthe for Large Elixir Applications
        
       Author : amalinovic
       Score  : 58 points
       Date   : 2023-06-06 11:04 UTC (11 hours ago)
        
 (HTM) web link (blog.appsignal.com)
 (TXT) w3m dump (blog.appsignal.com)
        
       | l72 wrote:
       | Great article on Absinthe, which is a graphql server library for
       | elixir.
       | 
       | Also, if you run elixir in production, you should check out
       | appsignal. It is incredibly helpful for my company (no
       | affiliation with appsignal)!
        
         | ilikehurdles wrote:
         | Surprisingly common. As an elixir dev I often end up with the
         | wrong kind of elixir/absinthe results on duckduckgo.
        
       | mpsprd wrote:
       | As a by-product of my mixology hobby, I thought for a second this
       | post was about Absinthe, the drink.
       | 
       | I was really curious about what Large elixirs meant in this
       | context.
        
       | freedomben wrote:
       | This is part 2. If you're not familiar with graphql yet, part 1
       | is an introduction to absinthe/graphql:
       | https://blog.appsignal.com/2023/05/16/an-introduction-to-abs...
        
       | andy_ppp wrote:
       | I highly recommend GraphQL-codegen if you like your API client to
       | be type safe on the frontend. I'm using Absinthe on
       | https://veloa.co and like most elixir packages it is extremely
       | well thought through and very stable.
        
       | benwilson-512 wrote:
       | Hey folks! Author of Absinthe here, feel free to ask me any
       | questions.
        
       | senorrib wrote:
       | I have a hard time understanding the reasons why people focus on
       | the wrong problems in large scale systems. N+1, for example, is
       | bad, and we all know it. However, these examples always show
       | strong coupling between database and API representations, and
       | this is a far bigger problem in large scale systems.
        
       | ilikehurdles wrote:
       | I was relieved to see we're doing almost all of this except for
       | using dataloader. The explanations were clear and concise so when
       | that need arrives I'll probably reference this post again.
        
         | throwawaymaths wrote:
         | Just be careful. Dataloader's errors (like many lazy systems)
         | are incredibly difficult to parse. And (last I checked several
         | years ago, may have changed) Dataloader's documentation is very
         | sparse
        
         | sb8244 wrote:
         | I'm also doing everything except dataloader. I can't shake that
         | there's something I don't like about it.
         | 
         | Maybe it's actually a great library, but it feels like I'm
         | giving up control of my queries and letting it run with them.
         | 
         | I prefer to use the batch function and manually resolve the
         | query on my own. It's a little more work but it's pretty easy
         | in the end. And fully controlled.
        
           | dudul wrote:
           | Same - I _hate_ how the dataloader documentation is so
           | centered around the idea that your dataloader just reaches
           | out directly into your Ecto layer. I always ended up building
           | my own KV implementation of dataloader. Maybe I was dumb, and
           | maybe I was basically just writing boiler plate, but at least
           | I could reason about my GraphQL API and my DB /Repo/Schema
           | separately and just have one use the other.
        
       ___________________________________________________________________
       (page generated 2023-06-06 23:02 UTC)