An Overview Of The Kinship Internal System
Kinship's internal API is built around a number of reusable classes & methods within them, focussing on using as little code as possible. A lot of the time, situations require the same methods with slight variations. Functions are created with this in mind, accepting as many parameters as possible and internally sorting through them. This allows common calls, callbacks, etc to be wrapped in large functions that can be used everywhere throughout the codebase.
Within the codebase, there are three large folders that allow us to make sense of this.
If you are a developer that is not trying to clone the entire project and just make the development process, this is the main folder that contains logic you would probably use.
This folder contains core objects, such as the
StripeResponse objects, and more. These objects contain logic to handle possible variations and abstract away work for both donors and charity admins, including for various types of donations (CC charges vs eTransfers), user states (e.g. matching donations to users that were not logged in but later did log in), etc.
Additionally, these classes can also represent common
Events at charities, such as donations being made, donors updating profiles, manual tax receipt resends, and more. This allows a comprehensive, streamlined representation of all activity in the charity, which can be reliably presented and requested.
This folder contains logic for combining classes for various situations. For example, building a
Donation object from raw stripe data, logging events, updating donor profiles, sending notifications, etc.
You can think of this folder as code that puts together classes to allow the charity to actually function. This setup also allows easy integration of new features, as they can generally be built using classes their builtin methods, meaning very little boilerplate is required.
Finally, functions are exposed and called by the API, which takes in parameters and determines which functions to call. This system also ensures events are triggered, provides a response to the frontend, etc.
There are three main API routes:
/donation: These contain donations relating to fetching, updating, & creating donations, as well as notifying users and more.
/donor: Routes under
/donorsdeal with donor-oriented requests, including fetching donations for a user, creating or updating a donor profile, admin tasks such as password resets, and more.
/admin: These are routes designed to be accessed by the charity admins, including to generate reports, resend emails to donors, and other such internal tools.
You can read more about the API structure here.