Hello Indico,
We are a group of Iowa State Students; our group has been exploring and analyzing your codebase from a software architectural perspective. We have attached a Google doc where we have outlined our findings. Please leave us feedback on our work and the feasibility of these changes. We would love to hear from the community!
Hi, the proposed change would not be very useful as there will never be a third group type - local groups are groups implemented in Indico, and multipass groups are groups coming from our authentication library (flask-multipass). So all group functionality is covered by those two. Adding interface classes or a factory classmethod just makes things more complex.
Your analysis of the architecture is a bit too simplified; for example caching is only used in very specific places where it provides a somewhat big performance gain. For example, multipass group membership checks are cached, because in case of backends like LDAP, the overhead of checking membership is not as negligible as a normal Postgres database query.
indico.web.http_apiuses this for external API integration.
This is the (legacy) API Indico offers to external consumers. It does not integrate external APIs.
Many other modules utilize these RESTful APIs, and there are many included APIs.
This particular API is not used internally at all - the internal APIs are typically part of the regular controllers, much closer to how a normal Flask app works, instead of this weird “http api hook” system (which I wrote together with a colleahue about 14 years ago when both of us were much less experienced).