Payment Web Engineers, Q4 Highlight, Q1 2019 Plans

Q4 Highlight

Payment Private API Deprecation

Payment Web Engineers now have already deprecate the usages of private API and some of legacy codes in Desktop Web.
There are some noticeable improvements on some of the web performance metrics (raw data: https://docs.google.com/spreadsheets/d/1dwdK0TjPm3cmCXu2g7f39SfDgch8Sl_zz53wsSjLfZ0/edit?usp=sharing).

TTFB

Payment Selection metrics improving 73.76%
Payment Confirmation metrics improving 81.29%

DOMContentLoaded

Payment Selection metrics improving 28.17%
Payment Confirmation metrics improving 24.48%

Speed Index

Payment Selection metrics improving 67.82%
Payment Confirmation metrics improving 58.72%

Payload Size

Payment Selection metrics improving 6.42%
Payment Confirmation metrics improving 5.23%

Some additional improvements include:

Better availability (less timeout message), proven by TTFB that is always below 1 second in every optimal normal request. (Timeout for web before error page displayed is 15 seconds.)
Number of server side request reduced half, since every API calls now only called 1 time in client side. (Previously, it's also called in server side.)

Increased Error Visibility

Payment Web Engineers now have an error reporting utilities that will report 3% sampled error report in the client side to be streamed to CloudWatch.
This temporary solutions applied to tackle 3rd party (Sentry) rate limit issue.

Unit Test Creation Initiation

Payment Web Engineers now have some unit tests implemented, from previously 0 unit test.
Currently, it only cover initial rendering test to ensure that deployed page will never have to have rendering failure(s).
Along the journey, we will increment unit test creation to provide better test coverage.

Q1 2019 Plans

Error Handling Standardization

Currently, we always use positive cases implementation; means we never assume that some of important API calls to be failed to execute.
This often results in some unexpected client side behavior, like infinite loading when we have back-end problems, or sudden blank page appeared without clear information.
Our aim:

Provide better error information to customer on every failure in API call and rendering logic.
Reducing invalid page request by providing graceful alert if there are some invalid parameters provided to render the page (e.g. invalid invoice ID when opening payment pages).
Provide better error behavior to reduce customer confusion.