You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an engineer with Tailwind Traders, you've learned your company is planning to launch a new website that provides stock price information to customers. Recently, an intern created a website prototype for the new application and the Lead Architect has now asked you to step in and improve the solution. Your objective is to update the app to implement automatic updates of the stock price information, but ensure communication between the client and server happens only when data changes on the server.
2
+
As an engineer with Tailwind Traders, you learned that your company is planning to launch a new website that provides stock price information to customers. Recently, an intern created a website prototype for the new application and the Lead Architect is asking you to step in and improve the solution. Your objective is to update the app to implement automatic updates of the stock price information, but ensure communication between the client and server happens only when data changes on the server.
3
3
4
4
## Prototype architecture
5
5
6
-
The server prototype has 2 functions:
6
+
The server prototype has two functions:
7
7
8
8
|Function name|Trigger type|Description|
9
9
|--|--|--|
10
10
|**getStocks**|Azure Cosmos DB|The server is responsible for reading all data from the stocks table in the database and returning that data in an HTTP response whenever the client requests it.|
11
-
|**setPrice**|Timer|A function to change the data in the database runs on a timer trigger. This simulates receiving changes from a backend system.|
11
+
|**setPrice**|Timer|A function to change the data in the database runs on a timer trigger. This function simulates receiving changes from a backend system.|
12
12
13
13
As a prototype, the intern simulated the stock feed with a timer function, which updates every minute. The client website requests all the stocks from the `/api/getStocks` API endpoint every 5 seconds in an attempt to display near real time data. This client request isn't efficient. Instead of pulling the data from the server, it's more efficient for the server to push any new stock information.
14
14
15
15
## Tasks to be done
16
16
17
17
In this module, you will:
18
18
19
-
- Run the prototype: View the client application, which polls the server for all stocks on a regular interval
19
+
- Run the prototype: View the client application, which polls the server for all stocks at a regular interval.
20
20
- Improve the application: Implement a serverless Azure Functions app to broadcast changes to connected clients using SignalR Service to product near real-time updates.
21
21
- Update the client JavaScript web application to connect to SignalR to get and display the messages.
Copy file name to clipboardExpand all lines: learn-pr/advocates/automatic-update-of-a-webapp-using-azure-functions-and-signalr/includes/2-analyze-limitations-of-polling-in-a-web-app.md
+11-13Lines changed: 11 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,17 +1,15 @@
1
1
2
2
3
-
The application's current architecture reports stock information by fetching _all_ stock price information from the server based on a timer. This design is often called a polling-based design.
3
+
The application's current architecture reports stock information by fetching *all* stock price information from the server based on a timer. This design is often called a polling-based design.
4
4
5
5
### Server
6
6
7
7
The stock price information is stored in an Azure Cosmos DB database. When triggered by an HTTP request, the function `getStocks` returns all rows from the database.
***Get data**: The first section of code, **cosmosInput**, gets all the items in the `stocks` table, with the query `SELECT * from c`, in the `stocksdb` database in Cosmos DB.
13
-
***Return data**: The second section of code, **app.http**, receives that data into the function as an input in `context.extraInputs` then returns it as the response body back to the client.
14
-
11
+
-**Get data**: The first section of code, **cosmosInput**, gets all the items in the `stocks` table, with the query `SELECT * from c`, in the `stocksdb` database in Cosmos DB.
12
+
-**Return data**: The second section of code, **app.http**, receives that data into the function as an input in `context.extraInputs` then returns it as the response body back to the client.
15
13
16
14
### Client
17
15
@@ -29,17 +27,17 @@ The server and client code is relatively straightforward: get all data, display
29
27
30
28
## Analysis of prototype solution
31
29
32
-
As a Tailwind Traders engineer, you've identified some of the drawbacks of this timer-based polling approach.
30
+
As a Tailwind Traders engineer, you identified some of the drawbacks in this timer-based polling approach.
33
31
34
-
***Unnecessary API requests**: In the timer-based polling prototype, the client application contacts the server whether or not changes exist to the underlying data.
35
-
***Unnecessary page refreshes**: Once data is returned from the server, the entire list of stocks is updated on the web page, even if no data has changed. This polling mechanism is an inefficient solution.
36
-
***Polling intervals**: Selecting the best polling interval for your scenario is also a challenge. Polling forces you to make a choice between how much each call to the backend costs and how quickly you want your app to respond to new data. Delays often exist between the time that new data becomes available and the time that the app detects it. The following illustration shows the issue.
32
+
-**Unnecessary API requests**: In the timer-based polling prototype, the client application contacts the server whether or not changes exist to the underlying data.
33
+
-**Unnecessary page refreshes**: Once data is returned from the server, the entire list of stocks is updated on the web page, even if no data changes. This polling mechanism is an inefficient solution.
34
+
-**Polling intervals**: Selecting the best polling interval for your scenario is also a challenge. Polling forces you to make a choice between how much each call to the backend costs and how quickly you want your app to respond to new data. Delays often exist between the time that new data becomes available and the time that the app detects it. The following illustration shows the issue.
37
35
38
36
39
-
37
+
40
38
In the worst case, the potential delay for detecting new data is equal to the polling interval. So why not use a smaller interval?
41
39
42
-
***Amount of data**: As the application scales, the amount of data exchanged between the client and server becomes a problem. Each HTTP request header includes hundreds of bytes of data along with the session's cookie. All this overhead, especially when under heavy load, creates wasted resources and unnecessarily taxes the server.
40
+
-**Amount of data**: As the application scales, the amount of data exchanged between the client and server becomes a problem. Each HTTP request header includes hundreds of bytes of data along with the session's cookie. All this overhead, especially when under heavy load, creates wasted resources and unnecessarily taxes the server.
43
41
44
42
Now that you're more familiar with the prototype, it's time to get the application running on your machine.
45
43
@@ -52,6 +50,6 @@ In the *local.settings.json* file of the Functions App, the `Host` section inclu
52
50
53
51
This configuration allows a web application running at *localhost:3000* to make requests to the function app running at *localhost:7071*. The property `CORSCredentials` tells the function app to accept credential cookies from the request.
54
52
55
-
Cross-origin resource sharing (CORS) is an HTTP feature that enables a web application running under one domain to access resources in another domain. Web browsers implement a security restriction known as same-origin policy that prevents a web page from calling APIs in a different domain; CORS provides a secure way to allow one domain (the origin domain) to call APIs in another domain.
53
+
Cross-origin resource sharing (CORS) is an HTTP feature that enables a web application running under one domain to access resources in another domain. Web browsers implement a security restriction known as same-origin policy that prevents a web page from calling APIs in a different domain; CORS provides a secure way to allow one domain (the origin domain) to call APIs in another domain.
56
54
57
-
When running locally, CORS is configured for you in the sample's local.settings.json file, which is never published. When you deploy the client app (unit 7), you have to also update the CORS settings in the function app to allow access from the client app.
55
+
When you run locally, CORS is configured for you in the sample's local.settings.json file, which is never published. When you deploy the client app (unit 7), you have to also update the CORS settings in the function app to allow access from the client app.
0 commit comments