Frontend System Design: Music Streaming Service (Spotify)

hi today we will discuss how to design a web application for streaming music we will cover not only the front end part but also touch on specific aspects such

as streaming protocols and different audio formats let's begin we start with a brief introduction during which we discuss references address clarifying

questions from our hypothetical interviewer and Goth requirements next we turn our attention to the architecture encompassing the

primary layers of the application like UI data models API and other elements following that we take a closer look at the process of streaming music we

discuss how we plan to implement this in the browser including the formats Technologies and approaches we intend to use subsequently we explore a general

topic common to most major web applications such as is offline mod performance and accessibility additionally we delve into

specific details of Our obligation and finally we conclude by consolidating all requirements to ensure nothing has been

overlooked first and foremost we need to find references for our application designing an app without a Clear Vision of what we are working on can be

challenging while we can and must ask clarifying questions to the interviewer it's essential to be familiar with the

context in our case possible references include Spotify Apple music YouTube music and SoundCloud this applications Encompass a

wide range of features such as audio playback playlist management and the ability to download music for offline usage since it's impossible possible to

cover all features during the interview we must ask with the interviewer about the specific areas on which we should focus on so let's move to the questions

first we need to determine which features we should support the answer is that we should show recommendations on the main page allow users to search by

track artist or albums and provide additional artist information when users click on an artist name next we need to

understand whether we should support an offline mod and if so how it should be used the answer is affirmative we should allow users to download music for

offline listening many music apps like apple music and YouTube music offer Standalone experience where users can launch them separately as native

applications do we need something like this having a native application would be useful however it's important to note

that designing a native app isn't the responsibility of a frontend developers usually so we need to consider how to

achieve it with limited resources lastly incure with the interviewer about any additional features that application should have additionally we should

support seamless playback ensuring that playback continues uninterrupted regardless of user actions on the page or when switching between

devices now we are ready to collect the requirements since the interviewer has provided a clear picture of their expectations it should be relatively

straightforward for us in different situations we should refer to the features of similar apps and ask more clarifying questions so let's start with

functional requirements users can listen to music playback should not be interrupted by

any actions on the page users can search by track name artist or album user can click on the artist name or album to

access more information we should build and display personal recommendations for users such as popular songs or tracks

from their favorite generous we should synchronize the state between different devices if a user starts listening to a

song on their desktop and switches to a mobile phone we should remember the last played song nonfunctional requirements the application should be accessible to

people with different disabilities it should perform efficiently it should be internationalized

it should have an offline mode allow users to download tracks for offline listening and it should work well on

various types of devices now is a perfect moment to check all requirements with the interviewer before beginning designing it's better to ask questions

now rather than spend time developing the wrong features let's look on the high L architecture this is an initial overview

and we will add more details later however let's review what we have so far we're using the classic modern view controller pattern or MVC I prefer this

pattern because it's well suited for describing a typical web application separating components into layers provides a reliable and clean

architecture allowing changes in one layer without affecting other part of the application the architecture consists of three main

components view controller and model our schema is more complex so let's Del into the details the view or UI is the visual

layer responsible for displaying UI elements on the page in our case it includes four main components main screen art screen search screen and

player the main screen is the initial page which users see when they open the app where we present recommendations to the user the artist screen offers

detailed information about arst including descriptions and list of songs and albums search is separate page in our case as it might include multiple

entities such as songs and songs and artist requiring ample space to display result results effectively and player is

responsible for playing music the controller serves as the core of our application responsible for connecting

the view and model The View doesn't fit data directly from the model or server it does it through the controller the same applies to writing data The View

doesn't directly update the model instead the controller handles View events the model consists of two parts the client store and responses cach it

is crucial to distinguish between the these two types of stores the client store is for storing client only data including input values sorting

parameters or for example last scroll position everything not received from the server and not requiring synchronization with it on the other

hand the responses cach stores server responses and typically contains immutable data we have separated API model into a distinct layer only

responsible for handling Network request related to the server all interactions with the server should occur in this model in other words the controller

works with the API model as if it's a unaware of the server's existence with the front end s side complete let's now turn our attention to the back end we

have two servers app server and web server the web server responsible for delivering assets like JavaScript CSS

and HTML files and the UPS server primarily managing data related tasks for example when users request a song search The Observer handles the request

and Returns the results let's look on the user interface normally you shouldn't sketch the UI during the interview but it can be

helpful to have a mental picture keeping the overall UI design in mind can help us to create a more cohesive application here's the main screen with

recommendations which includes other things like recent releases or most popular songs the next is a search screen displays the results of a search

including songs artist and albums an artist page provides additional information notably each screen includes

a player as one of the requirements is to ensure seamless playback the next question is how we should render the application there are two

primary options client site rendering and server site rendering each has its suitability in specific cases client site rendering is easier to develop and

maintain it provides smooth transitions between Pages without additional loot time however it has bad search engine optimizations first contentful paint and

time to interactive metrics from the other side serite rendering provides good search engine optimizations and good time to interactive and first

contentful paint however it also has slower transitions between Pages as we need to make request to the server for each page and it's more challenging in

development and maintenance client site rendering and server site rendering are based solutions that can be enhanced for instance in client side rendering we can

Implement preloading assets and displaying loers until the application is fully rendered in the case of cite rendering we can Implement gation to

render a static page on the server and quickly deliver it to the users but this results in a non-interactive page for some time we can improve gereration by

using partial gation and Progressive gereration topics that require more in dep exploration before selecting an approach we must consider our priorities

since we're designing a web app fast initial loading is essential but not as critical as for a landing page good search engine optimizations is necessary

primarily for promotional pages but not for the app we expect our application will be highly interactive with numerous

onscreen elements that must function smoothly and most importantly we must ensure continuous play de which rules

out any form of serite rendering based on these priorities we can extract the main requirements fast switching between pages and continuous playback without

page reloading client side rendering fulfills both of these requirements however it comes with significant downsides if we load the entire bundle

and start executing Java Script on the client side it may take too much time especially on low performance mobile devices

leading to what's know as the blank page problem in some cases user may look on a blank page for more than 10 seconds which is unacceptable we must find ways

to improve this we can utilize client site rendering along with preloading by showing users a skeleton prel loader we can eliminate the impression of a frozen

page which might lead users to leave additionally implementing aggressive cut split by user by using modern bundle

bunders like weback or rollup allows us to split the JavaScript bundle into smaller chunks in our case this could

result in three chunks one for main page one for artist page and one another for search page we can go even further by

breaking these chunks into smaller parts more specific components and laely loading popups and other assets that are

not immediately necessary the key idea here is to combine client side rendering with efficient Cod splitting and preloading so the bundle size scales

according to the application size preventing and necessary loading the next topic is data model our data model comprises three primary

entities song album and artist each song has one or more authors and optionally belongs to an album each album consists

of one or more songs and has one or more authors both albums and songs should be associated with one or more generous

chener is represented as an anom with predefined string values like rock pop classic music Etc each entity has a URL

field such as s urel or artist URL which is necessary for sharing for instance if a user like a song they may want to

share it with friends requiring a sharable link we have discussed the data model but now we need to address how data will be transmitted between the web

application and the server there are three main options rest API RPC approaches with grpc developed by Google being the most popular and graphql API

rest API is the most flexible and straightforward approach suitable for various API structures it interacts well with browser caching and offers a reach

set of tools finding developers experience with rest API is generally not a problem however its flexibility can lead to a lack of standardizations

as rest is essentially a set of rules rather than framework each developer or team decides which rules to follow making it challenging for new team

members to work with apis that may deviate from expected Norms additional checks are often required to validate responses from the server RPC approaches

differ significantly from rest instead of describing entities RPC focuses on methods for example consider a method

called delete item in the rest you would use the entity name and the delete method whereas in RPC it resembles a

plane function in for example JavaScript the idea behind RPC is to obstruct the technical details from the end users

user simply request the deletion of an item and the method handles the rest RPC offers several advantages high performance strong security Cod

generation allows to automate and point creation contracts to ensure data consistency between the backend and the front end side sites however RPC is not

natively supported by browsers and can be more complex often used for cross server interactions and then there is a graph Quil graph Quil is a powerful query

language that allows fetching only the required Fields making it a deal choice for situations where entities are tightly coped for example like in our

case graph Quil supports features like cod generation static analysis and offers a good developer experience when considering trade-offs it's challenging

to find some particular weaknesses in graph coil it does add complexity to development but any other tools do the same and its suitability depends on the

specific use case unlike rest API graph Quil is not a general solution and it's not suitable in many cases like for example streaming before we go further

it would be useful to clearly understand what tightly culate data means in our scenario we are dealing with three main entities song artist and album All of

which are tightly interconnected there is a high chance that at the same point in the app we will need to simultaneously access several fields

from the songs entity and at the same time fields from the artist entity without graph Quil we would be required to make two separat requests for these

two entities and then merge them on the client side however with graph Quil we can simply make a single request moreover in the case of the rest API we

might potentially have to request all fields from both entities which is typically not needed as mentioned earlier graph Quil permits the featuring

of only the required Fields before choosing a protocol let's consider how our app will interact with the server first we need to stream audio files

authorization support is is crucial our entities are tightly coupled for example fetching artist with all their albums and songs is a typical request not all

fields are necessary on every screen for instance the main screen may require only the song name and cover by clicking on it could reveal more detailed

information based on these considerations we can identify two primary requirements F only the data that is needed and support streaming and

authorization graph Quil effectively addresses the first requirement however we also require support for streaming and authorization therefore the best

approach is to use two protocols together graph Quil for data and rest API for all other interactions certainly this approach is more complex to devel

develop and more expensive however it offers scalability and becomes more Val avilable as the application

grows the next topic is backend for front end or BFF it's an additional layer positioned between the front end and the back end the idea behind a BFF

is to create a dedicated back end for each user experiences such as mobile or desktop instead of having a single General port purpose API backend

alternatively you may opt to have one BFF server serving all clients now let's explore situations where you might need

a BFF when your app is used across various devices each with distinct requirements and capabilities for instance mobile devices usually have

lower performance but they have access to features like the camera and QR code scanning when there is additional logic or intensive competition ations that can be moved from the client side to the

server certainly supporting an additional server requires additional resources so if you decide to use it be prepared for increased expenses moreover

your team should has some knowledge of backend development in our scenario the frontend team would be responsible for

both the web and the BFF in our case we need to manage more than one client at least desktop and mobile clients making

the addition of a BFF a sensible Choice additionally since we have recently choosing to incorporate graph coil the BFF is a suitable place for its

implementation let's consider the arms architecture after adding the BFF layer we have placed it between the client and the back end which means every Quest

passes through the BFF in the BFF we have implemented both a a graph Quil API and rest API on the backand side we

still have only rest API moreover if we need features that the back end doesn't currently support say custom data filtering we can Implement them in the

BFF the back end typically should be more robust and generic since it handles many clients it might not always be

feasible to add specialized code for each client as it can lead to unmanageable complexity the BFF on the

other hand is a flexible layer designed to serve specific clients or client types one of the roles of the BFF is to handle resource intensive citations

instead of doing it on the client side we won't go deeper into the API specifics since we have opted for graph Quil for data handling which abstracts

away much of the complexity if you're are UNAM familiar with graph Quil it's a query language for apis and a runtime for fulfilling those queries with your

existing data craft Quil empowers clients to request precisely what they need and nothing more the primary point of our interest is to implementation of

the search functionality as you might remember we need to implement Searchers uh across multiple entities entities

simultaneously artists songs and albums s we might request users to specify the category before searching and we should

retain this filter in search settings by default the search should work across all entities on the back end we determine the best matchet results and

send them to the client we initially display let's say five songs five artists and Five albums the exact count

depends on the screen size and can be larger on desktops if this isn't this isn't sufficient users can click on more

results button for a specific entity this leads to at least four distinct endpoints one for mixit search results

one for songs one for artist and one for albums the next significant topic is streaming a core feature of our application let's go into the details

first and foremost let's differentiate between streaming and Progressive downloading Progressive downloading is the method used by the HTML 5 Audio element by default it involves

downloading audio in chunks and allows user to start playing content immediately after the first chunk is downloaded Progressive downloading has

two key distinctions from real streaming meta content is stored in the users device browser cache users canot jump to a specific audo segment they must wait

for all previous segment to download with streaming the browser doesn't store the audio in memory instead the audio is trimmed directly to the user's device a

helpful analogy is that when you click the pause button with Progressive downloading playback is PED on the client side while the audio continues to

download in the background with streaming when you click pae both playback and downloading from the server are passed simultaneously let's discuss

the pros and cons of each approach Progressive downloading provides instant audio playback the track starts as soon as the first chunk is downloaded users

traffic savings files are downloaded once and can be cached for later use support for offline operations files are stored on the user's device and it's

easy to implement HTML 5 AIO element inherently support Progressive downloading however it lacks support for fast seeking meaning users can job to

specific audio segments potentially increasing their data usage Progressive downloading also raises security concerns as files must be stored on the

user's device as a result several advantages come with tradeoffs Progressive loadings used for short tracks where fast seeking f Futures and

security ear crucial from the other side streaming offers fast seeking efficient band white utilization and enhance

security however it's not useful when users don't have an internet connection as it doesn't store files on the device it also requires more complex

development and maintenance streaming is ideal for longer tracks that require fast seeking features and Security in

our case where we might have short songs or long podcasts and aimed to protect audio files from unauthorized copying

and distribution streaming is a preferable Choice streaming isn't natively supported by browsers so you

need to use meta Source extension or msse to enable it meta Source extensions extends the capabilities of of video and

audio elements enabling Dynamic changes to a media stream without requiring plugins this technology supports features like adaptive meta streaming

live streaming video splicing and video editing msse provides native streaming support for the HTML 5 audo Element

without the need for additional browser extensions previously apps had to rely on browser extensions like flash or silver light to enable streaming even if

you don't plan to stream extended tracks implementing MSE can be beneficial as it offers greater control over content

delivery including support for custom protocols furthermore if your audio content requires digital Rights

Management or DRM for protection content msse allows you to handle encrypt Auto streams ensuring secure distribution and

Playback the one challenge with msse is browser support as a fallback option you can utilize the native HTML 5 Audio

element for Progressive downloading now let's consider the streaming protocols while HTTP is the default option it

natively supports Progressive downloading rtmp or realtime messaging protocol is a communication ation protocol used for streaming audio video

and data over the Internet originally developed by MCR media for use between Flash Player and the Flash communication

server HTTP live streaming or hls is an Adaptive betray streaming protocol developed developed by Apple Dynamic

adaptive streaming over HTTP or Dash also known as impa Dash is an Adaptive betray streaming technique that enables

high quality streaming of meta content over the Internet delivered from HTTP web servers similar to Apple's hls

solution and pack Dash works by breaking the content into a sequence of small segments which are served over HTTP HTTP

supports only Progressive downloading not streaming but it's straightforward to implement rmp supports streaming but it requires

additional extensions to be installed both hls and dash are modern solutions hls has better browser support due to

its age while impa Dash is format independent in other words we're not limited in choosing an outo format with

Dash whereas hls supports only AAC MP3 AC3 and and EC free formats so if we opt

for hls we are limited by these formats so what is suitable for our case we can't use HTTP as the primary approach

since it doesn't support streaming rtmp lacks native browser support and requiring users to install additional

extensions to use our app would be inconvenient hls is natively supported

through Apple software but Dash and hls are well supported where MSE let's look at the streaming

protocols used by popular streaming services YouTube music supports both hls and dash Apple music supports only hls

Spotify employs its OV proprietary protocol for our app we will use Dash because it's modern support streaming

and it is codic agnostic the next topic is audio formats since we have choosen Dash we have the freedom to select the most suitable

audio format for our needs the oldest format M3 is widely supported and M3 files have relatively small sizes however there are better Alternatives

available today in terms of quality and size one such alternative is AA PC or Advanced Audio codic it's an audio codic standard for digital audio compression

designed to succeed the emper free format offering higher sound quality at the same bit rate while emper free and AAC were designed for playing audio

files the next two formats oppos and a verbus were specially designed for streaming audio content appos provides good quality and a wide range of bit

rates while a Serv offers better quality than mree at similar bait rates it is widely used by streaming services and is

op sourced which may be advantagous depending on our go our company's goal let's see what real applications use QP

music supports AAC and oppos apple music supports AAC and apple lossless aut coduct or

alac which is open source and royaltyfree Spotify uses AAC and aerbus for our service we prefer to use

AC and ag verbus ag verbus is designed for streaming purposes and is open sorts which is generally favorable as notal

browsers and devices support streaming we also have AAC as a fallback other streaming services typically allow users

to change the bit rate to their needs additionally it is possible to adjust the bit rate dynamically through

streaming via msse Dash or hls depending on the users Network conditions in some cases there may be browser compatibility

issues some browsers do not support msse with certain audio formats it means that we need to support different audio formats based on the browser that's why

it's important to support at least two formats to to provide broader device compatibility in our case AC plays the role of the format supported by Major

devices and browsers the next topic is encrypted Med extensions encrypted Med extensions provide API that allo browsers to interact with content

protection system or CPS which includes content encryption model or CDM meta content is encrypted so users cannot access it outside the application this

is necessary to prevent illegal distribution this requires the use of special servers that provide access to

these content such servers are called DRM servers the is the provider between the encrypted meta content and the DRM

server now we have more details about our system let's see how CDM andm interact with the other

components first the API request the audio file meta metadata including the audio URL after receiving the metadata

the controller passes it to the player's component next the player sends a request to the amme which calls the CDM

that built into the browser the CDM requests a license key from the durm server the DRM server generates a

license key and sends it to the client the client passes the key to the CDM which then decrypt the media content and

finally the user gain access to the content additionally to using MSE we can take it a step further and use the

modern web audio API however not all browsers supported we may Implement a graceful degradation technique depending on the browser we will approach one or

multi multiple of the following Solutions HTML 5 native audio element msse and web audio API the HTML 5 Audio

element offers very basic audio Playbook the web audio API is more complex but provides additional features such as mixing processing filtering and

crossfading the HTML 5 AO element has better support from browsers MSC falls in the middle it has relatively good browser support but like some features

found in the web Alo API in our case we will start with the HTML 5 Alo element as a fallback for Al the browsers depending on the browser we will upgrade

the Alo player progressing to the next step in other words for users with Al browsers we will provide the minimum required features allowing them to still

use our application for users with modern browsers we will offer all possible features let's look on the comparison We Begin from the left side

the native audo element is a very basic solution it's easy to develop and has good browser support however it has limited features metas Source extensions

has many more features including preloading and streaming V hls and dash however browser support is less extensive and it requires more resources

for development and maintenance and for web audio API it provides numerous audio related features like mixing processing

filtering but browser support is worse and it Demands a certain level of expertise to work with effectively as we

discussed earlier we plan to implement all these approaches but will'll utilize them depending on the client's browser the next feature is an offline mod

offline mod is crucial for streaming music applications users want to access their music catalog when they don't have an internet connection imagine a

scenario where a user downloads music in advance to listen it during a flight so what features should offline mod support we should display the current Network

status and inform the user that they are offline while also prompting them to go to the list of downloaded files users can browse downloaded music and of

course they can play it but how can we make our application work when users have no internet connection if the browser can't reach a reme server it

simply returns a not found error right yes unless we find a way to intercept it service workers can help us here let's

look at what a service worker is service worker are built in the browser service workers act as a proxy between the web application and the back end service

workers can listen to incoming requests pass some of them to the network and store a copy of the response for future

usage where the cash storage API the cash storage API is for storing assets such as HTML CSS and JavaScript files it serves as a browser cache for storing

data fish responses by utilizing the cach storage API service workers can reduce Network utilization even if we don't need a fine

mod in simple terms service workers allow us to cash assets store them and use them offline when a user has no connection we can simply retrieve the

page from the cache let's see how a service worker works together with a cache storage API when a user has an internet connection first the application

requests assets HTML GSS and CSS file files the request is intercepted by the service worker the worker checks the cash storage if assets are cached they

are rried from the cach and returned to the web application if the assets are not cached they are faged from the web server the web server sends the assets

to the web application the service worker stores the Assets in this cash storage next time they are needed they are retrieved from the cash without a

request to the web server and the service worker sends the asset to the web application and finally web application uses them to render the page

however without content assets are not very useful what is the use of blank pages if users can do anything with them storing assets is not enough we should

also store Meda files of course we can store all the music on this users device but we can offer them them the option to

store the favorite tracks or any other tracks what we can use for storing media data we have two options local storage

the only advantage of this is that it's easy to develop it has limited capacity typically 5 or 10 megabytes depending on

the browser it doesn't support binary files and has a slow synchronous API another option is indexed to be it

offers a relatively larger capacity for example in Chrome it can use up to 80% of the available space and allocate a

maximum of 75% of the space for each origin It natively supports binary files has a fast asynchronous API and is a

future reach client side database however the wealth of Futures leads to a very complex and convoluted API which

can discourage many developers in our case we have no choice local storage is not suitable because it's has really small capacity for storing Meda files

therefore we opt for indexb you may wonder why not use the cash storage API which we use for storing assets for storing Med files as

well the cash storage API provides a limited set of options and does not give us enough control over the downloading process it doesn't allow us to easily

pause and resume download track the progress of downloads or properly responds to http rench requests HTTP rench requests ask the server to send

only a portion of an HTTP message back to the client rench requests are useful for clients like media players that supports Random Access Data tools that

know they need only part of a large file and download managers that allow users to pause and resume downloads for instance if we're downloading several

files some of them may be large and we can pass some of them and continue with other to prioritize loading and perform other tasks therefore we need more

control over downloading and storing media files before we move to the file downloading we should know how to decrypt media files as you remember

where are using DRM to do that in normal situation however without internet connection it becomes impossible persistence license may help us

persistence license can be stored in a local license store on a device and Playback clients May reuse the C license

repeatedly until it's removed or becomes expired persistent license are needed when we don't have access to the license

server due to no inter connection or for another reasons the disadvantage of persistent license is that you cannot revoke them before they expire the

license should be valid for a limited time approximately one week after which it must be refetch when the user access

the internet we are using a persistent license to decrypt files and allow users to listen to other content now that we

have all needed elements let's see how downloading music should work assume that the user has already downloaded the

music and we have put it into the indexb now let's look at the FL scenario the web application is trying to retrieve

the data but the user has no internet connection since we can download the assets from the server we need to retrieve them from the cach storage to

render the page the application goes offline shows the network status and prompts the user to go to the download

directory we assume that the audio files has been preloaded by there are encrypted the user uses the preloaded

persistence license to access the files the next topic is a native application it would be nice if our users could use the application separately from the

browser it is very convenient and gives us more control we assume that we don't have a dedicated team to develop a desktop app so the same team will

develop the web version and the native version the native application should be relatively easy to develop for the frontend team in other words it must use web Technologies we have two possible

options here electron or Alternatives and Progressive web application when talking about electron we don't forget that electron is just one tool that that

utilize web Technologies to provide a netive experience it has its pros and cons so feel free to use any electron alternative that is more suitable in

your case electron is a framework that allows developers to build applications compatible with Mac OS windows and Linux

using web Technologies like GS HTML and CSS electron is crossplatform electron allows you to build desktop applications

that can run on Windows MOS and Linux without major modifications access to Native apis electron apps can access

native system features and apis making it suitable for building future reach desktop applications it has large development Community electron has a

large and active Community which means you can find plenty of resources plugins and support it's independent electron Works separately from the browser

it's an dependent instance of chromone however it has bigger size electron apps tend to be larger in size compared to PW

as they include a bonded version of herum along with your app code since electron apps run a separate instance of chromium they can consume more system

resources leading to potentially higher memory usage a progressive web applications is a type of application software delivered through the web built

using common web Technologies including HTML CSS and JavaScript it is intended to work on any platform with a standard

compliant browser including desktop and mobile devices this crossplatform pwas are accessible through web browsers

making them crossplatform and compatible with various devices it has smaller size pwa are generally smaller in size

compared to electron apps since they do not require a bondet runtime like like chromium it has better search engine

optimizations PW can be indexed by search engines and discovered like regular websites potentially increasing

your apps visibility however it has limited access to Native apis PW are still Limited in terms of accessing

certain native API and system features compared to electron apps and also it's browser dependent pwa shares a Hing

process with a browser it means that users can close the browser if they want to keep the application workable it also

means that the PW share resources with the browser so what is better based on the description of both approaches we

can conclude that PW a is a good for cases when we don't need all the features of the Native API and at the same time the speed and simplicity of

development are important developing a pwa is much easier than building an electron app and electron and alternatives are a good choice when

we're developing feature reach applications that need to access native apis and system resources real YouTube

music uses a wa you can identify it by opening it in a browser and looking for the pwa icon in Chrome it's located on

the right side of the address bar I don't know what Apple uses for Apple music Spotify uses herum embeded framework which is one of the

alternatives to electron for our service we will use a pwa initially this is more suitable we don't know whether our application will be successful or not so

we can't allocate time and resources to build a complex native application a pwaa provides us with a possibility to

launch a mobile app and desktop app relatively easily with minimal resources now let's talk about the streaming optimizations what if a users wants to

play a favorite songs many time how can we optimize this scenario just as we store saved music we can also store frequently played music the only

difference is that this data needs occasional cleaning this means we can turn to our old friend nxb once again if

we discover that a user is replaying a song rather than streaming kit we can download it and save it into indexb let's see how it works when a user

begins to reply a song we first need to check if it's already saved locally and in indexb assuming that indexb does not

contain such a file the web location requests the file from the CDN the audio files are then transferred to the client

once all the chunks are downloaded we can group them together and store them in indexb the audio file name should not be

used as a key in fact the ID should be used when the user wishes to replay this song it will be retrieved from index cdb without a nwork

request let's discuss synchronization we anticipate that our application can be used on a variety of devices a user might start listening to an album or

song at home and then continue listening from a mobile phone while outside we need to store the following playback information current song The Point from

which playback should continue and Playback context the the playback context includes the list to which the current audio file belongs it could be

an album a list of favorite or recommended songs or something else we need the context to determine which audio file should be played next or

previous the playback context may also contain other useful information memorizing the point from which Playbook should continue may not be very

convenient for short tracks but it is useful for long DJ sets and podcasts we may implement it for audio longer than

10 minutes so let's see how it works when a user starts playing an audio file either manually or automatically we send all the necessary data to the

application server later when the user switches devices or browsers we retrieve this information to continue playback we know that the current audio files belong

to to a specific album or list and we know the track position from the album ID we can determine which track should be played next or previous consider how

we can implement the future to remember the last playback Point imagine a user listening to a long a track like a podcast they wouldn't want to start from

the beginning every time we can't use local storage for saving this position since users may switch device deves the only options here is to store it on the

server side if we do that how often should we update this state we can't do it too frequently as it would create a heavy load on our servers yet we can't

do it too infrequently either possibly we can send one request when a track is stopped for any reason think about both

scenarios or explore alternative Solutions the next topic is adapting the application for mobile devices mobile devices differ from desktop they have

smaller screens and generally less powerful processors and memory we must consider these specifics we shouldn't download high resolution images on

devices with small screens we can use the SRC set and the picture HTML elements to control which image to load

Mel devices including cell phones usually have screens while this offers certain possibilities it also presents limitations hover and focus events are

not possible on touch screens so we must find alternative ways to interact with the app all interactive elements should be large enough to ensure the touch area

is bigger than the visual size of the element and text content should also be large enough to be readable on small screens on small screens we can't afford

to display wide banners large decorative elements Etc the user experience should be centered on the main content we can use CSS meta queries to create different

versions of the user interface and finally we should avoid aggressive preloading as mobile devices typically have slower internet connections and

limited data traffic performance is a broad topic and we can't cover it all I prefer to ceg R it into five areas

Network images audio UI and jscript and CSS I've grouped JavaScript and CSS together because they are both related to the code from the network side we can

use data compression jip and Broadley Broadley is a relatively new compression algorithm developed by Google it employs a modern compression algorithm optimized

for the web and generally achiev gives better compression ratios than jzip brle is a particularly effective on text based files formats like HTML CSS and

JavaScript however it's not widely supported as gz which means that some older web browsers may not be able to decompress broadly files gz on the other

hand is an older and more established compression algorithm that has been used on the web for many years it is supported by virtually all modern

browsers ensuring that you compressed files will be readable by the majority of users jzip is also a good choice for compressing binary files such as images

and videos as it can achieve good compression ratios on these files types the other recommendations are use the

latest version of protocols such as HTTP to zero or higher Implement caching cets which we did VI cash storage API request the minimum required fills where the

graph Quil API preload critical data and defer loading non-critical assets such as popups and IDs scripts for images we

will employ lazy loading meaning we download an image only when it's needed we will also use modern media formats

like webp for images and webm for videos although we haven't discussed video in details if included we should prefer

using the web M format web web m is an alternatives for webp but for videos we should law the appropriate image for

each screen using the SRC set attribute and picture HTML elements for audio files we will use modern AO ccts such as

AAC and a verbus additionally we're using the modern Dash streaming protocol which allows us to stream audio files instead of downloading them saving user

storage space for elements that we can significantly speed up we can at least make them appear faster instead of standard spinner we can use skeletons

with a shimmer effect these skeletons simulate a real UI helping user better understand how the final page will look we should also provide smooth

transitions such as fadings slidings or animations between screens and other interactive elements on the page we should utilize light weight icon fonts

or svgs for icons and buttons and avoid loading redundant fonts we might even go further and limit fonts variations and

symbols downloading only what's necessary in JavaScript we should avoid JavaScript animation when possible additionally we should steer clear or of

heavy computations on the client side opting to move them to a web worker or to the server site recognizing that operations with Tom elements can be

resource intensive we should stri to reuse Tom elements instead of creating and removing them whenever it's possible finally we should split the bundle into

chunks as we discussed earlier when using a single page application it's crucial to divide the application into chunks and load them only when needed

regarding CSS we should prefer CSS animations however it's ESS essential to be aware that CSS animations also have performance costs the safest animations

in terms of performance are opacity and transform animations we should follow naming conventions like bam unless we're using other approaches such as CSS

models or stylid components naming conventions not only help maintain code consistency but also improve performance as only the first level selectors are

highly efficient first level selectors consist of a single selector the next topic is accessibility while it can very depending on the specific app we can

focus on some general recommendations for all non-decorative images we should use meaningful alt attributes use appropriate Ro attributes

the RO attribute describes the function of an element for programs that can make use of it such as screen readers use AR label or ar labeled bu for

interactive elements without labels when an element doesn't have accessible name especially in cases like buttons with only icons the aror label attribute can

be used to provide a meaningful label pay attention to color contrast to ensure readability and accessibility these can be checked using tools like

Lighthouse which is built into Chrome ensure that all interactive elements can be navigated and operated using a

keyboard include transcript for audio content whenever possible and make sure that errors are clearly communicated

both visually and through screen readers the next topic is internationalization which involves preparing application for translating on

different languages and translating text content preparing application for translating on different languages includes things like attempting to prict

the users laale using a combination of the accept language HTTP header and IP address however users should also be allowed to change it if they wish

remember that one country may have multiple languages and users may use VN consider differences in worth length carefully review the user interface

especially in interactive elements pelo localization may be helpful here P localization is a technique used for testing localization it involves using

AO language instead of a real language it keeps string readable but highlights problematic areas common to real languages it helps quickly identify

places without translation and can involve adding some characters to the P translation to identify and flex UI

elements avoid using string itation as words may appear in different places in different languages do not put text in

images because it's not scalable and use logical properties instead of directions these steps can significantly improve the accessibility and user

experience of your application for a global audience now let's focus on the next question how do do we translate the text in order to translate the text

effectively we need to decide on the format for saving translations and the method we will use for

translation format options include Json IU message format get text and other formats translation methods includes TMS

or translation management system internal translation team external translation team and other options before selecting a format it's essential

to choose an approach to translation not all formats are compatible with all methods I have prepared a table that outlines approaches suable for different

project sizes on the left side are approaches that work well for small projects while the right side present scalable approaches more suitable for

large projects translation agencies and Freelancers medum to high cost depending on the project sites quality various but

it's usually good enough low wender log as we can change agency easily since we manage translations on our servers and

it's suitable for small projects usually translation software or API medium budget quality depends on the underline

translation model low window loog as we can easily change software suitable for small to medum projects localization

service bigger budget than simple translation low to medum wendlock Ideal for medium to large applications when

launching in different markets and simple text translation isn't sufficient internal translation team

good quality but can be costly it may be free if If part of a larger company with an existing team it's suitable when planning long-term app

development TMS or translation management system a system designed for managing localization and translations

suitable for projects with a big budget and substantial scale High vendor log so choose carefully each approach has its

advantages and limitations making it crucial to align your choice with your project specific needs budget and long-term goals next we must determine

the format in which we will store translations not all services work with all formats so this decision is critical

first one is Json Json is a human readable format it's easy to work and very flexible well flexible Jon loocks

specific standards for Trans translation management you will need to create your own structure for handling translation within Json files this format may not

offer as many features as dedicated translation libraries potentially limiting your ability to handle pration

context or dynamic text formatting C text format in contrast to Json get text was especially designed

for translations get text is the oldest format among these three and is well established for managing translations in software development CeX supports

essential features like pluralization and context making it suitable for a wide range of translation needs however

C text may have a stepper learning curve if you're not already familiar with it cext files are not human readable as Json files which make translation men

management slightly more challenging and the last one ICU or International components for Unicode format ICU is an open-source crossplatform set of

libraries providing uni code and globalization support for software applications it supports numerous features including date time formatting

numbers currency formatting ICU is the most powerful among these three formats but is also the most challenging to learn and work with it is most suitable

for projects with complex translation requirements but maybe overkill for smaller projects while many services support Json it's essential to check

whether the services you're plan to use support gex or ICU if you opt for these formats in our case since we don't anticipate highly complex translations

Json serves as the most universal for format it is especially suitable if we have an internal translation team

alternatively we can utilize translation or lionization software depending or on our expansion plans for other markets

translation agencies and Freelancers are preferable When developing a website or a small web application without scalability Ambitions in such cases they

can be more convenient than than building a system to interact with various devices translation Management Systems may be an overhead for our

application since we don't have an extensive amount of text to translate and that's the conclusion

let's review all the requirements once more to ensure we have covered every aspect let's examine the functional requirements music listening we have a

addressed audio files delivery and implemented a graceful degradation approach for music playback we have discussed the search functionality both

its General operation and its application for specific entities users see personalized recommendations on the home screen when

open the app synchronization between devices we have introduced a system for synchronizing the current track and

context across different devices or browsers now let's consider the non-functional requirements our app is designed with

accessibility in mind following best practices to ensure it's usable for people with various disabilities we have taken various

approaches to guarantee the high performance of our application our development includes an offline mod allowing users to use the

app even without an internet connection we have taken steps to ensure our application functions seamlessly on various types of devices and

internationalization we have prepared the application for translation into different languages that's all for today I will include all the relevant links below if

you found this video useful please don't forget to click the like button and subscribe to the channel stay tuned for more upcoming videos thank you for watching and see you next

time bye