diurnalist / ourkino Goto Github PK

There is no real reason for this, except for my own learning.

Some changes from the initial design I'd like to make:

• Provide location configuration as separate YAML files; have the tool output the schedule either in CLI or HTML output w/ a configuration file as input. Input file will have the location name, timezone, and a list of theatres to pull from. Each theatre configuration will have a name, scrape driver, and scrape driver parameters, which will be specific to the scraper.
• Formalize the scraper interface a bit more; instantiate a scraper with its parameters and execute the scrape w/ the target date as the input. Output should be a list of showtimes. Showtimes should have the theatre name, showtime name, language information, date and time (timezone-localized) and a deeplink to more information about the film.
• Consider using a work queue for issuing scrape requests to have a way of limiting request throughput. Such a queue could be injected on the scrape call.

Basic architecture:

1. Command layer parses arguments and configuration input and instantiates all the necessary scrapers and handles writing error responses.
2. Scraper layer issues HTTP requests and parses the response however it needs to, ultimately returning a list of showtimes.
3. Render layer takes the showtimes, arranges them however and writes out some sort of response, either to console or external file.

Other notes:

• Use golang net/html library for HTML parsing