README.md (2796B)
1 # Service Status App 2 3 ## How to run the app 4 5 Without Ansible: 6 7 ``` 8 docker build python_app -t service-status-app 9 docker run -p 8000:8000 service-status-app 10 ``` 11 12 With Ansible: 13 14 `ansible-playbook playbook.yml -i hosts` 15 16 This will build an image, and then start the app or restart it if it was already running. 17 18 ## Possible improvements 19 20 ### Mitigate denial of service exposure 21 22 First off, there is a denial of service opportunity where if a client calls our app very frequently, we will make many requests to GitHub which could lead to us being rate limited by GitHub and our app wouldn't be able to provide service anymore. 23 24 Either we could make the service handle load much better if we fetch the GitHub status data periodically in a scheduled background process or similar, and to memoize that response for serving to our clients, or alternatively we could put some kind of reverse proxy like Varnish in front of our app and configure it properly to limit the amount of requests that our app has to perform. 25 26 I would tend to prefer the first option as it is simpler to implement. 27 28 ### Log timestamps 29 30 We could look into adding timestamps to log lines. 31 32 ### Upgrade outdated dependency management solution 33 34 Possibly we could look at swapping out the pip/venv tooling in favor of uv, which seems to be the industry standard recently. We should take into consideration whether there is an established practice in the organization. For the exercise I decided to ignore uv and use only pip / venv, working under the assumption that these are the widely used tools in the rest of the team. (Note I'm not super up to date with Python tooling, so might be in a bit of deep water here. I understand there might be all sorts of opinions on this subject.) 35 36 ### Dynamic configuration 37 38 I also considered whether we ought to extract the configuration for STATUS_URL from the app in order to be able to configure that from outside of the app, for example via an environment variable set in the Ansible playbook, but I don't really think this would make sense in this little app at this point, especially since it can't have any other value than the GitHub endpoint. 39 40 ### More explicit error handling 41 42 One thing that I think makes the app potentially a bit flaky is the catch-all exception handling on line 25. It will cause the app to return a 500 "Failed to fetch status" error regardless of what has happened, for example if GitHub status API is not responding at all, or if the format of data has changed so that we fail to parse the response, or we have some other bug, or anything else. I would probably have tried to be a little more explicit in this error handling, then again the use case is hypothetical so it would have entirely depended on what kind of level of service we were required to provide.