Models

The web backend component is built with Java Spring framework in MVC(Model-View-Controller) architecture.

User

Represents the user of the application. The record gets created when someone logs in the very first time in the application. The identifier is the one that the Spotify generates and it's a maximum of 25 characters long string. The other information that is stored about the user is the name that is given on Spotify. Since its max length is not documented it's stored in a 255 characters long string.

LEDConfig

Represents an effect created by a user. The identifier is generated by the database when it is created. The effect descriptor is stored as a string in JSON format. This is the JSON descriptor that is processed by the LED controller. The rest of the data are metadata that the frontend needs like createdAt, name, etc...

There are the hasMusicAction field that could be determined by parsing the config text but the frontend needs is separately from the config text and this way it's not necessary to respond with a huge text rather than 2 boolean values.

This model also has a foreign key(user_id) which helps to connect it to a user. There is One To Many relation between the User and LEDConfig which means multiple configs might belong to a user.

LEDDevice

Represents a hardware component. The identifier is generated by the database once it is created. the deviceID field is the unique identifier of the Raspberry device. When the hardware component is turned on and initializing it sends this information about itself and this is how the backend recognizes it. The sessionID field is generated when the hardware initiates a websocket connection. This ID helps the websocket communication between the backend and the device. There is also a status field which shows whether the device is online or offline. It also has a user_id foreign key that connects it to a user. There is a One To Many relation between the User and the LEDDevice which means multiple devices might belong to a user.

Tag

A LEDConfig can be categorized using tags(e.g.: flashing, fast, blue, etc...). Every tag has an identifier generated by the database and a name. There is a Many to Many relation between the LEDConfig and the Tag which means a single tag might belong to multiple LEDConfigs but also multiple tags belong to a single LEDConfig. For implementation an extra table is necessary to represent this relation and it's called ledconfig_tags.

View

This is a Many To Many connection between the User and the LEDConfig. It represents a view action between them. Both of the fields are foreign keys and together they are the identifier of the View entity.

Favorites

Yet another Many To Many connection between the User and the LEDConfig. The user might mark some LEDConfigs as favorite for better accessability on the UI.

Overview