Where did all the time go?

While there was a Q3, there really wasn’t much time to report on it between switching jobs and finishing college. That leaves Q4 left and there have been a lot of updates since the last update. To start there have been major additions to the UI and it brings in more functionality.

There are still some bugs that exist that are a doozy, most of the work of Q3 and Q4 have been revolving around rewriting a lot of the service calls to split them apart and use hooks to handle most of the extra features. As an example when you create a room a scene is created by default so you can immediately add resources and add them to the scene. That used to be a hard requirement inside of the room service but is now done after the room is created in a separate fashion.

Demo

So you have a visual accompaniment with this post here is the Synk Q4 demo.

What may not be immediately noticeable is a change in load times for certain elements, from Q2 just loading the room you had a second or two. That is now condensed down into milliseconds as we move towards using primarily sockets for communication.

The UI got a fresh coat of paint, scenes are a single row until expanded which show a list of all instances in that as well with their controls to the right of them. At the bottom of the scene panel is the option to add instances right to that scene. Plans to add instances from the resource page to specific scenes in planned but not implemented as of this time.

Another big feature that is helpful is the live preview which mutes the global scene for the DJ only and plays the preview of the track as to let the DJ know what that track is without having to leave or open it elsewhere. It also allows the DJ to understand what they’re about to add to a scene. Future plans to have this also on the scenes page as an option to preview with and without global audio to ensure what track you play is the one you want to play.

Another addition to the UI front is adding a volume slider and loop toggle. These features have been there from Q2 but now they’re available from the UI. UI tweaks will be a large portion of the work in 2018. A lot of experimentation will be happening as the backend API is stabilized. The UI as well as 2019. UX is very important in this stage and currently it does feel clunky to handle the most basic 2020. tasks, but most of that has to deal with how the frontend handles state, which is now fully using 2021. Redux inside of Angular.

Invisible Features

As I said earlier most of the features for Q3-4 have been backend changes to split apart responsibilities. With that change comes a change in how users are allowed to do certain actions. I’ve used permissioning systems in Laravel plenty of times but coming back to Javascript there doesn’t seem to be many that are in the forefront. From searching I came across CASL and it’s a very lightweight isomorphic permissioning system that allows me to describe permissions in a very easy legible way.

CASL isn’t that hugely used so it’s tough to place something into an ecosystem which doesn’t have huge amounts of community support. However with my experience the maintainer is quick to fix issues, of which I only found one so far since using it.

CASL also really eliminates a lot of complexity and due to it’s simple nature I can use it with REST and sockets and connect it to whatever backend (if required) I need.

Speaking of backends, there is now a combination of databases used in Synk now. Primary storage is in MongoDB against better judgement. In the future this will change but for the prototyping phase mongo has been very easy to handle. Perhaps I might go back to MySQL or Postgres, but that comes with it’s own issues. For the second database I’m using NeDB, while it is not hugely maintained I haven’t run into many issues and it’s hard to come by a nicely packed in memory DB.

The NeDB section of Synk has the responsibility of handling the socket connections and authentication. Primary authentication is still through Auth0 and Mongo but the JWT is understood by the NeDB layer. When a user loads the site and joins a room they are allowed to query for the room information but scene info and realtime updates are sometimes meant to be private. So this allows the server to decide whether or not a client will be able to receive the socket event. Allthewhile using the same CASL permissions the primary service side uses.

I’m happy with the way this combination gives flexibility and scalability, as most permissions are figured out when the client creates the initial connection with their JWT.

A few additional updates have happened to the time syncing code as there were edge cases in other browsers that caused a discrepancy of 2 minutes over the span of two or more weeks.

Future Plans

Planning for the future is sometimes difficult but I believe there is a path forward for Synk that will create a platform for success. To start there will be a limited edition of Synk available to the general public after a closed beta. This beta will be invite only and primarily used for UX testing. After the major issues with the UX have been solved, if there are many, there will be an opening to the public where users can sign up for a limited account.

These numbers aren’t final and they’re mostly guesses.

General Public:

• Room Count: 2
• Public only rooms
• Resource Count: 15
• Instance Count: 15
• Live Instance Count: 2-3
• Max patrons: 4
• Basic feature set enabled

I believe with that as a general guideline it creates enough freedom for a casual game but for those who want to have a catalog and be prepared and use the advanced features of Synk it would be a subscription. Now it wouldn’t be hugely expensive, probably around $2-5/mo depending on the tier. This is called the Subscriber tier.

This is all without actually hosting the content, that part is still on the client using Synk. The Producer tier might be something like $10/mo and it would be possible to allow users to upload the tracks to Synk directly and not have to worry about outside sources. Integration with other services will probably fall under the Subscriber and Producer tier and not in the public tier.

It also goes without saying with the upper tiers the numbers from the public tier are larger and for producers it’d be nearly unrestricted in use.