Introduction
Since the advent of our goal to simplify Resonate’s tech stack and creating a functional development environment that’s easy for newcomers to get up and running (so they can contribute!), and in line with Product Development Update: October 2022, we’ve been hard at work on the consolidated API. (I realized that we have specific forum threads for front-end clients such as Beam: A Native App For Linux, macOS, and Windows (testing please!) and Minimal mobile apps for Android and iOS to track progress and report back to the community how things are going, we didn’t yet have a thread going for the the back-end API, so the aim of this thread is to fulfill that role.)
What is an API?
What is a API or a back-end in non-tech-speak terminology? Think of it kind of like how a public library works perhaps: if you go to the library looking for a particular book, you can ask a librarian to help you find, and check out something that you’re looking for. They swipe your library card (authentication / logging in), and you can take the book with you, or make copies of pages of a book to keep. Think of the API as the librarian, serving requests for specific pieces of data (music to stream, album art to look at, music metadata, etc.).
Consolidation
So instead of splitting up these services across many different and separate folders with code you have to download separately and set up separately to get running as a developer, the goal here is for one download and everything gets up and running with a simple command - we want developers to be able to focus on contributions and improving our codebase, rather than worrying about how to get everything working.
Progress as of Mid-October
Work has been moving quickly on the API (tracked in our Product Backlog), and in recent weeks we’ve introduced extensive testing, which lets developers know immediately if the changes they’re attemping to make will break things (essential for newcoming devs looking to contribute but don’t yet understand the codebase in full).
I want to give a massive shout out to @psi for putting forth an immense amount of dev-ops work and elbow-grease into this, as well as @matt_burnett for putting in a lot of incredible work with the testing: which with the above additions means that we should now have tests running every time someone puts in a change request to our code. It’s not a full test suite yet, but this will give us a lot of insight into how and when we change things, and how they affect the overall API. They’ll catch unexpected side-effects across the app, and means you don’t need to have one person holding the knowledge of the entire app to prevent side-effect you didn’t expect.
The tests will also make it much easier for us to know what output we’re expecting from endpoints, and to write endpoints so that they conform to that output. Whenever we make changes to the API, or fixing bugs, we should be writing tests for those changes. (should is an ideal world, realize we are a volunteer project).
This may be a bit wobbly, as @psi has noticed that sometimes the GitHub Action doesn’t load in the expected test libraries, for example, so we’ll have to iron that out, but it’s a huge step forward for confidence in that our code is doing what we think it should do (or aspire it to do).
We’ll be sure to continue to post further updates below this initial post, so we can continue to make this work visible/transparent, and receive feedback from the community.
Get the production environment running on the same server as where all of our data is stored.