Site portal to static site

[neverendingqs]

What about converting the site portal to a static site? Right now it uses Django templates. I can work on that next.

From #350. Templates: https://github.com/PokeAPI/pokeapi/tree/master/templates

The 404 page might be useful as well: https://www.netlify.com/docs/redirects/#custom-404

Requirement: since we're using Netlify's Open Source plan, we need to give them proper attribution. An inclusion of their [logo[(https://www.netlify.com/press/) should do the trick, or maybe a "hosted by Netlify" statement in the footer.

[cmmartti]

Should the pokeapi.co portal be moved to a separate project? To me, it doesn't really make sense to keep it with the API. We would need to extract the static pages anyway to host beside the json files, and other people who self-host the API probably don't need or want the site portal.

What do you think?

[tdmalone]

^ I think that's a good idea. They're two different projects: a website, and an API =]

[neverendingqs]

I like the idea, but I'm not sure how to combine the two at deploy time if they are in two separate repos. Thoughts?

[sargunv]

The deploy script can simply clone all relevant repos and copy all the static files it needs into a single location

[neverendingqs]

The deploy script can simply clone all relevant repos and copy all the static files it needs into a single location

That's not available out-of-the-box. We can manage deploy keys, but I think it would be best to just put them in a different directory in this repo to keep things simple. We can always split them up at a later time.

[sargunv]

That's not available out-of-the-box.

Not sure what you mean. Netlify's build system appears to give the option of running any arbitrary command (and if not, another CI system certainly will) so it's just a matter of cloning relevant repos and cp. Am I missing something here?

[neverendingqs]

Sorry I forgot that all our repos are / can be public. I'm used to working with private repos at work, which means having to manage credentials / deploy keys to be able to clone another repo.

I still think it's simpler to manage everything in one repo, but I can support either option without the credentials issue.

[tdmalone]

If it adds complexity maybe it’s worth keeping them together until we’re up and running on Netlify and then we could look at the pros/cons of splitting them?

[cmmartti]

How about putting the website in a different Netlify server all together, then set up a proxy in Netlify to redirect requests from pokeapi.co/api/ to api.pokeapi.co? That way both projects can be kept completely separate and can be updated separately.

[cmmartti]

By the way, I'm still interested in doing this. Not sure why it shows that I'm unassigned.

[sargunv]

I'm actually unable to assign you for some reason.

[neverendingqs]

Hmm probably because you got bumped from the org because of the 2fa thing (#350 (comment)). Sorry about that.

I think you can re-add yourself once you get back in.

[tdmalone]

Re setting up the proxy, should the new canonical API URL be api.pokeapi.co, and the proxy just be used for backwards compatibility?

Over time, this should then reduce reliance on the proxy - and theoretically increase speed (slightly) and avoid duplicating the bandwidth usage (if that’s how it works) across the two sites. Right?

[cmmartti]

That's a good point about the performance hit of the proxy. I agree that the canonical API URL should be api.pokeapi.co. We can put up a message on the website to ask users to switch to the new URL and keep the proxy live indefinitely.

Also, is there a way we can track the usage of each URL? (Perhaps that should be a new issue.)

[neverendingqs]

I have added the following to this issue:

Requirement: since we're using Netlify's Open Source plan, we need to give them proper attribution. An inclusion of their [logo[(https://www.netlify.com/press/) should do the trick, or maybe a "hosted by Netlify" statement in the footer.

I thought it fits well here, but we can spin this into its own issue if that works better.

[cmmartti]

What should I call the repository for this project? Right now I have "pokeapi-co-website". Does that work?

[tdmalone]

@cmmartti Maybe just ‘pokeapi-website’? I usually wouldn’t put the domain in the repo.

[cmmartti]

The reason I included the domain is because for all intents and purposes, the website is the domain, and it is unlikely that the official site is ever going to move from pokeapi.co. Just like the reactjs/reactjs.org and vuejs/vuejs.org repositories. In the same spirit, I favour "pokeapi.co", but I suppose the name is not important, just as long as it's understandable.

Also, licensing. I am using Gatsby (static site generator based on React), which is licensed as MIT. The main PokéAPI repo uses the 'BSD 3-Clause "New" or "Revised" License' with copyright attributed solely to Paul Hallet. I plan on using the same BSD licence with the copyright as "Paul Hallet and PokéAPI contributors" as suggested here. I copied the copy almost verbatim from the original site, but none of the code is the same. Does that make sense?

[tdmalone]

Fair enough - looks like there is a popular precedent for the domain in the repo 😄

The copyright notice sounds ok to me. But I think I'll open a separate ticket for that to get visibility+consensus.

[cmmartti]

A partially complete version of the static site is now live at https://pokeapi-co.netlify.com/. It is built using Gatsby, a static site generator for React.

For now, there's a placeholder in place of the logo in the header, the documentation pages are empty, and some minor styling is missing (in the About page). The proxy redirect of /api to the old API works fine, as well.

[phalt]

Nice work @cmmartti !

[tdmalone]

Awesome work on this @cmmartti! Is this issue ok to close?

[cmmartti]

Yes, I think we've covered all the bases. Any new issues can be made in the pokeapi.co repo.