Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using external data (APIs) as an optional replacement for CSV files #859

Open
brockfanning opened this issue Jan 19, 2018 · 6 comments
Open

Comments

@brockfanning
Copy link
Contributor

@philipashlock @Kali2017SDG
I'm starting this issue to correspond to the "Database Linking" item in the development priorities. There has been discussion of allowing for external data, through API calls in javascript, as an optional replacement for the CSV file approach. This would allow the use of this platform along with a completely decoupled data management system.

To get started on development, we'd need some real-world use-case to development against - preferably a public API that's already out there. In #852 @soho501 mentioned the SDG API, which has a non-final test version that seems like a good first candidate.

@brockfanning
Copy link
Contributor Author

@SmithersA ^^

@brockfanning
Copy link
Contributor Author

@philipashlock @SmithersA On second thought I shifted over to a build-time approach, rather than run-time with javascript. It seemed like a re-architecture of all of the data visualizations (tables, line graphs, bar graphs, etc.) to use an abstracted data-grabbing function would have been a lot of work, and also carry a performance cost. Instead, I thought I'd first go with a build-time approach of importing data with a server-side script and saving it as CSV data in whatever way the platform already expects.

I've put up an example script as a pull request: #861

@soho501 FYI this example script used the SDGAPI as a data source. Hopefully I didn't hammer the API servers too much while testing it. :)

@brockfanning
Copy link
Contributor Author

@philipashlock pointed out an inherent limitation of the build-time approach: the data could frequently be out-of-date in between site builds. Let's explore the run-time approach too.

@brockfanning
Copy link
Contributor Author

brockfanning commented Feb 12, 2018

@philipashlock @SmithersA #887 is meant to provide the basis for a run-time approach to external data sources.

@brockfanning
Copy link
Contributor Author

@philipashlock @SmithersA #901 is a next step here - showing a proof-of-concept of getting data from a CKAN service. More details are in the pull request.

@brockfanning
Copy link
Contributor Author

@philipashlock @SmithersA I've updated #901 with a demo of the CKAN data source here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant