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)!

Surprisingly common. As an elixir dev I often end up with the wrong kind of elixir/absinthe results on duckduckgo.

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.

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.

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.

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

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.

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...

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.

Hey folks! Author of Absinthe here, feel free to ask me any questions.

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.

A few reasons they don't cover that sort of thing in articles like this imo:

1. Graphql brought back n+1 problems for many popular frameworks/languages

2. This article's goal is to convert readers into paying customers, never forget that. Engineers at shops with large scale systems and problems like what you've outlined are not who will be reading this article and are not people who would pay for appsignal. They likely have existing performance monitoring systems that are either too specific to their systems, too entrenched into their infra, or more advanced for their needs.

In the end this article is marketing, and effective marketing casts the widest net to get as many people into the funnel as possible. When you look at it that way, common scaling problems, like n+1 is going to buy more customers for the cost of this marketing campaign compared to the hyper-niche pool of shops worried about decoupling database:api 1:1 mappings