Architectural overview
All information in these pages can be superseded by Scenarios and Code in the actual application. These pages are to give a general understanding of the system, although it would be nice if these pages were kept up to date. If you find that the information here is misleading please notify us by the google group so that we can at very least remove it!
- CouchDB store
- Ruby / Rails Front End
- Couch Rest Rails library for interaction with the database.
- We have removed active record (sometimes makes things ‘interesting’)
The primary goal of the RapidFTR project is to provide an API interface for any number of mobile devices to up-load and search information related to family tracking and reunification. Primarily this information is details of lost children.
Rails allows us to build the website interface along side the API, adding a few URL’s that are only useful for Browsers ( urls ending with /edit /new).
In an attempt to make client development as pain free as possible we aim to make the API ‘RESTful’. This means that we consider the API to be managing resources of different types. The first recource is that of Child records.
We try to describe actions on these resources by using HTTP verbs as concisely as possible.
Rails helps the API to function with a number of Data Formats (HTTP Form Variables, XML and JSON). We aim to ensure all interaction with the api handles JSON, we do not guarantee support for other formats, and will drop them or functionality with them if doing so adds any complexity to the system.
RapidFTR’s primary purpose is to collect information on children, in the system these are instances of the Child Model object. RFTR aims to be very flexible in the information we gather to ensure RFTR can be taken up by any NGO doing FTR work. This has driven the decision to use CouchDB as the backend and so has meant that the Child object has to be equally flexible.
As such the Child object is essentially a hash of the data we gather about a Child. On top of this goes any logic we must apply to that data. This includes things like validating the bare minimum of information we must gather on a child.
For more information on this and other entities see their own pages here Key entities or better yet their code!
In order to effectively gather information there does have to be some agreed structure to the child records. The system’s primary use for this information is to layout forms in the case of the website. Clients can also access this information for hints on how to render data gathering forms. The basic interaction of this information with the API looks something like this:
