Because our root index.html (and really our whole site!) only changes after populating articles, it's advantageous for us to generate pages ahead of time once we've populated the DB, rather than making Django rerender the same page every time there's a request for it. As we've seen with #68 and #81, when our app engine goes to sleep it can often take 3-5 seconds or more for our instance to wake up, request the article data from the db (which may have also gone to sleep), and render the page. This way, we can serve content immediately upon request without waiting for instances to wake up (I tested this and confirmed that fetching static files isn't affected by the state of our instances). This should completely bypasses any cold-boot concerns for the pages we apply it to!
Implementation
Right now I've only applied this for the index.html page, since that's the page most likely to be the first requested by users and search engine crawlers. We could do this to other pages if we wanted to.
After running the article population logic, the index.html page is generated and saved to the static files directory. Note: in production, static files are served from the "staticfiles" directory (created and populated by manage.py collectstatic), not "static."
index.html was updated to make the csrf_token optional. Since we're generating one static HTML file, we can't include this.
If the CSRF token is provided, index.html will be functionally the same as it was before.
If the CSRF token isn't provided, the feedback submission form will be disabled. After loading the page, a token is fetched and inserted into the form, and the form is enabled. This request has a secondary benefit of waking up the server instance if it's asleep, which means we get the best of both worlds: an immediate response to a request for the root index, and an awake server instance ready to handle the next requests.
A new routing rule was added to app.yaml to grab the static index.html file for requests to "/" and "/index.html." I was careful to leave the existing index view alone and make sure the template was still compatible with it so we can easily turn this off just by editing app.yaml, and everything will (should) go back to the way it was.
Other notes
The find_articles query doesn't seem to require a CSRF token, so I removed it from that form. But it would be easy to insert one into it like the use case form.
Resolves #68 and tables #81.
Context
App engine has great support for static file hosting: https://cloud.google.com/appengine/docs/standard/hosting-a-static-website
In fact, we're already using it for our static files: https://github.com/dtinit/portmap/blob/f7203d86cdcc58c6223ff1b132f5e6144fad7974/app.yaml#L4-L8
Because our root index.html (and really our whole site!) only changes after populating articles, it's advantageous for us to generate pages ahead of time once we've populated the DB, rather than making Django rerender the same page every time there's a request for it. As we've seen with #68 and #81, when our app engine goes to sleep it can often take 3-5 seconds or more for our instance to wake up, request the article data from the db (which may have also gone to sleep), and render the page. This way, we can serve content immediately upon request without waiting for instances to wake up (I tested this and confirmed that fetching static files isn't affected by the state of our instances). This should completely bypasses any cold-boot concerns for the pages we apply it to!
Implementation
Right now I've only applied this for the index.html page, since that's the page most likely to be the first requested by users and search engine crawlers. We could do this to other pages if we wanted to.
After running the article population logic, the index.html page is generated and saved to the static files directory. Note: in production, static files are served from the "staticfiles" directory (created and populated by
manage.py collectstatic
), not "static."index.html was updated to make the
csrf_token
optional. Since we're generating one static HTML file, we can't include this.A new routing rule was added to app.yaml to grab the static index.html file for requests to "/" and "/index.html." I was careful to leave the existing index view alone and make sure the template was still compatible with it so we can easily turn this off just by editing app.yaml, and everything will (should) go back to the way it was.
Other notes