A while back, @zetto.plus wrote this Topic highlighting Resonate’s tech infrastructure and needs. Our new Needs category and help wanted tags on Github allow us to easily highlight tasks developers could take on.
I’ve set this Topic as a “wiki” which means you can edit it directly. If you are a developer who has experience with where Resonate is right now, feel free to edit this doc to update information and delete outdated information.
@jackhajb @auggod @boopboop @piper @fgblomqvist
I’m tidying up the forum and this seemed worth revising rather than deleting. If you feel there is a better way to summarize this information (or if you know of a more current summary elsewhere), please share your thoughts. I’m aiming to remove redundant and out-of-date materials, so if we decide not to update this, I feel it best to delete it.
Intro
In working our way toward producing a mobile and desktop Resonate app, we could use more help on the development side of things, but here’s the thing:
As a co-op, we are trying to think outside of the box when it comes to technology and more.
Going against the grain means having to account for a few extra things in the development process, so here’s a light overview of where we’re at and where we need help.
Focus areas
- The Player
- The Main Website
- ID and Access Management
- The Community Forum
- Accounting (Back Office)
- Catalogue Management
In each of these areas, we have different needs.
For the Player, we’re releasing a new version (try it out!), with better playlists, and there are more social features we’d like to add.
For our Main Website, we are still in the process of transitioning from WordPress to Hugo. We need a wiki page too!
For ID and Access Management, we are focused on work around the ID server, our user and member API, and a Community Credentials feature.
For the Community Forum, built on Discourse, we’re working on improving the design and our community processes.
In Accounting and Payments, we need a new payments API, better statistics, and financial reporting.
And for Catalogue Management, we’re working on uploading and catalogue “ingestion” tooling.
Front-end stack
- Choo (we rely on Choo modules)
- Hugo (for the new main site)
- Tooling (Figma for UX designs; for JS packages, Lerna, Gulp, PostCSS, and so on)
Back-end stack
- Node.js (for the Resonate upload tool)
- Golang (for our core APIs and our OAuth 2.0 server)
- PHP (current API for handling tracks, plays, Stripe payments, and more; it is partially integrated with our WordPress system through users and metadata)
- WordPress (current dynamic site with Gravity Forms and other plugins)
- Hugo (our new, static website framework)
- Discourse (our community service)
- We use Docker containers with Ansible for automating our CI/CD pipeline. We also have an NGINX web server load-balancing tier. Our infrastructure platform is - - Hetzner Cloud (H-Cloud CLI tool).
Core APIs
Our focus is secure, privacy-respecting user and member management. Our current legacy back end mostly uses WordPress and its ‘Gravity Forms’ and ‘Ultimate Member’ plugins, in addition to manual processes and spreadsheets (labour-intensive).
Our future will be built around secure APIs with our own core code, and no data replication between legacy and the player.
We are already moving to a microservices architecture with both RESTful Node.js APIs and RPC APIs written in Go, using protocol buffers (TWIRP/Grpc).
We will use OpenAPI standards and provide developer-friendly SDKs. We are considering the use of more sophisticated API gateway tools like Kong for the future.
APIs for tracks and player
The tracks API is moving to a new version and serves content to the player (a progressive web application written in Node.js). It provides audio and image files, and metadata such as artist, track, release, and playlist info.
In the future, our new user and membership API will provide more flexible and rich artist, label, and collaborator profile information to the player.
You can find more detail on the player here:
In both the current (beta) player and the new player, we use standard HTTP/2 from the Node.js server, and the Node.js client handles all buffering and content delivery pretty well – try it! No encoding / DRM. Standard (not HQ) streams. More on the new (v2) tracks API here:
https://github.com/resonatecoop/tracks-api
———
Managing user information
The current WordPress site is complex and unwieldy to use for profiles. The WordPress Ultimate Member, Stripe, and MailChimp plugins can be tricky to keep in line. There is also poor integration with our Discourse-based Resonate Community.
Our ID server today provides only partial authentication and no roles, resulting in multiple logins (to WordPress, Discourse, and the player). We have partial introduction of Postgres DB, which is our target relational database, but for now, we are on MySQL. We may also set up a statistical / reporting database later.
Moving to microservices
One of our current goals is to finish transitioning out of the WordPress service and into the static Hugo website, as well as a series of self-service apps (progressive web apps written in Node.js) for the player and for transactions to update profiles and manage our catalogue, all handled by the core services, a cluster of scalable Golang microservices and APIs:
- User and Membership API
- Tracks API
- Payments API
Our payments API needs to give us the flexibility for future alternative and cheaper methods of payment. We need better integration across our statistical and billing/payments information from our platform. That includes links with our accounting platform (Xero) and our use of social media channels for (privacy-respecting) contact management and CRM.
Identity management
Our Go OAuth 2.0 server will allow role-based interaction between services with minimum exposure of user information, geared up for future ‘ecosystem’ use of both Resonate identity and potential ID services.
We have an exciting EU-supported Next Generation Internet project called ‘Community Credentials’ that allows for privacy-respecting portability of important credentials/proofs between members and between communities. We use W3C verifiable credentials to do this.
A new foundation
The Resonate team has many more ideas and plans on the tech front, but until we are able to address some of these foundational and transitional concerns regarding tech and infrastructure (and obtain more resources), we will not be able to explore and build on them.
