search

EmissarySocial / emissary

The Social Web Toolkit
https://emissary.dev
GNU Affero General Public License v3.0
133 stars 14 forks source link

What are the reasons for MongoDB? #84

Closed sbutler-gh closed 1 year ago

sbutler-gh commented 1 year ago

I'm curious about the use of MongoDB in this project. I'd like to better understand the reason it was chosen, and alternatives considered.

benpate commented 1 year ago

Great question :) As Emissary it still very new, please excuse the lack of documentation and architectural diagrams right now.

Technical Reasons to Use MongoDB

  1. I expect Emissary to need the features where Mongo excels: fast, concurrent read access, and eventual consistency of writes.

  2. In addition, Emissary is intended to be easy for large service providers to run at scale, while still preserving the independence of each individual node. So, it was important to use something that clusters well, and fits nicely into an existing DevOps infrastructure.

  3. Also, MongoDB documents fit nicely into Go structs without any additional ORM mapping. It has made initial development very fast, which helps get the app off the ground.

  4. Mongo has some great realtime features that make SSE push notifications a breeze.

  5. On a personal note, I have already built a large app using Go/Mongo and the server stack was fantastic. So it made sense to start with what I knew.

But We Don't HAVE to Use MongoDB

More importantly, Emissary is built to migrate to other database architectures when necessary. 95% of database access goes through a common db interface so that mongo can be swapped out for a better alternative if necessary. The remaining mongo-specific queries are isolated in the queries folder so they can be rewritten on another architecture.

The only real hurdle I've left unsolved is the mongodb ObjectIDs that are used as primary keys for all of the model objects. I left this problem as technical debt to figure out later because getting a working platform (on any db) seemed like the more important issue to solve first.

I'll Welcome All Contributions

I think there's a lot of potential in this idea and this codebase, and I don't need to be dogmatic about the tools we use. If you're interested in making adapters for another database, I'm happy to show you where all the code is, and to all pull requests that don't fundamentally break the app.

aschrijver commented 1 year ago

This just came up in Forge federation chatroom related to the project licensing (SSPL). FerretDB was mentioned, which is Apache 2.0. Note that the website still mentions Apache as well, which does not correspond to LICENSE.

(The licensing of SSPL meant I couldn't include on Delightful Club fediverse apps this morning, as the delightful projects only allows FSF or OSI approved licenses for listed resources)

benpate commented 1 year ago

Hi @aschrijver - Lots of great info here, and thanks for jumping in. Is there a link to the Forge Federation chatroom? I'd love to pop in to learn and participate.

I'd love to get Emissary listed on the Delightful Club list (and others) when it's ready. I've just entered the "start telling other devs to take a look" stage, and will be ramping up more as the software stabilizes. Are there other places you'd recommend

It looks like FerretDB is protocol-compatible with Mongo. It should be a drop-in replacement. Our DB requirements are pretty light -- simple object storage, indexed queries, and one "nice-to-have" of realtime updates via change streams. If we can get that out of Ferret DB, then I could do some testing and add that to the setup guide. Would that help get us listed on more OSS directories?

Building in open source is important to me, but I have to admit, I'm not an expert with all of the different licenses. I chose Apache because it is straightforward and doesn't include the LGPL "poison pill" that has dogged many companies. At the same time (and at first glance) Mongo's Server Side License seemed like a good balance between allowing people to use their software for free, but preventing companies (like Amazon EC2 and others) from simply reselling other people's work without any compensation. I've considered dual-licensing Emissary under similar terms. What would you recommend?

aschrijver commented 1 year ago

Is there a link to the Forge Federation chatroom?

https://matrix.to/#/#general-forgefed:matrix.batsense.net

Would that help get us listed on more OSS directories?

Yes, you could have Apache 2.0 license in the repository. When I found FerretDB I already hoped it was appropriate for this project, as main differences are in advanced things where MongoDB is targeting high scalability, big tech stuff.

What would you recommend?

Licensing is always an intricate topic. I am FOSS-minded myself (copyleft), rather than OSS (permissive). There is a lot of FUD against copyleft out there, created often by Big Tech. There is nothing withholding a copyleft project maintainer of monetizing their code. Examples are plausible.io and keila.io who are both AGPL-licensed and run a good business. Dual licensing is also an option, for instance copyleft + proprietary version for enterprise customers, but it isn't popular in the FOSS community.

Note that with permissive license you run a risk. The risk that you created something and - with popularity coming - proved to be valuable, after which some other company grabs your code and builds a proprietary competing product (e.g. a SaaS platform) from it. This is somewhere, where AGPL protects you. AFAIK if customers install the packaged release they have no (for them) 'negative' consequence from it of having to publicly share code extensions.

benpate commented 1 year ago

Hey all. Ima close this issue. But it's worth noting I've switched the license from the Mongo "Server Side License" to the AGPL 3.0. Cheers!