Summarizing development stack and apis

A while back, 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.


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:


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.


@jeremy @piper @brndnkng @replygirl

I believe this is the best cluster of documentation for the current USER API , Of course @auggod would know best, as well as how may connect to STRIPE, the TRACKS API, PAYMENT API and accounting processes for rights holders / custodians.


Other good info is under the #orientation tag. Folks, feel free to tag other good dev orientation topics with #orientation.

1 Like

@jeremy and I were discussing this this week - I found this document in an issue in an older repository on GitHub, and I added it to the Resonate Docs website at the bottom. This certainly needs to be updated, since it’s from circa 2020, but the scope and depth of what this document aims to achieve is commendable:

Resonate.Tech.-.Why.What.How.and.Where.v1.pdf (1.4 MB)


Hi @piper here is the source deck… please feel free to update it!

For the next levels of detail I started on a series of design docs for each main ‘domain’ for the APIs.

Example here

A lot of this now overlaps with stuff in the Platform category, but I thought it would be good to have a more complete doc for each ‘domain’ with some version control and collaboration around it while drafting and discussing. Best not to use google stuff of course from here on!

There are long discussion threads around this, talking about options and choices… Robert M, Angus and I held those in the Pavilion dev forum. Let me or @angus know if you need access.


Could you elaborate a bit more by what you mean by “domain”? Sorry for the noob question!

Oh sorry… I really just meant an area of the puzzle… usually a cluster of services that hang together in some way because they are related… for example:

  • Listening services
  • Uploading and artist self-service
  • Catalogue management and rights management and reporting
  • Users and memberships
  • Accounting and Payments
    …and so on

Often it’s helpful to think about ‘object/data subject areas’ in dividing up the big picture, but remember its the user ‘epics’ and stories make it come alive and make sense for the user (consumer) of the api.

(I suppose strictly I should have said ‘bounded context’ in case anyone is fussy about this…)


Do you mind giving me access to all this? I’m trying to pull together all the docs that might be helpful to inform the next phase as we try to get to a DSP


Sorry Jeremy - I assumed you had been given all this already! I’m not sure if I still have rights to grant, but @Hakanto and @auggod should be able to help too. Ping me your preferred email address on Telegram or a DM