In January 2023, during donate-neo's design phase, our CiviCRM
consultant [suggested](https://gitlab.torproject.org/tpo/web/donate-static/-/issues/107#note_2872743) looking at a CiviCRM extension called
[inlay](https://lab.civicrm.org/extensions/inlay), "a framework to help CiviCRM extension developers embed
functionality on external websites".
A similar system is [civiproxy](https://docs.civicrm.org/civiproxy/), which provides some "bastion host"
approach in front of CiviCRM. This approach is particularly
interesting because it is actually in use by the Wikimedia Foundation
(WMF) to handle requests like "please take me off your mailing list"
(see below for more information on the WMF setup).
Civiproxy might eventually replace some parts or all of the Django
app, particularly things like (e.g. `newsletter.torproject.org`). The
project hasn't reached 1.0 yet, and WMF doesn't solely rely on it.
Both of those typically assume some sort of CMS lives in front of the
system, in our case that would need to be Lektor or some other static
site generator, otherwise we'd probably be okay staying with the
Django design.
### WMF implementation
As mentioned above, the Wikimedia Foundation (WMF) also uses CiviCRM
to handle donations.
Talking with the `#wikimedia-fundraising` (on `irc.libera.chat`),
anarcat learn that they have a setup relatively similar to ours:
- their civicrm is not publicly available
- they have a redis queue to bridge a publicly facing site with the civicrm backend
- they process donations on the frontend
But they also have differences:
- their frontend is a wikimedia site (they call it donorwiki, it's
<https://donate.wikimedia.org/>)
- they extensively use queues to do batch processing as CiviCRM is too
slow to process entries, their database is massive, with millions of
entries
[This mediawiki plugin](https://packagist.org/packages/wikimedia/donation-interface) is what runs on the frontend. An
interesting thing with their frontend is that it supports handling
multiple currencies. For those who remember this, the foundation got
some flak recently for soliciting disproportionate donations for users
in "poorer" countries, so this is part of that...
It looks like the bits that process the redis queue on the other end
are somewhere in [this code](https://gerrit.wikimedia.org/r/c/wikimedia/fundraising/crm/+/1002753) that eileen linked me to. [This is the
CiviCRM extension](https://gerrit.wikimedia.org/r/plugins/gitiles/wikimedia/fundraising/crm/+/refs/heads/master/drupal/sites/default/civicrm/extensions/wmf-civicrm) at least, which presumably contains the code
which processes the donations.
They're using Redis now, but were using [STOMP](https://stomp.github.io/) before, for what
that's worth.
They're looking at using [coworker](https://lab.civicrm.org/dev/coworker) to process queues on the
CiviCRM side, but I'm not sure that's relevant for us, given our
lesser transaction rate. I suspect Tor and WMF have an inverse ratio
of foundation vs individual donors, which means we have less
transactions to process than they do (and we're smaller anyway).
