Introduction
First, some unfortunate news. At the end of August, 2022, @auggod, Resonate’s only paid dev, decided to step back. He volunteered to stay around to ensure a smooth transition and assist with the handover to the rest of the volunteer @maintainers. We’d like to extend our deep gratitude and thanks to him for all of his hard work and dedication to Resonate over the past years.
With @auggod’s departure, this leaves the remaining volunteer @maintainers with a dev stack they cannot successfully and completely build locally (making it nearly impossible to fix things when they break, or to implement new features), in particular the ID server written in Golang. A number of the current live assets exhibit technical debt, meaning they use libraries and packages that are no longer well-supported, making it an uphill battle to maintain and build upon. Also, the transition off of WordPress is not quite complete.
Additionally, the co-op is currently low on funds and can’t afford to hire a developer to contribute full time.
As a result, the current tech stack and setup should be seen as a success as an initial prototype, a proof of concept, which will tide us over until we can eventually create a Minimum Viable Product for Resonate. Expect our current infrastructure to be in flux for the time being while we build out new solutions that are easier to get running and contribute to as volunteer developers, and lack the technical debt that our current prototype exhibits.
Features we know don’t work
- The ability for artists who newly joined to upload new music. If you were around before the transition you will able to continue uploading music.
- Some (but not all) users are experiencing bugs with logging in.
Justifay
We are currently exploring collaboration with Justifay, a fellow music cooperative, based out of Barcelona, Spain. In the spring we collaborated on an initial phase of work, and they are interested in continuing to build with us towards the common goal of creating an open-source Digital Streaming Provider. These conversations are helping shape our immediate and long term goals.
The following is a synopsis of our current development strategy and way forward:
Overview
This section on down is adapted from the new overview section of the docs, which will be kept as up to date as possible with a high level, bird’s eye view of our tech stack and current development processes.
What does a professional DSP look like provides a tentative roadmap of our long-term goals. To gain a better understanding of our immediate goals and tasks, check out our Public Product Backlog.
In September of 2022, Resonate set a goal: to create a functional development environment and to simplify the entire tech stack. This is to prepare Resonate to meet the needs of the DSP Product Development Plan.
As a result, the assets that are currently on our live servers should be considered a prototype. These legacy assets are more or less considered to be in Maintenance Mode as we consolidate the server API into one repository: api. Initially, we’ll move all legacy JavaScript microservices into this consolidated repository, following that, the server assets written in Go (namely id and user-api) will be incorporated/adopted as well.
We want to provide a consolidated back-end API one Docker command to spin up the whole back-end, in a shippable package, one container that is easy to install, plug, and play. This will in tandem help us further grow our open source ecosystem, speed up development for the long-term, and facilitate onboarding new dev contributors.
Active Development
Resonate’s API is undergoing a consolidation phase, pulling in functionality from multiple legacy repositories into one, the api. The api repository is experimental, and under very active development - expect things to change rapidly. The beam app (an Electron app written in TypeScript/React) can be run in the web browser, and will eventually replace the live web player. As we develop and build out api, beam will be the go-to front-end client for testing. Because we aim to build an open-source Accounting Engine with automatic reporting with digestion of DDEX Electronic Release Notification Message Suite Standard (ERN) data, the current focus is primarily on the back-end.
That being said, some of this work can occur in parallel. For volunteers looking to get their toes wet or to tackle a quick issue, contributing to our actively maintained front-end clients (beam and mobile) would be massively helpful. Check out the Beam Issues List or the Mobile Project Board to get a better idea of prioritization. If you’re a volunteer feeling rather ambitious, check out the Product Backlog for an idea of more overarching issue/task prioritization, and issues/tasks for the back-end.
Legacy Assets on Live Servers
The following assets will live on on our servers while work is conducted to build out a Minimum Viable Product. This means that users should not expect as much support for problems encountered with our current infrastructure, which should be considered more or less legacy and in maintenance mode.
Resonate ID Server - a Golang server that acts as our “authentication” portal. It’s primarily used to provide login and authentication for client apps, which includes the stream app, the dashboard, and, for example beam.
Resonate User API - this is primarily a database that stores all the user information and has some user management methods and functionality associated with it. It also is a golang server.
Tracks API - a thin nodejs sequelize API that provides access to the tracks database, serving streaming information, etc.
Stream & Dashboard - These are two different webapps. The stream app is a choo based javascript app that allows streaming, while the dashboard app allows track management and upload. The dashboard API also contains some code that is partially duplicated with tracks-api mentioned above, so there are plans to merge those.
Signed,
@executive, @maintainers
