Query languages are available that allow applications to submit query requests in hierarchical structures and receive data results in the same hierarchical structures. In some systems, a server is provided that receives the data query, identifies one or more data sources for the requested data, obtains the requested data from the data sources, and structures a response based on the structure of the request.
The discussion above is merely provided for general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that solve any or all disadvantages noted in the background.
A computer-implemented method includes a processor retrieving a configuration file, loading a data definition from the configuration file, receiving from a requestor a request for data at an endpoint exposed by the processor, using the loaded data definition to obtain the requested data from a data source, and returning the requested data to the requestor. The processor then determines that the configuration file has been modified and in response to the configuration file being modified, the processor retrieves the modified configuration file, loads a modified data definition from the modified configuration file, receives from a second requestor a second request for data at the endpoint exposed by the processor, uses the loaded modified data definition to obtain the requested data from the data source, and returns the requested data to the second requestor.
In accordance with a further embodiment, a server includes a network interface for connecting to a computer network and a processor configured to receive a query for data, use a configuration file to identify a data source on the computer network for resolving the query and return the data requested in the query. The processor also determines that the configuration file has been modified, retrieves a modified configuration file from the computer network, receives a second query for data, and uses the modified configuration file to identify a data source on the computer network for resolving the second query.
In accordance with a further embodiment, a method includes retrieving a configuration file, providing an endpoint to receive data queries and utilizing the configuration file to process the data queries. The configuration file is monitored to determine if it has been modified. When the configuration file is determined to have been modified to produce a new configuration file, the new configuration file is used to process data queries.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Data request servers, such as GraphQL servers, execute server code that has been specifically written to convert queries for data received from clients into requests designed to obtain the data from one or more data sources. Because each server is designed to work with a different set of data sources, prior systems utilized custom server code for each data request server. Such code is inefficient to write initially and time consuming to maintain since each server's code must be maintained separately.
In the embodiments described below, an improved architecture is provided in which universal server code is provide that can be used by a plurality of different data request servers, such as GraphQL servers, that each support different collections of data sources. The universal code is adapted on each server to work with a particular group of data sources through a configuration file assigned to the server. To allow for the universal code to be deployed separately from the configuration file, the configuration file is stored in a separate software package from the server code on a continuous integration/continuous deployment system.
When the universal code begins executing on the server, the code requests the configuration file designated for the server's data sources and uses the configuration file to set the allowable data types and the information used to resolve queries received from clients. Using the system, individualized data request servers are achieved while allowing a majority of the data request server source code to be universal to all the servers so as to be more easily written and maintained. In addition, deploying the configuration file separately from the data request server code allows the configuration file to be modified frequently and easily without having to wait for redeployment of the data request server code. Thus, the server for one group of data sources can be updated by updating its configuration file without impacting the operation of other data request servers operating in accordance with other configuration files. This improves the operation of all of the data request servers because it requires fewer interruptions of their operation to install new data request server code. In addition, all servers run the same version of the data request server code making it easier to identify which servers need to be updated when a bug is found in the server code.
In step 100 of
At step 102, a respective configuration file is deployed to a datastore 212 for each of the data request servers. In
In accordance with one embodiment, datastore 212 stores each configuration file as part of a key/value pair where the key is used to access the value and the value is the configuration file. In
At step 104, each data request server requests its respective configuration file from datastore 212. In accordance with one embodiment, the data request servers receive their respective key for their respective configuration file and the location of datastore 212 as part of the deployment of data request server code 200.
At step 106, a configuration file loader, such as loader 250 in data request server 204, loads the information in the configuration file into executable code 210.
Resolvers section 302 provides information for resolving data queries where resolving a data query involves matching the data query name to a field name in resolvers section 302, such as field name 312, and using the parameters stored for that field name to request the requested data from a data source, receive the returned data from the data source and structure the returned data to match the hierarchical structure of the query before returning the structured data to the requestor. In particular, a method 309 is used in combination with the path designated for endpoint 310 to identify how and where requests for data are to be sent for this data query.
Data definition section 304 includes definitions for various data types including a query data type that defines allowable structures for queries, such as query definition 316. Data definition section 304 includes additional type definitions for other objects such as definition 318 for a car object, definition 320 for an entity object, definition 322 for a full name object, and definition 324 for a full address object.
Loading step 106 of
After the configuration file has been loaded into executable code 210 at step 106, a configuration monitor 252 in executable code 210 is started at step 108. The operation of the configuration monitor is discussed further below.
At step 110, executable code 210 begins to process queries from clients.
In step 400 of
At step 402 of
If the structure of the query matches the structure of data types in the configuration file, executable code 210 determines if cached queries are permitted at step 405. Cached queries are queries that have their results stored on data request server 204 and do not require the data requested in the query to be retrieved from data sources, such as data sources 260 and 262 of
If cached queries are permitted, the top-level field name is compared to the field name in resolvers section 302 of the configuration file (see
If the query is a cached query at step 408, executable code 210 then uses a refresh field 362 set for the top-level field name to determine if a cache refresh is needed. Refresh field 362 sets a time period for reacquiring the data from data sources 260 and 262. Executable code 210 compares the refresh field 362 to the period of time that has expired since the cached data was last received to determine if a cache refresh is needed. If a cache refresh is not needed, cached results from a previous query are returned for the query at step 412.
If cached queries are not permitted at step 405, or if a cache refresh is needed at step 410 or if this is not a cached query at step 408, executable code 210 identifies data sources for resolving the query at step 414 using the data source name field for the associated resolver and the properties of the associated data source from data sources section 300 of the configuration file. These properties include one or more endpoints, such as a RESTful API, for retrieving data, such as endpoint 310 of
At step 416, executable code 210 uses the data sources to resolve the query by sending requests to the data source endpoints. In accordance with one embodiment, these requests are constructed using a request mapping template, such as a request mapping template 364 provided by the configuration file. The requests are then passed to the endpoints of the data sources, such as data sources 260 and 262, which retrieve the data and return the data to executable code 210. At step 418, executable code 210 structures the returned data to match the structure provided in the query. Thus, the returned data is parsed to select only the fields requested in the query and to place the parsed data into a hierarchical structure that matches the hierarchical structure of the query.
At step 420, executable code 210 determines if this is a cacheable query. In order for a query to be cacheable, executable code 210 must permit query caching and this query must be designated as cacheable in the cache field of the configuration field. If this is a cacheable query, the structured data is stored at step 422 on data request server 204 so that it can be returned with the next request for this query. If this is not a cacheable query at step 420 or after step 422, the structure data is returned to client 254 at step 424.
In step 108 of
In step 700 of
At step 714, executable code 210 finishes processing any pending queries using the data sources, resolvers and data types of the old configuration file. Thus, steps 700-714 are performed while executable code 210 continues to receive queries from clients, such as client 254, and while executable code 210 continues to resolve those queries to provide data to the requestors. Thus, the configuration file is monitored without impacting query processing. At step 716, executable code 210 switches to the data sources, type data and resolvers of the new configuration file, such as those shown in
Computing device 10 further includes an optional hard disc drive 24, an optional external memory device 28, and an optional optical disc drive 30. External memory device 28 can include an external disc drive or solid-state memory that may be attached to computing device 10 through an interface such as Universal Serial Bus interface 34, which is connected to system bus 16. Optical disc drive 30 can illustratively be utilized for reading data from (or writing data to) optical media, such as a CD-ROM disc 32. Hard disc drive 24 and optical disc drive 30 are connected to the system bus 16 by a hard disc drive interface 32 and an optical disc drive interface 36, respectively. The drives and external memory devices and their associated computer-readable media provide nonvolatile storage media for the computing device 10 on which computer-executable instructions and computer-readable data structures may be stored. Other types of media that are readable by a computer may also be used in the exemplary operation environment.
A number of program modules may be stored in the drives and RAM 20, including an operating system 38, one or more application programs 40, other program modules 42 and program data 44. In particular, application programs 40 can include programs for implementing any one of the applications discussed above. Program data 44 may include any data used by the systems and methods discussed above.
Processing unit 12, also referred to as a processor, executes programs in system memory 14 and solid-state memory 25 to perform the methods described above.
Input devices including a keyboard 63 and a mouse 65 are optionally connected to system bus 16 through an Input/Output interface 46 that is coupled to system bus 16. Monitor or display 48 is connected to the system bus 16 through a video adapter 50 and provides graphical images to users. Other peripheral output devices (e.g., speakers or printers) could also be included but have not been illustrated. In accordance with some embodiments, monitor 48 comprises a touch screen that both displays input and provides locations on the screen where the user is contacting the screen.
The computing device 10 may operate in a network environment utilizing connections to one or more remote computers, such as a remote computer 52. The remote computer 52 may be a server, a router, a peer device, or other common network node. Remote computer 52 may include many or all of the features and elements described in relation to computing device 10, although only a memory storage device 54 has been illustrated in
The computing device 10 is connected to the LAN 56 through a network interface 60. The computing device 10 is also connected to WAN 58 and includes a modem 62 for establishing communications over the WAN 58. The modem 62, which may be internal or external, is connected to the system bus 16 via the I/O interface 46.
In a networked environment, program modules depicted relative to the computing device 10, or portions thereof, may be stored in the remote memory storage device 54. For example, application programs may be stored utilizing memory storage device 54. In addition, data associated with an application program may illustratively be stored within memory storage device 54. It will be appreciated that the network connections shown in
Although elements have been shown or described as separate embodiments above, portions of each embodiment may be combined with all or part of other embodiments described above.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms for implementing the claims.