-
Notifications
You must be signed in to change notification settings - Fork 10
Developer guide
This page introduces anyone interested in contributing to the HIS-EMR-API through the applications structure, data model, and other concepts to help you get started.
Setting up the application for development is covered in the deployment page. Please go through that first before proceeding. In addition to the requirements specified in the deployment guide, you may find the following useful:
The tools listed above provide linting and intellisense sense capabilities for most editors. If you use vscode, the following extensions work with the two tools listed above:
Postman is recommended for manually testing the API. A postman
collection containing endpoints and example requests is provided with the application. It
is located at doc/src/index.json; import this file into postman.
The following is the directory structure of HIS-EMR-API application (with some unused directories ommited).
.
├── app
│ ├── controllers
│ ├── exceptions
│ ├── jobs
│ ├── models
│ ├── services
│ └── utils
├── bin
├── config
├── db
│ ├── data
│ ├── initial_setup
│ ├── migrate
│ └── sql
├── doc
├── lib
├── log
├── public
├── spec
├── swagger
└── vendor
The structure is that of a typical
Ruby on Rails application with slight
additions. Under the app directory are the exceptions, services, and utils directories.
app/exceptions just contains various custom exceptions used through out the application.
For example, if we need to flag an error communicating with an external service, a custom
GatewayError exeption is raised. These exceptions can then be handled at the controller
level with an appropriate error that's reported to users. You might want to see
app/controllers/concerns/exception_handler.rb
for how the exceptions are handled globally.
The app/services directory contains Plain Old Ruby Objects (POROs) and modules that make up
the business service layer of the application. Controllers are simply used as a glue layer
between the outside world and the service layer. Controllers get requests from users, process
them and forward them to the necessary service object/module to do its thing. The reasons for
this are best explained
elsewhere but from
our experience we find this approach eases unit testing and we don't have to think too much
about where to place a method in cases where the method cuts across multiple models.
In other words, service objects provide us a context for a given operation
(for example you will find everything to do with drug dispensations under a dispensation
service not models/drug_order, models/observation, nor models/patient).
app/utils contains various utility methods used across the entire project. These range from
basic date processing operations to helpers for concurrency. These methods do not carry
any domain logic, they could as well do in the /lib directory. The stuff from this
directory is usually included in service objects/modules.
Under db are the data, initial_setup, and sql directories. These contain various *.sql
files used to initialise the database. They were imported from the old ART application, most of
these files are not used but no one is yet to summon the courage to get rid of them.
doc is supposed to contain the project's documentation and the source files for the
documentation. doc\src contains a postman collection that can be loaded into postman.
Finally, spec contains the applications unit tests.
[TODO]
[TODO]
[TODO]