chore: update cover image

blog/tailcall-n+1-working-2024-08-04.md

@@ -7,16 +7,18 @@ authors:
     image_url: https://avatars.githubusercontent.com/u/194482?v=4
 description: A deep dive into the implementation details of the N+1 tracker
 slug: tailcall-n+1-identification-algorithm
+image: /images/blog/n+1-identification-cover.png
 ---
 
+![Cover image for N+1 Identification in GraphQL](../static/images/blog/n+1-identification-cover.png)
 As a developer working with GraphQL, you're likely familiar with the concept of N+1 issues, if not you should definitely check out our [N+1 guide](/docs/graphql-n-plus-one-problem-solved-tailcall).
 
+<!-- truncate -->
+
 To summarize they occur when a GraphQL resolver is called multiple times for a single GraphQL request, leading a large set of requests upstream and overall a slower query execution. In this blog post, we'll dive into how Tailcall specifically identifies N+1 issues in GraphQL, and explore the algorithm and data structures used to detect these issues.
 
 ![Actual Usage Image](/images/blog/n+1-image-terminal.png)
 
-<!-- truncate -->
-
 ## High-Level Working
 
 Unlike a traditional GraphQL implementation where the resolvers are written by hand Tailcall encourages developers to take a configuration-driven approach. This has many benefits and we have talked about them in our previous [blog](./no-code-graphql-2024-05-30.md). One of the main advantages of not handwriting is the ability to introspect and optimize. This means a configuration file can be parsed, validated and semantically analyzed to identify issues such as N+1 very precisely. With code, that's written in a general-purpose language if you wish to perform semantic analysis automatically you will need to depend on some sort of LLM solution and still it won't be as precise (at least today).