Runtime API Generation for Dynamic Language RPC Services
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Pre-generated application programming interfaces (APIs) for client-server applications, especially in dynamically-typed languages like JavaScript and Python, face challenges in supporting data type information and are often too large, leading to inefficiencies and increased complexity, particularly in browser-based applications.
Innovation Solution
A method for dynamically generating APIs at runtime using an interface definition language file, which allows for the creation of interface metadata and execution of remote procedure calls based on this metadata, enabling comprehensive support for client applications without static types and optimizing metadata retrieval through caching and on-demand generation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If pre-generated APIs include data type information in non-native format to support dynamically-typed languages, then comprehensive functionality is achieved, but the size of the API becomes unacceptably large
Solution Approach 1:
The patent segments the API functionality by separating the interface definition language file (containing service metadata) from the client application code. Instead of embedding complete type information in the API, the system divides functionality into: (1) a compact runtime library that handles metadata processing, and (2) an external IDL file that contains the service interface definitions. This segmentation reduces the in-memory API footprint while maintaining comprehensive support for dynamically-typed languages.
Solution Approach 2:
The patent moves the type information from the traditional dimension (embedded in the API code) to a different dimension (external IDL file stored on disk or network). The runtime system dynamically loads and processes this external metadata, transforming it into executable interface bindings. This dimensional shift allows comprehensive type information to be available without bloating the in-memory API representation.
2Adaptability or versatility
If a middle-tier is introduced to provide a language bridge for dynamically-typed languages, then access to the service is enabled, but the creation complexity and execution time increase
Solution Approach 1:
The patent implements self-service by enabling the dynamically-typed language runtime to directly process and interpret the interface definition language file without requiring a middle-tier translation layer. The runtime library includes built-in capabilities to parse the IDL file, extract service metadata, and generate executable interface bindings natively. This eliminates the need for an intermediate language bridge, reducing system architecture complexity while maintaining language compatibility.
3Reliability
If pre-generated APIs are used for compiled languages, then type safety and compiler access are achieved, but the APIs cannot be updated to reflect current service versions
Solution Approach 1:
The patent introduces dynamics by making the interface bindings generated from the IDL file version-agnostic. The runtime system dynamically processes the IDL file at execution time, allowing the generated bindings to automatically reflect the current service version defined in the IDL metadata. This dynamic generation approach maintains type safety through compile-time checking of the IDL file while enabling automatic adaptation to service version changes without requiring manual API regeneration.
Data Source
AI summary
An application specific interface (API) for a service that is accessible by remote procedure calls is generated at run-time from an interface language definitions file. In operation, a client application requests a connection to a server and then a runtime API generator connects to the server and downloads an interface definition language (IDL) file that defines services provided by the server. The runtime API generator parses the IDL file and generates the corresponding service API. Subsequently, upon receiving a client application request, the API generator generates a set of instructions that, when executed, emit one or more remote procedure calls that cause the server to implement the client application request. Because the API is generated at run-time, the runtime API generator enables client applications that are implemented in dynamically typed languages to access the service by providing access to the data type metadata that cannot be expressed in such languages.