activist backend planning

[andrewtavis]

Terms

• [X] I have searched open and closed issues
• [X] I agree to follow activist's Code of Conduct

Issue

This issue will serve as a discussion of how to implement the backend of activist in Django. Topics could include:

• Structure of the backend
• Data structures
• How to connect it with the frontend effectively
• Dependencies to add
• Switching the deployment from Netlify
• ...

Once specific tasks are defined by the community we can then make issues and begin on development 😊 Thanks all for any ideas!

[andrewtavis]

For this point above:

• Switching the deployment from Netlify

It would be really good to define the exact set of changes that would happen for the change to need to happen :)

[andrewtavis]

Steps to consider for the meeting:

• Goal: we have an admin setup that allows us to make organizations, events and resources and see them reflected on activist for testing

---

• Defining the tools we want to take advantage of (based on those that are outlined)
  • Which tools then make Netlify not able to be used? (changing of deployment methods)
• Defining diagrams that should be made and presented to the community (database, flows, etc)
  • Can we find an example somewhere that we can base our own off of?
• Defining rights that would eventually be for organization admins

[andrewtavis]

Another thing to account for is the ways that user will be able to sign up:

• User name, email, password and verification
• Username, password, secure verification (in person or via encryption service outside of activist)

[5ud03r5]

Hey @andrewtavis! I would love to work on backend for activist. My first question here would be why do we want to proceed with such big framework as django? FastAPI seems to be much suitable for Activists. Then to migrate it from netlify we can use any cloud provider like GCP to structure it accordingly. For deployment integration we can use Github Actions or GCP build functionality.

Let me know if you like it and want to hear more regarding implementation/structure details with tools I suggested above!

[andrewtavis]

Hey @5ud03r5! Great to hear from you! 😊

Generally with Django we're thinking that a lot of the data control and security that's built in would be something that would lend itself to platform that has to focus on security. With that being said, FastAPI was the other option as Flask doesn't seem to offer enough out of the box functionality. I agree that the templating from Django is a bit overkill though and FastAPI lends itself a bit better for integration with Vue. Not sure. I honestly was thinking more to go with the more popular one and I really shy away from larger frameworks that are not org managed like FastAPI that has a very shallow dev base.

Regarding Netlify shift: the big thing is that we're trying to avoid as many larger firms like Amazon or Google as possible, but then let me say that we will use their services if it comes to it and there isn't a valid open-source alternative. GCP would likely have the edge over AWS, but then the goal is for neither. Glad to have you in this discussion though!

As of now for the initial backend work we're doing this now in #207 and the PR #209. If you wanted to write in #207, that would be where the discussion should happen as the other two contributors who are active in the backend planning are in there :) :) This issue will likely get closed when #207 is :)

[5ud03r5]

@andrewtavis IMO these are not the arguments of choosing Django over FastAPI. As you noticed Django comes with a lot of built in features which most likely wont be used. Fastapi in the end is a combination of other well known libraries. It is highly customizable and have well strucuted docs. I have exp in both and spend much more time investigating issues relating to Django than to FastAPI. Im currently working with FastAPI on a big project and actually didn't use fastAPI community support even once.

In terms of Cloud solutions i thought rather about a place to store and manage data. In the end you will need to have such place. Big cloud companies comes with a lot of cool features, but i understand we rather want to choose some open source solutions.

Btw have you heard about supabase? Maybe BaaS solutions for backend will fit better here? They comes with pre built functionalities and Nuxt actually even have a library to integrate supabase with.

[andrewtavis]

Let me tag some people in this issue 🙃 (@wkyoshida, @momanyisamuel)

The idea of strong docs, async out of the box and integrated type checking is quite appealing :) I appreciate that you've used both and prefer FastAPI. We've also had a couple other people bringing this up, and especially in the Berlin community it is very much a thing given the main dev is here as well.

Let's wait on a checkin from the two tagged above. If memory serves me I was the main voice in favor of Django because of wanting to go with a more mature framework. With this being said we did go with Nuxt for reasons of ease of adoption and dev experience, so maybe I'm just not seeing it here because I'm worried about long term support that might be unwarranted. The effort that's gone into the backend already in #209 is also a factor, but then if the switch is gonna happen it's now or not for a very long time.

Supabase is definitely in my periphery as something that we'd consider adopting, especially given the Nuxt integration. Nice to get another vote in favor of it 😊

Again thanks for your thoughts, @5ud03r5! Really is nice to hear from you again :)

[andrewtavis]

Another factor in this that I'd actually like some feedback on is how often FastAPI needs security updates, because from experience with Django just being in the repo it's on a weekly/biweekly basis... This again might be security being more of a factor because of more overall use, but then a more modern framework might have fewer holes.

[andrewtavis]

But a further note on this is that the choice is not explicitly for Django but for it, Django Rest Framework with auto documentation and other tools in this ecosystem (including easy async support and type checking). Along with this is the Django ORM and admin site :)

The breakdowns always say Django for larger projects and FastAPI for smaller ones, which might also not factor that we inherently have Vue/Nuxt for a lot of the work for a fullstack. We can also use other ORMs for FastAPI and there’s also an admin panel from a third party that seems to have good support.

[wkyoshida]

Hey @5ud03r5 and @andrewtavis ! :wave:

I've only used Django before, so I might not have a concrete opinion comparing both frameworks as @5ud03r5 might, but I'll say this at least. From what I gathered trying to understand the use-case for activist, security is a pretty core pillar when thinking about how to approach the project. FastAPI does have some very clear benefits that I see (many that intrigue me as well!), but I was perhaps willing to go with Django more so for the trade-off of being more robust and mature regarding security, account management, etc.

I'm definitely open to discussion though! Would love to hear what others have to say. Just adding a thought here.

[andrewtavis]

Especially if we go with supabase, which I have cursorily added into a grant proposal to earmark it (why not? 😊), we'd really only be needing the backend for a portion of what it'd normally be used for. I guess in that case it wouldn't really matter too much what we go with, but then in that case sticking with the standard and building something advanced over it might be best? 🤔 Or is that only adding to the overkill? 😅

[5ud03r5]

This is my sum-up so we can agree on one solution. I'm happy to work with both btw, just giving my thoughts and some suggestions maybe.

Regarding Supabase - That's actually the best option in this kind of development. I'm a fan of BaaS solution because you don't actually care about anything, just integrating it with your code and it works. It is also suprisingly quite customizable, you can essentialy define db tasks/triggers and so on. Sadly it somehow limits you to choose a database which is underneath the BaaS solution, in case of Supabase it is pgsql. There are however alternatives like Firebase which support NoSQL model and MongoDB cloud which also supports NoSQL.

Nuxt can be easily integrated using built in NitroJs and provided Nuxt - Supabase libraries (also well documented). btw - it was actually a techonolgy stack in my graduation work - 'BaaS as a alternative for building web based develompent solutions' 😄

---

I will play a little pros and cons game to summarize it from my perspective:

Django pros:

• Easy to implement, it have much of built in functionalities and abstraction levels which are easily readable and deployable.
• Huge community support
• There is a lot of developers who knows how to work with it (at least on a basic level of understanding)
• Scalable
• Admin panel

Django cons:

• Huuuuuge framework - it is overkill for activists. Imagine using Angular for a frontend, it is somehow the same, but Django is even bigger, you can actually create Django only website with Jinja templates and little bit of Javascript
• Easy to learn - hard to master - Yes a lot of ppl know how to deal with it, but it is rather a basic knowledge. You need python + web development + databases deep understanding to actually manage and develop it accordingly in terms of building secure and efficient Websites
• There is a 'Django developer' term and it actually matches the case. No prior python deep understanding to understand Django (on an entry point/basic level)
• No swagger

FastAPI pros:

• Easy to implement - it is actually a combination of various python packages - you essentially can build a simple website with 1 file and by running pip install fastapi uvicorn and then starting uvicorn server
• Scalable
• Easy to manage without a lot of unnecessarily needed functionalities
• Highly customizable - you can basically define your own levels of abstraction
• Swagger

FastAPI cons:

• You need to be a python developer to work with it, there is no such term as a 'FastAPI developer', you need to understand python and how things work
• You are a person who builts functionalities, almost nothing is built in, except basic endpoints definitions
• You need to spend more time during architecture planning as it will later affect on your work and rewritting it may be hard and time consuming

---

Django comes with built in security functionalities, which doesn't mean you cannot do the same on fastAPI - it is rather a definition of using appropriate tools and knowledge of what needs to be secured and how to do it. With fastAPI it becomes bit more difficult because you need to actually track each package which doesn't comes with fastAPI and resolve dependencies

[andrewtavis]

As an initial comment I appreciate the inclusion of swagger in the breakdown 😅😊 Will check this later after work :)

[5ud03r5]

yea, Swagger is a pretty cool feature which also comes with Redoc what makes it super readable by anyone who wants to play with it. In the era of social apps like Twitter you can basically use API to make automated posts and so on and Swagger helps a lot here as in the end it is built in super readable documentation of your application

[andrewtavis]

@5ud03r5, one quick thing as I'm doing my reminder rounds: if you have interest we have the activist dev sync today at 15:00 UTC in the following Element Call: https://call.element.io/activist-dev-sync. Would be happy to have you there for the sync and to meet you! Would also be happy to do a call to introduce ourselves sometime in the coming week if you're busy today.

Beyond this, I'm not seeing a user name that's reminiscent of yours in the public Matrix space. Would be great to have you in the Development and General rooms!

Back to the breakdown above

Regarding Supabase - That's actually the best option in this kind of development. I'm a fan of BaaS solution because you don't actually care about anything, just integrating it with your code and it works. It is also suprisingly quite customizable, you can essentialy define db tasks/triggers and so on. Sadly it somehow limits you to choose a database which is underneath the BaaS solution, in case of Supabase it is pgsql.

I agree with this and think that Supabase is the best option. Regardless of backend discussions, Supabase has gotten resounding support from all over the place as a great option that integrates well with Nuxt and will make our lives easier. I also personally have no issue with Postgres, and the benefits of Supabase (cost, OS, etc) well outweigh Firebase just to use a different database.

Points on FastAPI and Django

Looking into FastAPI a bit more it does appear to be being used in production by major companies (Microsoft for ML flows, etc), so in those regards it's not a big deal. The major con for me is still the security ecosystem and a lack of maintainers. There are a lot of "people" who also are making software in its ecosystem (extensions or Starlette, the basis) as well as answering questions, but then the Django ecosystem has a LOT of maintainers that are even consistently doing security audits, which is a level that FastAPI is nowhere near.

If we're going with Supabase, then is there one that integrates better? It looks like both would work fine :) I've got some major decision fatigue with this at this point 🤦‍♂️ Big thing is also we have #207 waiting, and I'd feel bad to throw it out and thus waste @momanyisamuel's time...

A final word for FastAPI

The fact that FastAPI is already just behind Django and Flask in the Stack Overflow professional developer usage speaks loads. Let's get a breakdown:

• 2021: Django 13.02%; FastAPI 3.87%
• 2022: Django 13.59%; FastAPI 6.01%
• 2023: Django 10.88%; FastAPI 7.67%

FastAPI also wins based on 2021, 2022 and 2023 loved vs. dreaded / admired vs. desired comparisons. Responses for FastAPI also jumped from 2021 to 2022 without a big drop in sentiment.

A final word for Django

With the above being said, we also have a handshake agreement with ctrl.alt.coop that they'll jump in when we get funding, and they write in Django (specifically an app in Django and Vue that has similar use cases). This with the maintenance and privacy concerns is quite the argument.

Final thoughts

The above is some nice documentation for this decision, and we'll keep an eye on how the backend infrastructure progresses. Let's stick with Django in the back for now and try to implement as much of it in Supabase as possible such that if the switch should happen, then we can do so as easily as possible. This also grounds us in a standard while also expanding to something new, which is the same approach we took with Vue and Nuxt in the front. Has paid off so far :)

To end on a light note, my preference for any future backend rewrite would actually be the winner between axum and Actix Web 🦀😜😅🙃 Sounds like a fun project for a few years from now 😊

Hope this makes sense! I appreciate the discussion here 🙏😊

[andrewtavis]

Let's use this issue to also discuss any other parts of the backend that we can think of, and from there we can close :)

[5ud03r5]

Hey @andrewtavis, apologies for a delay in response, was on a short holidays. As said, I'm happy to work on whatever you decide to choose. Those were only my thoughts/suggestions. Regarding any meetings/syncs I'm free to join everyday 20:30-23:00 PM CEST, so just let me know 😃

[andrewtavis]

209 was just merged (@momanyisamuel 👏👏), so the basis of the backend is now in there 😊 I'll take some time to look into and setup some things for Supabase on Saturday. I'll report back after that, and would be happy to do a call with someone that day if they have time.

Would be great if we can continue the discussion of future steps in here :)

[andrewtavis]

@momanyisamuel and I are discussing some things for the backend right now 😊 The next big thing we need to figure out is the best practices to implement an event driven architecture. @5ud03r5 and @wkyoshida, do either of you have suggestions on this? I'll let @momanyisamuel also add some thoughts as well :)

[wkyoshida]

Sorry, I haven't kept up with all the backend discussions in a bit, but is the idea then to break the backend into microservices? It's a great approach, but it does add some complexity. So at first thought, I'm a little unsure if it's the architecture that makes the most sense for activist's case.

However, I am curious and open to hear what thoughts are though 😊

[momanyisamuel]

@wkyoshida Just to summarize so you can be up to speed on this, There's already a user on-boarding and authentication service/module that is separate - in progress, Thus in my opinion it would make sense to further split the application further into other standalone services. While implementing this as a monolith to start would be less complex, there's also the consideration that service separation could be more beneficial if implemented now rather than waiting to implement this later - less technical debt. This would also definitely allow for easier integration of the authentication service and any other third party integrations in the future.

[kurtisolo]

Hello, this is the first time I'm contributing here so I hope I haven't missed anything. So, a few considerations: I've used Django quite a bit in the past year, and from my experience, I've always found it very useful to split everything into as many apps as possible. It seems to add complexity to the project, but personally, I find it a good approach, especially when thinking long-term: the sooner you separate the dependencies of the functionalities, the fewer difficulties you'll face later on. The logic I use to avoid getting mixed up is to follow a "one-way" approach when it comes to importing between models: a kind of chain where each link (i.e., each app) can be imported into the next one, but not vice versa. Each link-app can only import from the previous apps (preferably only from the previous one). The more everything resembles a chain, the easier the management and scalability. I always prefer to split an app into two unnecessarily, rather than having to do it later with all the associated difficulties.

My two cents!

[andrewtavis]

Thanks the thoughts, @kurtisolo! Great to have your expertise on the team 😊 Sounds like some solid arguments and structure to me :)

[kurtisolo]

Great. First of all, I'd like to point out that in models.py there are a lot of IntegerField and DateField fields without parentheses (). This needs to be fixed, or it will cause errors during migrations. Having said that, I'd start thinking about how to divide the apps: I like to dedicate an app solely to authentication, which would be a good starting point. Right after that, I'd create the "User" app, which, if desired, can be combined with "authentication". As I've mentioned, I prefer to split as much as possible; it's easier to maintain and individual functions can be optimized better. Each app should contain its own models.py, views.py, etc., to make everything more maintainable. It's a bit laborious to do all this, but once the project's skeleton is set up, it will be robust, easily navigable, and easy to maintain. Here's the standard structure I use for each app:

app_name/ │ ├── migrations/
│ ├── templates/
│ └── app_name/
│ ├── admin.py
│ ├── forms.py
│ ├── apps.py
│ ├── models.py
│ ├── tests.py
│ ├── views.py
│ ├── urls.py
│ ├── signals.py
│ └── serializers.py

[andrewtavis]

Let’s wait on the others to jump in, @kurtisolo, but all’s sounding good to me :) :)

[kurtisolo]

Nice, happy to be here. Anyway those IntegerField and DateField must be fixed, they're not gonna work as they are right now!

[andrewtavis]

You’d be free to send along a PR for those fixes and we can then go from there, @kurtisolo 😊

[5ud03r5]

microser

Django is not really a framework you would like to use as a microservice due to its complexitty. Sadly we are rather forced to use monolith system if we decide to move along with Django. If you really want to move forward with Event driven approach you should rather consider Flask/FastAPI or any other microservice friendly languages like Rust/Go which are super suitable to handle event driven architecture

[kurtisolo]

What you're saying makes a lot of sense, and indeed Django allows for managing everything in a single monolithic app. However, it's advisable to divide larger projects into distinct apps, more or less large and specialized, especially if the intent is to allow for future expansion. In my opinion, the models.py file of the backend contains a considerable number of models, many of which can be grouped into separate apps. Just to give an example, "users", "events", and "organizations" could easily be managed by distinct apps. As I mentioned, this may seem to complicate things, but if done logically and thoughtfully, it will make navigating much simpler later on! Perhaps my approach is too personal, in fact, it's likely, but I believe that dividing the project into at least 3 or 4 apps is wise and advisable. The difficult part will be conceptualizing how to logically divide the code, but once done, maintenance will be much easier for everyone!

[wkyoshida]

Thank you for everyone's inputs so far! Definitely awesome to now have multiple people pitching in on this.

I'll add some additional thoughts as well that I had: Tbf, I'm not entirely against the idea of an event-driven architecture with smaller services. What I did want to keep in mind though are considerations on infrastructure and maintainability.

• As this is an open-source project without the financial resources of a for-profit company, just to make sure that infra costs are considered. Haven't done a dive into this in detail (and it could actually be completely fine), but just something to keep in mind.
• A monolith Django made sense to me in regards to allowing new contributors to hop in - as the backend would be contained. Being an open-source project, not having contributors to take on the task of implementing/maintaining an event-driven arch was something I considered (this might not be an issue now though with the growth of the dev community here :smile:). However, I wasn't entirely sure yet that the size and scale of the activist project would actually enjoy the benefits of an event-driven microservice arch fully - perhaps yes, perhaps not.

P.S.

• If we're talking microservices, I would also agree with @5ud03r5 that the discussion on language/framework changes a bit, no?
• One of the points as well is that the individual services would be decoupled and hence free to be implemented separately and in different languages (whatever fits best for its use-case).

[kurtisolo]

I believe that (in this case) splitting the code into 3 or 4 different apps should not be considered a microservices or event-driven architecture, as the project remains monolithic in terms of deployment and execution. IMO, modularization shouldn't overly complicate the code, especially considering the open-source context. On the contrary: with proper documentation (which I would be happy to take care of!) that explains how to approach a slightly more elaborate structure, the project will be easier to maintain in the long run when it inevitably grows in complexity.

I had to arm myself with patience to decipher the logical structure of the models (which I still don't fully understand, tbh: a few comments along the code would be appreciated), when it would be much more intuitive and clear for future collaborators to face some structure combined with good documentation.

Just to give an example:

• Users & Authentication
• Content & Resources
• Events & Groups
• Organizations

Such a division does not change the monolithic configuration of the project but simply makes the management and understanding of the code more intuitive and manageable. In summary: I completely agree that Django is not a framework suited for an event-based structure: but in my view, this is not the case.

[andrewtavis]

Thanks for the further points, @kurtisolo! Only comment on my end is that we should do “Organization & Groups” rather than putting groups with events as groups are sub-organizations :)

[kurtisolo]

So, I've further studied and pondered on the project's key points, and I'm even more convinced that if the backend isn't divided into at least 3 or 4 main sections, it will soon become increasingly difficult to work on.

Note: this doesn't alter the purpose for which Django was designed. On the contrary, I believe this is a standard practice that allows for a smoother utilization of Django's potential.

If we were to follow the path I'm suggesting, a division idea might be:

1. Authentication (Support, User)
2. Contents (Resource, Task, Topic)
3. Groups&Orgs (Organization, Group, Movement)
4. Events (Format, Role, ActEvent, LearnEvent)

Further observations:

• "Movements" is an additional concept I'm suggesting. I'm not yet certain how it could be integrated, but it's distinct from the pre-existing concepts, and it might be worth considering its introduction.
• I think we should consider splitting the "Event" model into "ActEvent" and "LearnEvent", as shown in the example.
• Some models seem to represent association tables from what I understand: in many cases, a ManyToManyField relationship could simplify the code, letting Django automatically create these tables.
• In other situations, the structure can be further simplified by using a model like:

class ModelExample(models.Model)
    CHOICES = [
        ('choice1', 'Choice 1'),
        ('choice2', 'Choice 2'),
        ('choice3', 'Choice 3'),
    field_with_limited_choices = models.CharField(max_length=20, choices=CHOICES, default='choice1')

[wkyoshida]

I believe that (in this case) splitting the code into 3 or 4 different apps should not be considered a microservices or event-driven architecture

Ah - @kurtisolo, ok I gotchu :thinking: I believe there might have been just a misunderstanding then. As you had jumped in as discussions on the event-driven architecture were starting - I believe it might have just appeared to others (myself included) that the suggestions to split the Django apps was in regards to how to implement an event-driven architecture. To be clear though - I am onboard actually with your suggestion. It does makes sense to me as well for us to modularize by domain logic (for many of the reasons provided already).

Again - thanks to everyone chiming in! I think it's great that we have more and more people contributing here. Is it alright with everyone though if we circle back to discussing the event-driven arch, as initiated by @andrewtavis here? I have a feeling that discussion might actually influence how further planning for the backend later works out. For instance:

• @momanyisamuel are you able to fill us in with more details on how the idea to split into separate services came about? I think that might be helpful for us all to evaluate if an event-driven arch is something we should actually be considering at this stage.
• Also, if yes to microservices though, as @5ud03r5 has pointed out, do we need to reconsider the language/framework?

[andrewtavis]

Thanks all for the thoughts here! There are multiple considerations here as far as ease of adoption and ease of maintenance as well as scalability - to name a few. For now a monolith is inherently what we need and would allow us to get up and running sooner rather than later. We need to keep this in mind as we need to start bringing users into the process and checking assumptions about what we’re building.

With that being said, maintenance and scalability might be served by splitting the code base into “services”, where services is in quotes at this point as it’s all still in this repo, but we structure things in a way such that when and if we do need to break a service out, that at that point we have all of the code for it mostly localized in one area of the code base. We can use Python modules for this to structure it in a way that people can jump in and focus on one part.

I’d say that generally the split into four we’ve been discussing makes sense. We can refine it a bit as we go 😊

As always open for thoughts, but let’s also start discussing documenting the decisions that have been made here. This will help others jump in and also help us get going :) How would folks want to structure this? A wiki on the repo? A markdown file?

CC @to-sta (so you’re aware 🙃).

[kurtisolo]

I agree on starting the documentation right away. I'd be happy to take care of it (you've probably noticed I like to overexplain, perfect task for me lol). As for which tool to use, I'll defer to your expertise, but I must say, a wiki would be cool :)

Another thing, I'm still not clear on one point: should the code then be divided using Django's app system, or not? Because you mentioned using 'Python modules', and I wouldn't want any further confusion to arise!

[andrewtavis]

Django's app system would be fine, @kurtisolo 😊

I'm also always a fan of a wiki, and this is also what @momanyisamuel and I had discussed :) Are you able to create pages on the wiki? Let's see how the editing experience goes on GitHub and then if it's working out we can point people to it in the readme and other docs.

[andrewtavis]

Adding a few more thoughts here:

• We seem to be talking semi-monolithic/modular-monolithic for the start, which does fit the goal of getting it out but allowing for eventual scaling through services that are siloed and then abstracted if needed
• Re: conversations of languages and frameworks
  • Let's agree at the very least that we're sticking with Python for now (I blame myself for the Rust comment 😅)
  • I personally have no issues with FastAPI being used for a service down the line
• I think that the most recent suggested split of @kurtisolo here matches the database schemas fairly well.

Repeating it:

1. Authentication (Support, User)
2. Contents (Resource, Task, Topic)
3. Groups&Orgs (Organization, Group, Movement)
4. Events (Format, Role, ActEvent, LearnEvent)

"Movements" is an additional concept I'm suggesting. I'm not yet certain how it could be integrated, but it's distinct from the pre-existing concepts, and it might be worth considering its introduction.

Could you explain a little bit more what you mean here? "Movements" was the old name for "Topics", so just want to clarify your thinking.

I think we should consider splitting the "Event" model into "ActEvent" and "LearnEvent", as shown in the example.

Would also be good to get some further explanation on this :)

[kurtisolo]

Could you explain a little bit more what you mean here? "Movements" was the old name for "Topics", so just want to clarify your thinking.

I've been thinking more about the concept of 'movement', as certain entities might not fit into the concepts of 'Organization' or 'Topic'. To provide a couple of totally random examples (which might not necessarily be pertinent, but just to express the concept better): 'Anonymous' or 'Black Lives Matter'. They can't strictly be considered 'topics', in my opinion, and neither are they 'organizations' due to their decentralized nature. As I've mentioned, I'm not sure how this concept could be integrated, but I thought it was worth considering.

I think we should consider splitting the "Event" model into "ActEvent" and "LearnEvent", as shown in the example.

Regarding this, while thinking about how to implement the 'Act' and 'Learn' event types, even though we could simply insert a Choice-Field in the Event model, it might be more advantageous to have two separate models, and hence more flexible, assuming they might have different characteristics. An alternative could be a single Event model and dividing Format into ActFormat and LearnFormat. In summary, it depends on how many and what kind of fields and characteristics the models will have: dividing them in the suggested manner is just a possibility to keep in mind as it might simplify the structure of the relationships between models.

Are you able to create pages on the wiki?

Regarding that, I think so, if you mean the integrated wiki in GitHub. I'm not an expert, but for instance, I use it in my private repositories, so I think I can manage. Worst comes to worst, I'll learn :)"

[andrewtavis]

I've been thinking more about the concept of 'movement', as certain entities might not fit into the concepts of 'Organization' or 'Topic'.

I like the ideation here, @kurtisolo! I don't think this is included in the MVP, but it's something to think of and I've added a note in the designs for myself. As of now support would be the main way in which relations of organizations would be shown, with mutual support making allies. BLM chapters could for instance be allies and thus people could more easily find others. What you're talking about though would be more pages that could present combined organizations that have chosen to work together towards specific goals as well as events, resources and the like? Glad we switched over to "Topics" 😅 Stream of concious:

• Top right media component could be a map that has the participating organizations (maybe even one for the events too?)
• Maybe the page layout for these would need to be totally different as we'd have multiple maps and maybe even videos/image components?
• Potentially give allies the option to enter into a movement with one another
  • If there are two allies in a movement and they stop being allies, then it dissolves
  • If there are more than two and two of them stop being allies, then what? The org that ends the alliance drops from all shared movements? They'd need to convince other orgs in their movements that the other org should be kicked out before they end the alliance?

...it might be more advantageous to have two separate models, and hence more flexible, assuming they might have different characteristics.

What are your thoughts on different characteristics? As they're outlined now I think that the distinction is there mainly to provide a baseline filter for people so they don't need to sift through the learning ones if they want to act. The pages till now are planned to basically be the same, but maybe you have thoughts on this 😊

...if you mean the integrated wiki in GitHub.

Yes, exactly :)

[momanyisamuel]

@momanyisamuel are you able to fill us in with more details on how the idea to split into separate services came about? I think that might be helpful for us all to evaluate if an event-driven arch is something we should actually be considering at this stage.

The discussion about microservices and going the event driven approach is mostly because there is already a separation in terms of functionality

As @kurtisolo has noted the division of the backend into the various services is the right approach in my opinion as well.

• Authentication (Support, User) - this is currently already separate and has third party integration [matrix] as illustrated by the information process @andrewtavis discussed in last biweekly meeting. leaving the three suggested services/apps
• Contents (Resource, Task, Topic)
• Groups&Orgs (Organization, Group, Movement)
• Events (Format, Role, ActEvent, LearnEvent)

This really already introduces the microservice approach in my opinion. While splitting the API into multiple apps using Django would be a good approach, the various apps being created would make this such a huge monolith and in my opinion it would make sense to split this so as to avoid:

• Performance issues - the various services are huge and can equally be improved on better as standalone services for example as you can note @kurtisolo has already suggested the concept of 'movement', a microservice approach would allow for the various services to be able to expand without affecting each others performance.
• Security issues - especially considered as the nature of activist requires a lot of security consideration. Separate services can help deal with Denial of service attacks for example avoiding the case of one monolith having all apps/services down. Third party integrations can also cause security issues and i believe this architecture would allow only the integrated services to be directly affected and thus allow for quick shutdown and recovery in such scenarios.

As @wkyoshida and @5ud03r5 suggested I also think picking appropriate technologies for the various services should be considered especially using python solutions such as FastAPI and Django

[andrewtavis]

@momanyisamuel and I are doing a call right now to discuss the backend ☎️😊

Generally we're thinking right now that with time considerations and trying to get something into users' hands as quickly as possible that it would be good to adopt what @kurtisolo suggested :) What this means is that we're going to at first be working on a monolith that's in Django with the separation of the four apps as detailed above. We as a team need to be keeping eventual micro services in mind as we build the initial backend such that we keep things as independent as possible. From there we can abstract services as needed, with our general thought process being that authentication would be the first to get its own service. Getting activist into production so we can start communicating with people and iterating it should be the priority. We'll doubtless need to refactor along the way, but let's refactor something based on what we're seeing in production.

Re: the above app separation, for now let's keep events as one model, but @kurtisolo please let us know what you think the benefits are of splitting it! :) We also have you in mind to work on #322, but let us know if you'd like us to pick it up 🙃

Thanks all for the discussion! From the call, we're really excited to get going 😊🚀

[andrewtavis]

Let's use this issue now for discussing how we want to document the API :) Sounds like all are on board for using the wiki. I'll do some minor setups for that now and i changed the settings on the wiki so that everyone can edit it for now 😊

[andrewtavis]

I just went through and ordered the models based on the four way app split in 7e71c25 (+ some other fixes). I also went through the schemas at the same time such that we have the same ordering in each :)

[kurtisolo]

Sorry for the absence, I've spent the last 2 days juggling bug fixes on another project. I'm thrilled that things are going well here!

So, about the division of the Event model: it was just a 'preemptive consideration,' in the sense that more distinct differences might have emerged in the future, which would have justified a separation like the one I suggested.

As they're outlined now I think that the distinction is there mainly to provide a baseline filter for people so they don't need to sift through the learning ones if they want to act. The pages till now are planned to basically be the same

However, if it's the way it is, then we can disregard the matter and simply stick with a single model :)

Regarding issue #322, I'm more than happy to contribute, see you there

[andrewtavis]

Decision was made in the dev sync yesterday that we can close this issue and that further issues can be opened later for specific points. Thanks all so much for this issue! Really appreciate the constructive communication and all the great points brought to the table 😊