acoffman
commented
1 month ago Hi Tek,
Thanks for your interest in CIViC and apologies for the delayed reply; I just returned from vacation. We do not have any formal documentation about using the CIViC codebase in other contexts, though it is MIT licensed and anyone is free to use it for their own purposes. I am happy to outline the basic architecture of the application though, and hopefully that will be useful to you.
The repository contains two separate applications, one in /client and one in /server. The client application is what powers the UI viewable at https://civicdb.org and is an Angular app written in Typescript. When we deploy a new version of CIViC, this action will build a static production build of the application using yarn and include it in the deployment. It is served from AWS as a static asset via nginx.
The /server directory contains a Rails application which serves a GraphQL API. It utilizes Postgres for data storage and Redis for caching and queueing background tasks. Puma is used as the application server and Sidekiq is used to process the task queue and scheduled/recurring jobs which is more or less the default Rails architecture.
The frontend is very tied to the API schema and probably would not be particularly useful without running the server, though you could in theory run the server and build an alternate frontend on top of it. Every feature in CIViC is available via the API.
As for switching out the data store, we use ActiveRecord as our ORM. This means it should be fairly trivial to switch between relational database engines (mysql, postgres, sql server, sqlite, etc) but switching to a document store such as mongo would require significant reworking of the data model. You could swap in Mongoid as your ORM, but our schema, validations, and data are fundamentally relational in nature so you would have to adapt them to work in the document model.
As mentioned above, our code and data is freely available for anyone to use and modify for their own purposes but in its current state, the codebase is designed specifically around the CIViC evidence model and curation workflow; it hasn't been designed to be a generic platform for other models or workflows. If you wanted to start modifying it for other purposes, I would take a look at /server/app/graphql/mutations to see what functionality is currently available and trace its execution through the codebase. Generally speaking a mutation will perform some authorization and data validation, then call an Activity which in turn may call multiple Actions (found in /server/app/models).
Hopefully this was helpful and let me know if you have any additional specific questions about the application's architecture.
Thanks, Adam
Hi Team,
Thank you for your great work. I'm interested in reusing code for a different project/use case. Unfortunately, I have not found documentation that specifically addresses reusing particular components (e.g., client-only or both client and server) by your established architecture and design principles.
Could you please confirm if there is existing documentation on adapting your code for other use cases or projects? I was unable to locate such information on civicdb.org. In particular, I am interested in guidelines on:
If no formal documentation is available, any tips or considerations you could share for developers looking to modify your project would be immensely helpful.
Moreover, I also think that these instructions would be beneficial to the community.
Thank you for your assistance!
@acoffman
Best, Tek