{"id":644538,"date":"2019-12-16T09:11:55","date_gmt":"2019-12-16T08:11:55","guid":{"rendered":"https:\/\/www.devoteam.com\/expert-view\/how-easily-can-backend-solution-break-your-fancy-front-end\/"},"modified":"2019-12-16T09:11:55","modified_gmt":"2019-12-16T08:11:55","slug":"how-easily-can-backend-solution-break-your-fancy-front-end","status":"publish","type":"expert-view","link":"https:\/\/devoteam.info\/sk\/expert-view\/how-easily-can-backend-solution-break-your-fancy-front-end\/","title":{"rendered":"How easily can backend solution break your fancy front-end"},"content":{"rendered":"

When working on a multi-purpose IT application, there simply is no more crucial phase of the project than the initial analysis. There is a tendency to jump-start certain projects by defining user stories perceived as \u201ceasy\u201c and deliver quick-win functionalities. This, among other things, serves as an assurance that the team is able to deliver from day one, but if not done properly might bring more trouble in the future, because working on a single task without proper knowledge of the whole product is a certain way to fail in the long run.<\/span><\/p>\n

It is also the reason why multidisciplinary teams exist and why user experience experts are no longer perceived as a money-generating buzzword but rather valuable addition to new (IT non-exclusive) projects.<\/span><\/p>\n

Let\u2019s move aside from theory and explore, as the title suggests one very easy real-world example. The trouble that could arise from improper stitching of backend and frontend.<\/span><\/p>\n

Scenario<\/i><\/b><\/p>\n

Imagine a highly customized ServiceNow portal with a lot of built-from-scratch widgets. Part of the customer portal experience was supposed to be the management of entitlements. The back-end part of the epic was to get those entitlements and related table information to the database, the front-end part was to create a pleasant user interface to manage orders and approvals. One of the key features of the new UI was a custom autocomplete form suggesting information from the dedicated backend tables. The story has been described and reviewed with the customer, the solution developed and successfully tested with a response time of around 250 milliseconds (for the suggested text to appear). But when moved to production, the feature suddenly broke.<\/span><\/p>\n

\"\"<\/p>\n

What happened?<\/i><\/b><\/p>\n

It turned out that the only problem was an insufficient sample size. No real data import has ever been tested by the customer. Since company policy rules have prevented usage of the real production file, the source table has been populated only with hundreds of records instead of millions in production. And since advanced grouping and filters have been used, the performance of the autocomplete feature dropped to somewhere around 20 seconds, rendering the whole functionality useless.<\/span><\/p>\n

What could have prevented that?<\/i><\/b><\/p>\n

Two things. First: <\/span>Keep asking questions.<\/b> Unfortunately for us, we already had answers to most of these questions from the beginning. So the second part of the answer was more important to fix the issue. But let\u2019s follow the line of the question just for the sake of outlining the solution: <\/span>How many records will there be available for the form? What is the source of the table? Do we have a different more condensed source? Can we create one? Will it be possible to obtain it from your subsidiary? Will we need to source different tables in the future for different forms?<\/span><\/i> <\/span><\/p>\n

Second: <\/span>Keep an eye on performance from the beginning.<\/b> The rule of thumb should be: <\/span>if something is supposed to be big in production (as the data source) make it ten times bigger in testing environment<\/span><\/i>. See how it holds up and when it eventually breaks. By simply populating the table in advance, we could have prevented:<\/span><\/p>\n