Groundwork Technology Choices

Introduction

Turn explanation into a process recipe.

Detailed information about Using Technology Radars can be found in our process recipe.

This page keeps track of major decisions that relate to Groundwork technology stack. Here we explore libraries and frameworks that are candidates to adopt in support of various architecture concepts and requirements. Decisions are ordered in reverse chronological order (Newest-first) and have states. They represent a Technology Radar. It has one additional ‘Open’ state, meaning that an investigation, called a Spike, is planned.:

Decision Log

Adopt Elixir PETAL technology stack

Adopt

The PETAL stack is a popular combination of frameworks and libraries that have proven to be very powerful and flexible. It consists of:

• Phoenix: Leading web framework for Elixir.
• Elixir: Elixir server-side rendering code.
• Tailwind: CSS framework to mark up HTML with semantic classes.
• Alpine: Minimal framework for composing JS behaviours in markup.
• Liveview: Real-time UX with server-rendered HTML.

Elixir and Phoenix Liveview were already part of the stack. Tailwind was a great experience in migration from Bootstrap for fedi.foundation and is intuitive to use for non-CSS experts.

Use Elixir for Floorplanner and Groundwork Platform

Adopt

List more arguments that led to the decision to adopt.

Initially Golang was considered, based on pre-selection of Go-Fed ActivityPub library. But with both Bonfire and CPub and language characteristics in mind, Elixir became the preferred language environment. Listing investigation results of both environments.

Use Golang for Floorplanner and Groundwork Platform

Hold

ActivityPub support libraries

Starting point has been to build off existing ActivityPub implementations, where we found:

Technology stacks based on Golang and Elixir have been explored in more detail in paragraphs below. The following sub-sections summarize considerations for each candidate.

Candidate: Go-Fed

Not selected

Set of ActivityPub libraries implemented in Golang that focus on shielding the developer from complexity and focus on building ActivityPub vocabulary extensions.

Key features:

• Generate Golang code from OWL vocabulary definitions.
• Fills in the blanks for ActivityPub support, offering Webfinger, NodeInfo, HTTP signatures.

Cons:

• Libraries no longer actively maintained. Implementers create forks to extend.
• Extensibility mechanism still largely untested, not mature. Lack of documentation.
• Huge amount of code generated. Cannot be easily shared between service modules.

Advice: Collaborate with implementers on AP extensibility mechanisms, most notably with forg.es community.

Candidate: Bonfire

Considering

Very interesting extensible framework with intent to facilitate an open ecosystem of plugin extensions for the creation of social applications that have federation support.

Key features:

• Built as a Fediverse platform with out-of-the-box common social features (Microblogging).
• Well productized, vision of becoming an open collaboration platform.
• Extensibile plugin architecture and plans faciliate a plugin ecosystem.

Cons:

• Early stage of development, unclear short-term direction (microblogging-first approach?).
• Architectural complexity, opinionated approach, unclear positioning for plugin builders.

Advice: Strive for close collaboration, invited to join Social Coding co-shared community.

Candidate: API Platform

Not selected

Very active project, offering a complete platform for productive development of front-end applications based on linked data and semantice web technologies.

Key features:

• Generate a PHP data model from the RDF vocabularies and ontologies.
• Production-ready application framework with existing ecosystem.

Cons:

• PHP language, opinionated Jamstack less suited for server foundation and polyglot usage.
• Full reliance on framework direction. ActivityPub is just one ecosystem component.

Advice: Interesting to learn semantic web best-practices. Possible partner for future collaboration.

Candidate: SemApps, ActivityPods

Not selected

SemApps, a microservice platform based on Moleculer that adds extensive linked data and native ActivityPub support. ActivityPods is a SemApps application that combines ActivityPub and Solid.

Key features:

• Ease of use of Linked Data Platform to create, store and retrieve custom entities.
• Extensibility, modular architecture. Huge developer base on the NodeJS techstack.

Cons:

• More focused on Semantic Web, knowledge graphs, using experimental, complex standards.
• Strongly tied to underlying frameworks and NodeJS + Javascript technology ecosystem.

Advice: Interesting to learn semantic web best-practices. Possible partner for future collaboration.

Candidate: openEngiadina CPub

Preferred

Generic ActivityPub server with experimental features based on research into peer-to-peer use. Provides support for Client-2-Server ActivityPub and content-based addressing.

Key features:

• Federation based on linked data (RDF) extensibility and a C2S generic server.

Cons:

• Experimental features that will not be ready for production on the short term.
• Project is discontinued due to AS/AP + C2S complexity. Continues based on XMPP.

Candidate: rdf-pub

Not selected

ActivityPub server that supports Client-2-Server features and RDF based vocabularies. Part of Linked Open Actors project.

Key features:

• Linked data (RDF) and basic C2S support.

Cons:

• Very early development, small team, and serves a larger project with different use cases.

↑ →