Abstract: A request is received from a client for data to render a modular contained widget component of an application user interface. Whether the requested data is cached at an intermediary server is determined at the intermediary server, wherein the requested data is based at least in part on one or more database records stored at a backend server. In response to a determination that the requested data is cached, the requested data is obtained from an identified cache instance that cached the requested data. The cached requested data is based at least in part on the one or more database records provided by the backend server to the intermediary server to maintain an updated version of the requested data at the identified cache instance. The requested data is provided to the client from the intermediary server.

Abstract: A request is received from a client for data to render a modular contained widget component of an application user interface. Whether the requested data is cached at an intermediary server is determined at the intermediary server, wherein the requested data is based at least in part on one or more database records stored at a backend server. In response to a determination that the requested data is cached, the requested data is obtained from an identified cache instance that cached the requested data. The cached requested data is based at least in part on the one or more database records provided by the backend server to the intermediary server to maintain an updated version of the requested data at the identified cache instance. The requested data is provided to the client from the intermediary server.

Abstract: A server includes a data cache for storing data objects requested by mobile devices, desktop devices, and server devices, each of which may execute a different configuration of an application. When a cache miss occurs, the cache may begin loading portions of a requested data object from various data sources. The cache itself may be divided into multiple partitions, and each of the partitions may be assigned to a specific attribute, such as an application configuration. Portions of the data object may be loaded into corresponding cache partitions based on the attributes of each. Although part of a single cache, each of the partitions may be independently assigned different cache replacement policies. Performance metrics for each of the partitions may be monitored and used to update the cache replacement policy for each partition at runtime without interrupting response traffic.

Abstract: A request is received from a client for data to render a modular contained widget component of an application user interface. Whether the requested data is cached at an intermediary server is determined at the intermediary server, wherein the requested data is based at least in part on one or more database records stored at a backend server. In response to a determination that the requested data is cached, the requested data is obtained from an identified cache instance that cached the requested data. The cached requested data is based at least in part on the one or more database records provided by the backend server to the intermediary server to maintain an updated version of the requested data at the identified cache instance. The requested data is provided to the client from the intermediary server.

Abstract: A server includes a data cache for storing data objects requested by users logged in under different user roles. Different user roles may have different permissions to access individual fields within a data object. When a cache miss occurs, the cache may begin loading portions of a requested data object from various data sources. Instead of waiting for the entire object to load to change the object state to “valid,” the cache may incrementally update the state through various levels of validity based on the user role of the request. When a portion of the data object used by a low-level user role is received, the object state can be upgraded to be valid for that user role while data for higher-level user roles continues to load. The portion of the data object can then be sent to the low-level user roles without waiting for the rest of the data object to load.

Abstract: An embodiment may involve, based on a pre-defined trigger associated with a particular application, reading error data from a resource that is used by the particular application, wherein persistent storage contains definitions of a plurality of error scenarios, a plurality of fix scripts, and associations between each of the plurality of error scenarios and one or more of the plurality of fix scripts; applying one or more rules to the error data, wherein the rules involve pattern matching or parsing; based on applying the one or more rules, determining a particular error scenario represented in the error data, wherein the particular error scenario is one of the plurality of error scenarios; determining, based on the associations, a particular fix script associated with the particular error scenario, wherein the particular fix script is one of the plurality of fix scripts; and causing execution of the particular fix script.

Abstract: An embodiment may involve, based on a pre-defined trigger associated with a particular application, reading error data from a resource that is used by the particular application, wherein persistent storage contains definitions of a plurality of error scenarios, a plurality of fix scripts, and associations between each of the plurality of error scenarios and one or more of the plurality of fix scripts; applying one or more rules to the error data, wherein the rules involve pattern matching or parsing; based on applying the one or more rules, determining a particular error scenario represented in the error data, wherein the particular error scenario is one of the plurality of error scenarios; determining, based on the associations, a particular fix script associated with the particular error scenario, wherein the particular fix script is one of the plurality of fix scripts; and causing execution of the particular fix script.

Abstract: An embodiment may involve, based on a pre-defined trigger associated with a particular application, reading error data from a resource that is used by the particular application, wherein persistent storage contains definitions of a plurality of error scenarios, a plurality of fix scripts, and associations between each of the plurality of error scenarios and one or more of the plurality of fix scripts; applying one or more rules to the error data, wherein the rules involve pattern matching or parsing; based on applying the one or more rules, determining a particular error scenario represented in the error data, wherein the particular error scenario is one of the plurality of error scenarios; determining, based on the associations, a particular fix script associated with the particular error scenario, wherein the particular fix script is one of the plurality of fix scripts; and causing execution of the particular fix script.

Abstract: A server includes a data cache for storing data objects requested by users logged in under different user roles. Different user roles may have different permissions to access individual fields within a data object. When a cache miss occurs, the cache may begin loading portions of a requested data object from various data sources. Instead of waiting for the entire object to load to change the object state to “valid,” the cache may incrementally update the state through various levels of validity based on the user role of the request. When a portion of the data object used by a low-level user role is received, the object state can be upgraded to be valid for that user role while data for higher-level user roles continues to load. The portion of the data object can then be sent to the low-level user roles without waiting for the rest of the data object to load.

Abstract: A messaging service may be distributed in a cluster of nodes such that each node includes an instance of the messaging service. To ensure that messages are not lost in the messaging service through a load balancer, addresses for each of the nodes may be accessed, and messages may be retrieved from individual instances of the messaging service by addressing the nodes directly and bypassing the load balancer. To retrieve messages, a client may cycle through the node addresses and retrieve messages until each corresponding message queue is empty. Once a message queue is empty, the client may stop sending requests to the corresponding node until the message queues on the other nodes have been emptied. Various request patterns may be used to cycle through node addresses, including Round Robin patterns and patterns that correspond to traffic patterns seen by the load balancer.

Abstract: A server includes a data cache for storing data objects requested by mobile devices, desktop devices, and server devices, each of which may execute a different configuration of an application. When a cache miss occurs, the cache may begin loading portions of a requested data object from various data sources. Instead of waiting for the entire object to load to change the object state to “valid,” the cache may incrementally update the state through various levels of validity based on the calling application configurations. When a portion of the data object used by a mobile configuration is received, the object state can be upgraded to be valid for mobile devices while data for desktop and other devices continues to load, etc. The mobile portion of the data object can then be sent to the mobile devices without waiting for the rest of the data object to load.

Abstract: Techniques for asynchronous handling of service requests are disclosed. A service receives a request from a requesting entity. The request includes a function identifier and function input. Responsive to receiving the message, the service selects a first event handler to process the request. The service translates, via the first event handler, the function identifier to a native function call. The service initiates execution of the native function call using the function input, and receives output corresponding to the execution of the native function call. Responsive to receiving the output, the service selects a second event handler to process the output. The service generates, at least in part by the second event handler, a response based on the output. The service transmits the response to the requesting entity.

Abstract: A server includes a data cache for storing data objects requested by mobile devices, desktop devices, and server devices, each of which may execute a different configuration of an application. When a cache miss occurs, the cache may begin loading portions of a requested data object from various data sources. The cache itself may be divided into multiple partitions, and each of the partitions may be assigned to a specific attribute, such as an application configuration. Portions of the data object may be loaded into corresponding cache partitions based on the attributes of each. Although part of a single cache, each of the partitions may be independently assigned different cache replacement policies. Performance metrics for each of the partitions may be monitored and used to update the cache replacement policy for each partition at runtime without interrupting response traffic.

Abstract: A server includes a data cache for storing data objects requested by mobile devices, desktop devices, and server devices, each of which may execute a different configuration of an application. When a cache miss occurs, the cache may begin loading portions of a requested data object from various data sources. Instead of waiting for the entire object to load to change the object state to “valid,” the cache may incrementally update the state through various levels of validity based on the calling application configurations. When a portion of the data object used by a mobile configuration is received, the object state can be upgraded to be valid for mobile devices while data for desktop and other devices continues to load, etc. The mobile portion of the data object can then be sent to the mobile devices without waiting for the rest of the data object to load.

Abstract: Techniques for configuring applications are disclosed. A system maps software development stages to respective stage-specific configurations in two or more sets of stage-specific configurations. The system selects a software development stage for configuring an instance of an application. Responsive to selection of the software development stage, the system configures the instance of the application based at least on: a stage-specific configuration, in a set of stage-specific configurations, corresponding to the software development stage; and another stage-specific configuration, in another set of stage-specific configurations, corresponding to the software development stage. The system executes the instance of the application based at least on the stage-specific configurations from the sets of stage-specific configurations.

Abstract: Techniques for asynchronous handling of service requests are disclosed. A service receives a request from a requesting entity. The request includes a function identifier and function input. Responsive to receiving the message, the service selects a first event handler to process the request. The service translates, via the first event handler, the function identifier to a native function call. The service initiates execution of the native function call using the function input, and receives output corresponding to the execution of the native function call. Responsive to receiving the output, the service selects a second event handler to process the output. The service generates, at least in part by the second event handler, a response based on the output. The service transmits the response to the requesting entity.

Abstract: Techniques for asynchronous handling of service requests are disclosed. A service receives a request from a requesting entity. The request includes a function identifier and function input. Responsive to receiving the message, the service selects a first event handler to process the request. The service translates, via the first event handler, the function identifier to a native function call. The service initiates execution of the native function call using the function input, and receives output corresponding to the execution of the native function call. Responsive to receiving the output, the service selects a second event handler to process the output. The service generates, at least in part by the second event handler, a response based on the output. The service transmits the response to the requesting entity.

Abstract: Techniques for asynchronous handling of service requests are disclosed. A service receives a request from a requesting entity. The request includes a function identifier and function input. Responsive to receiving the message, the service selects a first event handler to process the request. The service translates, via the first event handler, the function identifier to a native function call. The service initiates execution of the native function call using the function input, and receives output corresponding to the execution of the native function call. Responsive to receiving the output, the service selects a second event handler to process the output. The service generates, at least in part by the second event handler, a response based on the output. The service transmits the response to the requesting entity.