Requirements to an V3(beta)

[GreatNovaDragon]

First of, i am taking reference to this message by @Naramsim here

Hi guys, if you like we can start working on a V3beta version! If you are volunteering we can start writing some code.

On my side, I can only help you with the deployment part, since I don't really have time to implement such complicated things now. We can start anew and use or drop Django, same goes for CSVs, we could switch to other formats. Reply if we can on you!

I'll copy this comment over at #966.

Originally posted by @Naramsim in #1037 (comment)

As much as i personally would love to start anew, there are some informations missing before one could actually do such,

What are the requirements to an v3 (Technical or Modelwise)? What should be carried over from v2? What explicitely not? Or does nothing matter and someone should just start?

[Naramsim]

Hi, so far the APIv2 had a great success and the only big problem for the user is understanding the difference between pokemon, pokemon-species, pokemon-forms.

I say we cannot modify the current properties nor delete them but only add them for the current API due to the huge consumption, as we have done so far.

That said other small problems were raised in the past. I'll write down a small list of thoughts

1. encounters return is different than other endpoints' #332
2. We use changelog tables. In my mind, I thought we might have an API that's generation-centric, such as:

/api/v3/generation-i/pokemon/bulbasaur
/api/v3/generation-iii/pokemon/bulbasaur
/api/v3/generation-i/item/old-rod
/api/v3/generation-iii/item/old-rod

But maybe this adds difficulties in understanding.
3. We are serving static files so the new one should also be able to be parsable and servable with a simple function or we'll incur again in terrific costs.
4. We could start from a predefined standard as OpenAPI and/or use an API generator.
5. We might just work on the GraphQL current API and promote it to V3. Especially if we could strip the pokeapi_v2_ prefix from all the fields. And maybe getting rid of pokemon-forms and pokemon-species and condense them into a single PG table that then can be retrieved with GQL.
6. GQL now has no costs, but it crashes when someone submits a heavy query. We should at least upgrade to 2cpu8ram machine that's about 50$ per month, but our current ad revenue is 30$/m and the donations are basically non-existing.
7. A big problem for us is finding people to update the data. It would be cool to automate it and maybe build the data from external sources without having to maintain CSV files.

To be honest the point 5 is really cool!

This are just some thoughts.

[GreatNovaDragon]

I'll add my own personal thoughts, with the

0. Some of my thoughts are also based upon the fact that in semantic versioning, a major version change is accompanied by Breaking API Changes.
1. I personally dont like the pokemon, pokemon-species, pokemon-forms table format, cause it doesnt combine with a relatively more modern understanding of what a "Pokemon" is.
2. the current csv files are not that easy to understand how to edit, unless you already have Database Knowledge.
3. that there is big doubling with the ID and the Name fields in the NamedRessources. The ID could aswell actually just be the name, in the named-ressources.

Additional understanding question: How/Where are the static files served? Is it just json-formatted files outputted somewhere?
4. If its just json-formatted files somewhere on github, couldn't we actually just forego any actual programming of an csv -> json conversion, and directly edit the json files, and a CI-Run to verify that the edit works.