pokeapi

pokeapi copied to clipboard

Hi. I've been playing around with the GraphQL API and I can't find a way to retrieve Pokemon along with their sprites.

This is the query I'm using, but I'm getting every Sprite as null:

query pokemon {
  pokemon_v2_pokemonspecies(where: {pokemon_v2_pokemondexnumbers: {pokemon_v2_pokedex: {name: {_eq: "kanto"}}}}) {
    id
    name
    pokemon_v2_pokemons {
      pokemon_v2_pokemonsprites {
        sprites
      }
    }
  }
}

One result from this query is this:

{
  "data": {
    "pokemon_v2_pokemonspecies": [
      {
        "id": 1,
        "name": "bulbasaur",
        "pokemon_v2_pokemons": [
          {
            "pokemon_v2_pokemonsprites": [
              {
                "sprites": "{\"front_default\": null, \"front_female\": null, \"front_shiny\": null, \"front_shiny_female\": null, \"back_default\": null, \"back_female\": null, \"back_shiny\": null, \"back_shiny_female\": null, \"other\": {\"dream_world\": {\"front_default\": null, \"front_female\": null}, \"official-artwork\": {\"front_default\": null}}, \"versions\": {\"generation-i\": {\"red-blue\": {\"front_default\": null, \"front_gray\": null, \"back_default\": null, \"back_gray\": null}, \"yellow\": {\"front_default\": null, \"front_gray\": null, \"back_default\": null, \"back_gray\": null}}, \"generation-ii\": {\"crystal\": {\"front_default\": null, \"front_shiny\": null, \"back_default\": null, \"back_shiny\": null}, \"gold\": {\"front_default\": null, \"front_shiny\": null, \"back_default\": null, \"back_shiny\": null}, \"silver\": {\"front_default\": null, \"front_shiny\": null, \"back_default\": null, \"back_shiny\": null}}, \"generation-iii\": {\"emerald\": {\"front_default\": null, \"front_shiny\": null}, \"firered-leafgreen\": {\"front_default\": null, \"front_shiny\": null, \"back_default\": null, \"back_shiny\": null}, \"ruby-sapphire\": {\"front_default\": null, \"front_shiny\": null, \"back_default\": null, \"back_shiny\": null}}, \"generation-iv\": {\"diamond-pearl\": {\"front_default\": null, \"front_female\": null, \"front_shiny\": null, \"front_shiny_female\": null, \"back_default\": null, \"back_female\": null, \"back_shiny\": null, \"back_shiny_female\": null}, \"heartgold-soulsilver\": {\"front_default\": null, \"front_female\": null, \"front_shiny\": null, \"front_shiny_female\": null, \"back_default\": null, \"back_female\": null, \"back_shiny\": null, \"back_shiny_female\": null}, \"platinum\": {\"front_default\": null, \"front_female\": null, \"front_shiny\": null, \"front_shiny_female\": null, \"back_default\": null, \"back_female\": null, \"back_shiny\": null, \"back_shiny_female\": null}}, \"generation-v\": {\"black-white\": {\"front_default\": null, \"front_female\": null, \"front_shiny\": null, \"front_shiny_female\": null, \"back_default\": null, \"back_female\": null, \"back_shiny\": null, \"back_shiny_female\": null, \"animated\": {\"front_default\": null, \"front_female\": null, \"front_shiny\": null, \"front_shiny_female\": null, \"back_default\": null, \"back_female\": null, \"back_shiny\": null, \"back_shiny_female\": null}}}, \"generation-vi\": {\"omegaruby-alphasapphire\": {\"front_default\": null, \"front_female\": null, \"front_shiny\": null, \"front_shiny_female\": null}, \"x-y\": {\"front_default\": null, \"front_female\": null, \"front_shiny\": null, \"front_shiny_female\": null}}, \"generation-vii\": {\"ultra-sun-ultra-moon\": {\"front_default\": null, \"front_female\": null, \"front_shiny\": null, \"front_shiny_female\": null}, \"icons\": {\"front_default\": null, \"front_female\": null}}, \"generation-viii\": {\"icons\": {\"front_default\": null, \"front_female\": null}}}}"
              }
            ]
          }
        ]
      }
    ]
  }
}

Two things:

1. all sprites are null
2. rather than being part of the JSON response, the sprites are returned in a string containing another JSON document.

Am I doing something wrong or is it this a bug?

It's a bug. Currently, the sprites are the only non-working thing in the graphql engine. It's because we don't have a Postgres table for them.

Is there any updates on the issue? I'm having the same problem...

No updates

I tried locally but then I had no time and didn't continue

shame :( otherwise its a great graphQL playground! 🙏

I ran the same query as @simonorono and I didn't get null for the sprites, I got the paths but the paths before they are serialized:

"sprites": "{\"front_default\": \"/media/sprites/pokemon/1.png\", ...}"

This is just how it appears inside the PokemonSprites model since that model is just a charfield. We don't use that media substring anywhere from what I can see, except maybe in a few tests. We could just entirely remove that media string and replace it with https://raw.githubusercontent.com/PokeAPI/sprites/master/ in the build file, because that's what we do in the serializers anyway. It'll make that table a bit bigger and it would still be a string, but at least the user could just parse it since it's stored as valid JSON.

Tested with a fresh clone of the PokeAPI and can confirm this is no longer an issue.

Hi @simonorono, No implementation has been made. I feel the issue is still here.

@C-Garza , how could you possibly get the sprites' link?

@Naramsim you're right, I was looking at the regular API :man_facepalming:.

@Naramsim I can't really recall, but if I remember correctly I think I made a mistake because I was doing it on my local machine and it had those sprite links after I ran some kind of step. But I'm pretty sure it shouldn't work still because the sprites don't have their own postgres table or something if I recall.

So i was able to reproduce this error and fix it on my machine. Since no PR has been raised against this, i am gonna assume this has not been explicitly fixed.

I downloaded the the tar ball from the releases page. Currently the latest is v2.3.0. The core issue seemed to be tar ball didn't to contain the sprites data at all. So when running the application, the sprites folder was empty, causing the null response. I manually added the sprites folder data, flushed the DB with make docker-flush-db , and rebuilt it with make docker-build-db. This fixed the issue and on using GraphQL Query mentioned above, i am getting something of an acceptable response.

Attaching gist for others to verify API response https://gist.github.com/LeonEstrak/cf6a288e45c35a2b516f7f762890952a

I ran the same query as @simonorono and I didn't get null for the sprites, I got the paths but the paths before they are serialized:

"sprites": "{\"front_default\": \"/media/sprites/pokemon/1.png\", ...}"

This is just how it appears inside the PokemonSprites model since that model is just a charfield. We don't use that media substring anywhere from what I can see, except maybe in a few tests. We could just entirely remove that media string and replace it with https://raw.githubusercontent.com/PokeAPI/sprites/master/ in the build file, because that's what we do in the serializers anyway. It'll make that table a bit bigger and it would still be a string, but at least the user could just parse it since it's stored as valid JSON.

@C-Garza I have raised https://github.com/PokeAPI/pokeapi/pull/727 to resolve this.

OK, thanks to @LeonEstrak we now have the URL of the sprites in the graphql response. They have to be parsed but at least they are there.

Thanks!

Any update on these being parsed? I added some code on my side to parse the sprites object and then choose a specific one that I want, but it would be nice to handle that in the GQL query

No. sorry, updates here will require some actual work and nobody can right now

Hello, I'm not sure if anyone is aware, but it looks like the URLs in sprites reverted to their previous '/media' form. These used to have the full URL in them at some point, but are now not working anymore. The only reason I noticed is because of a codepen I use this for. Just thought I'd let you know. Thank you.

You're right!

Issue still happening. Going back to restfull right away

Been playing with this and it seems that just changing the type of the column to jsonb would be enough to make Hasura return them properly. However, the API breaks and I haven't had the time to check what needs to be changed in the API for this to work.

Been playing with this and it seems that just changing the type of the column to jsonb would be enough to make Hasura return them properly. However, the API breaks and I haven't had the time to check what needs to be changed in the API for this to work.

Did you try to build the db with first cloning the submodules? The sprites need to be present locally

Been playing with this and it seems that just changing the type of the column to jsonb would be enough to make Hasura return them properly. However, the API breaks and I haven't had the time to check what needs to be changed in the API for this to work.

Did you try to build the db with first cloning the submodules? The sprites need to be present locally

I tried without cloning the submodules. Was just trying the format part of it.

Am I doing it wrong or this is still broken ?

Still broken

Is there any intention of fixing it? I see that it has been like this for quite a long time.

I tried to replicate it some time ago and at some point I managed to fix it. But I don't remember how now. It's gonna probably stay like this for a couple of months

@Naramsim I have raised #949 to fix this. Seems to be working fine while doing local testing.

I will see if i can get them parsed. If you could provide a little assistance here @simonorono, since it seems you got the parsing bug.

@Naramsim I have raised #949 to fix this. Seems to be working fine while doing local testing.

I will see if i can get them parsed. If you could provide a little assistance here @simonorono, since it seems you got the parsing bug.

Many thanks !!

Hi the sprites should be there now. As a parsable string block.

Hi the sprites should be there now. As a parsable string block.

Appears the parsable string blocks may be out-of-date compared to the REST API (eg. ogerpon, id 1017 returns all null values)

Why does it differ so much to the way it is structured in the rest version?