Build Your App

Interested in using AidData’s data to create your own tool, app or visualization? The rules below provide some guidance on how to proceed. If you'd like to request that your tool, app or visualization be featured on aiddata.org, please contact us at data@aiddata.org or join our Freenode #aiddata channel. 

Quick Stats

Use Quick Stats to search for information about a donor, country, sector and more.

by Donor

Loading...

by Country

Loading...

by Sector

Loading...

Technical Guidelines

Technologists, software developers, and data visualizers/analysts who want to interact with our API, related services and/or data should keep in mind the following guidance on our architecture. AidData's API is a RESTful API, built in NodeJS. Our database engine is MongoDB, but most of the query work is done by Elastic Search. This combination of document oriented database plus an Apache Lucene-based search engine gives us the flexibility needed to handle a variety of requests while still maintaing very good performance.

Applications should receive input as a feed (json), i.e. our API or other feed, or by file. See our research releases for downloadable files. Apps should preferably run visualizations directly from one of our feeds (json) to allow for future format changes or updates to the data. If you do decide to store data on a local database preferably use MongoDB, but MySQL and PostgreSQL also work. Just be aware that storing data on a local database means you either have to continually refresh the data or risk having outdated information in your application

Rules for Creating New Apps

1. Follow a service-oriented architecture

Design your application with the mindset that it could plug into the AidData 3.0 architecture and consume services we plan to develop. Apps should integrate with the AidData 3.0 API or file (i.e. our AidData 3.0 Research Release). Contact us at info@aiddata.org or on our #aiddata Freenode channel if you are unsure of the best method for your app, or if you have questions about the structure or content of the data.

Apps should preferably run visualizations directly through our API to allow for future format changes or updates to the data. If you decide to store data on a local database use MySQL, PostgreSQL, or MongoDB. Keep in mind that storing our data on a local db means you either have to continually refresh the data or risk having outdated information in your app

2. Select an appropriate suite of languages

If creating a custom app, a model-view-controller (mvc) pattern is highly preferred. Use one of the following core languages: java, php, or javascript frameworks (i.e. Backbone or Bootstrap). If creating a visualization, use html5 technologies (i.e. javascript) rather than Microsoft Silverlight or Flash.

If creating an app based on a framework, use js frameworks (i.e. Backbone [preferred] or AngularJS) or a module-based CMS, such as Drupal,  which can support our data. If creating a geospatial app or visualization, use a geo-server (with PostGIS storage) or ArcGIS suite.

3. Build with performance and scalability in mind

All pages should load under 5 seconds and apps should be able to easily work with at least a million data points (and growing).