It is recommended you run this project in a Python virtual environment. After cloning, install the packages with pip install -r requirements.txt
and then flask run
to run the app. You can also run it in development mode with python app.py
, which will use the mock environment variables found in .flaskenv
.
The api keys for each individual 3rd party service (HouseCanary, etc.) are labelled appriopriately in .env
. The base URL's of each specific 3rd party service you want to access are appropriately labeled under .flaskenv
.
- GOAL: prompt homeowners with an additional question if home has a septic system.
- we want to leave the web app implementation alone:
- assuming they want to leave FE engineers alone
- make the aggregator at the backend, instead of the web app talking to multiple 3rd party API's
- make that information available through a custom API endpoint you design for our web app to use.
- building this a GraphQL aggregate data layer if this was going to be pulling from many individual data sources
- returning only a boolean, instead of a True/False/None
- there might a scenario where the API user might want to know if we couldn't verify if our response is accurate
- implement authentication and authorization at Flask level
- check out flask convention/native flask modules (if any) for security
- setup Docker so the API is built inside a container for scalabiliy
- basic MAKEFILE command for
docker-compose
shorthand
- basic MAKEFILE command for
- actual factual HTTP request to HouseCanary if given credentials
- unit testing in whatever native testing module Flask has (if there is one)
- caught off guard by global context variables such as
request
, feels weird to import something to the global scope without declaring it, or passing it in- I assume it is just similar to how the browser provides the
window
object auto-magically to most frontend apps
- I assume it is just similar to how the browser provides the
- Flask was straight forward, but mocking a proxy and it's response in unit testing less so
- Unsure of nature authentication/authorization
- unlikely that this app would store it's own variation of users/uer info
- would use existing organiation's authentication/authorization
- need to include scenarios where the 3rd party API's might require an api key per user in the organization