Add DPG: AletheiaFact.org (10585)

[dpgabot]

Public Link : https://app.digitalpublicgoods.net/a/10585

[ricardomiron]

The project has a direct dependency on MongoDB. Product owners are considering implementing an abstraction layer:

We have considered in the past providing Database Adapters on top of TypeORM [1] to make the developer experience seemingly across different infrastructures, that can support a range of OSI-compliant DB and MongoDB, which would be our main choice. After some investigation, in the current state what prevents FerretDB from being a drop-in replacement is the lack of support for the $lookup aggregation pipeline [2] and our choice to use virtual populates. With TypeORM support this would need to change anyway and these are architectural decisions to save disk space due to our constrained resources but flexible and easy to replace with a foreign key strategy. Also, NestJS modularity [3] and domain-driven design combined with its extensibility make it possible for the community to create their own interfaces with the platform resources, much like MediaWiki allow with its extension system. In that way it's technically possible to support any kind of DB as long as the resource interfaces are respected. [1] https://github.com/typeorm/typeorm [2] FerretDB/FerretDB#1427 [3] https://docs.nestjs.com/modules#feature-modules

Further technical proof of implementation of TypeORM would be needed beyond the theoretical possibility. To be followed up via support email by @kagaba

[ricardomiron]

Response from the product owner:

I created this repository with a POC on how NestJS can be used to create abstractions to have different code flows based on the desired DB but keeping the interfaces cohesive and functioning in the architectural design. In this POC I demonstrated a functioning CRUD interface for a resource going through the same API but storing on different databases (MongoDB and PostgreSQL) depending on an environment configuration.

I decided to just showcase plain NestJS and Typescript interfaces because this approach allows a much broader set of alternatives. Also, I did my best to keep it simple and complete the POC as soon as possible due to time constraints.

I'm not betting that TypeORM can be a silver bullet, especially if you want to support FerretDB (which I'm not familiar with btw). But as I mentioned before, even if you can do that easily, our code contains aggregations pipelines not supported by FerretDB yet. The DB abstractions strategy should work but interfaces should be implemented for the target databases.

@iperdomo

[ricardomiron]

• Bound to Ory hosted version, ask if any feature is not present on the open source version.
• Technical proof of replacing Mongo, beyond general NextJS framework capabilities.