Universal UGC (User Generated Content) Contributions Management System

The uugc library is a Deno module designed to facilitate the management and validation of User Generated Content (UGC). With the power of Zod, it offers strong type validations for entities related to UGC. The module simplifies the process of storing contributions, making them hierarchical, and provides both in-memory and potentially other persistent solutions.

We call it Universal UGC (UUGC) because it can be used for a variety of use-cases such as commenting system (e.g. blog comments), forum messages, real-time chats, sync'ing with Discord, LinkedIn, Slack, Teams, etc. and integrating Hypothes.is and other annotation platforms.

Features

• Strongly typed entities using Zod.
• In-memory persistence strategy for quick prototyping.
• Extensible design to accommodate other storage solutions.
• Hierarchical representation of contributions.
• Asynchronous methods simulating real-world scenarios.
• Simple rendering logic for contributions.

Architecture

Concepts

• Persistence, User Interactions, and Presentation are separated
  • Persistence should mutate and persist entities in as small and granular "flat" way as possible (as opposed to "rich JSON" with hiearchical structures) so that contributions may be easily stored in memory, in Key/Value databases, in relational databases, or in document databases -- making the persistence truly independent. When retrieving data from the database, though, the in-memory structures should be "rich" and hierarchical.
  • User Interactions should be decoupled from Persistence so that whether we're using an HTTP service, GraphQL, web sockets, a wire protocol (like PostgreSQL), or any other service interface our persistence is not tied to UI/UX/service activities.
  • Presentation services should be decoupled from Persistence and User Interactions so that we can serve HTML, Mobile, and other user agents.
• Use Zod for defining and inferring types for entities like Parties, Contributions, and their relationships so that user-supplied content can be parsed and validated before persisting or interacting or presenting.
• Uses asynchronous methods whenever reasonable.

Entities

• Party: An entity which can be a Person or an Organization.
• Contribution: User-generated content with optional parent linking, making it hierarchical.
• Contribution Target: The target entity to which a contribution is related. This could be a URL for a content (e.g. a blog post comment), it could be another thread (in case one message is a reply to another like in Discord, etc.).
• Contribution Session: Represents user activity with authentication and user agent details.
• Contribution Reaction: a like or other reaction to a contribution.
• TODO: Multi-tenancy capabilties
• TODO: Contribution Folksonomy: tagging and other organizing capabilities.
• TODO: Annotation integration with Hypothes.is.
• TODO: Feature flags and configuration management

Persistence Strategies

• ContributionSessionPersistenceStrategy: Interface defining CRUD operations on authenticated sessions.
• ContributionPersistenceStrategy: Interface defining CRUD operations on contributions.
• ContributionTargetRelationshipPersistenceStrategy: Interface defining CRUD operations on the relationship between contributions and their targets.

Interaction and Presentation Strategies

• ContributionInteractionStrategy: Interface defining methods for posting and fetching contributions (this is the "business logic").
• ContributionPresentationStrategy: Interface for rendering contributions and threads (this is the "presentation logic").

In-memory Implementations (mainly for demonstrations and examples)

• ContributionMemoryPersistence: An in-memory data store and CRUD implementation for contributions.
• ContributionTargetRelationshipMemoryPersistence: An in-memory data store and CRUD implementation for contribution-target relationships.
• TypicalContributionInteraction: A class implementing both interaction and presentation strategies. It uses in-memory stores by default. Provides rendering logic to represent contributions in a simple string format (for debugging).

Init after clone

This repo uses git hooks for maintenance, after cloning the repo in your sandbox please do the following:

deno task init

Check for missing deps

deno task doctor

You should see something like this:

Git dependencies
  🆗 .githooks/pre-commit
  🆗 .githooks/pre-push
  🆗 .githooks/prepare-commit-msg
Runtime dependencies
  🆗 deno 1.34.0 (release, x86_64-unknown-linux-gnu)
Build dependencies
  🆗 dot - graphviz version 2.43.0 (0)
  🆗 java 17 2021-09-14 LTS
  🆗 PlantUML version 1.2022.6 (Tue Jun 21 13:34:49 EDT 2022)

Doctor task legend:

• 🚫 is used to indicate a warning or error and should be corrected
• 💡 is used to indicate an (optional) suggestion
• 🆗 is used to indicate success

If you get any error messages for dot, Java, or PlantUML then you will not get auto-generated entity relationship diagrams (ERDs).

Maintain Deno dependencies

You can check which deps need to be updated:

find . -name 'deps*.ts' -type f -not -path "./support/*" -exec udd --dry-run {} \;   # check first
find . -name 'deps*.ts' -type f -not -path "./support/*" -exec udd {} \;             # update deps