By default API requests are passed though toddles global edge network instead of going directly from the users browser to the API. This practice is known as proxying and the node in the edge network the requests is passed through is called a proxy. There are a few reasons why this beneficial.
Enabling access tokens to be stored securely. Storing an access token in a secure cookie is the safest approach but since the cookie is not accessible from with in the browser, requests need to be passed through our proxy to set the appropriate authentication headers.
Avoiding CORS issues. CORS or Cross Origin Resource Sharing happens when a single website fetches data from several different domains. In many ways CORS is a key part of the web, but it also introduces a lot of security headaches. For that reason browsers do not allow CORS requests without first checking that the server allows such requests. Because your application runs on the same node we proxy your API requests through this is no longer an issue.
APIs in toddle also trigger events which can be used to run workflows after an API request has completed.
If the request is successful, meaning that a response was returned and the HTTP status code was below 300, then the Success event will be triggered. If a response could not be returned, or if the status code was 300 or above then the Failed event will be triggered instead.
Debouncing API requests
Debouncing an API request is a way to make sure that a request is not made multiple times for a single input. The classical example of debouncing is implementing a type ahead search.
Imagine you have an API requests that returns search results from a server. This API request uses a search string from a variable that is updated as the user types into a search field. Lets assume the user types in the word "marts". Since the variable is updated on every keystroke, and the API is configured to re fetch then toddle will actually make 5 API requests for that input.
m
ma
mar
mart
marts
By using debounce we can delay the request by a number of milliseconds. If a new requests is made within this time then the timer is reset and we keep waiting. When the timer has finished without any new requests being made withing the set period, the latest request will then be executed.
If we e.g. set a debounce of 300ms (good default) then the debounce timer will make sure that only the fifth request of "marts" will be executed. At the same time 300ms is fast enough that it does not register as much of a delay for the user.
