Static site generator

[cuducos]

This PR focuses on simplifying the production stack needed to deploy this web site: instead of a Python back-end and Redis, the proposal is to switch to a static site generator. Code reviewing this PR could be troublesome because there's a lot of changes, but the summary is:

1. Drop stuff that makes no sense in a static site generator:
   • asyncio web framework (a574bad)
   • cache (7783e9e)
   • HTTPS (de4cab5)
   • compression of HTTP responses (e9ab029)
   • Heroku deployment files (aa43aac)
2. Minor improvements:
   • updating Python (d4e262b)
   • using Pipenv (35454f4)
   • simplifying the Dockerfile (7577ff5)
3. Implementing the static generator (ad35ce2)

If this looks like a good approach, one it's on master I can try to set it up on Netlify or GitHub pages, for example.

When code reviewing I suggest two (non-exclusive) strategies: first is to review commit by commit to focus on smaller sets of changes; second, to follow the instructions on the updated version of the README.md.

[cuducos]

Update

With f12bd71c1365bf4231850da37c3bcce58b70755c we're already using GitHub Pages. I've updated the DNS and http://www.vitimasdaintolerancia.org/ is already being served by GitHub.

Disclaimer

First I tried @netlify, but as they do not support Python 3.7 and as we use dataclasses (only available — natively — in Python 3.7) and as they do not support Pipenv, I decided to give GitHub Pages a try. Although I was unable to remove @netlify checks from this repository. What I've try:

1. deleted the site on Netlify
2. removed webhooks from this repository here on GitHub
3. restricted access to Netlify on this repository (GitHub organization settings)
4. changed the HEAD and forced a git push to trigger a new build

But stills… Netlify is running FIVE checks on this pull request. Any ideas how to remove these checks as we're not using @netlify anymore?

Now every check is gone, including Travis and Code Climate. Aff.

Todo

I think that if this PR is approved and merged we can close:

1. 35: Python was already updated here (to a newer version than in this other PR)

2. 27: as SSL would not be a matter for this repository anymore

[sergiomario]

@cuducos I've checked the static content generation template and it looks okay. But, I have a question, you implemented static generation in Flask because the framework API is similar to Sanic, right?

I asked because I see simpler implementations with pelican, for example. But I think you should have chosen to keep an architecture similar to that drawn with Sanic.

[cuducos]

Good point. I think there is a two-fold advantage in using this strategy (i.e. Flask + Freeze):

• It's the simplest implementation at this point: as the web app was written in Sanic (which is basically an asyncio fork of Flask), it was easy to transform it in a static site generator without bordering about adapting the whole architecture to Pelican's architecture;
• It's the simplest way to allow us to revert this back to a web app: if in the future we want to have it as a web app again (let's say, implement a CMS, dynamic search and filters or whatever), the web app is ready and we'd just need a Procfile to spin it up at Heroku again