A Golem requestor is a specific piece of code running on an Internet-connected device.
The characteristic that describes the requestor agent is the need to use hardware resources that are available in the Golem network, shared by its providers.
The typical use case for the requestor is as follows:
Define the need
Define the IT resources it needs. Those needs (for example CPU and memory requirements) are then published in the form of a Demand in Golem's decentralized market.
Buy the resources
If the decentralized market contains offers previously announced by the providers that match the requirements of the particular requestor's demand, the resources thereby offered are purchased to be used by the requestor.
Use the resources
The actual usage depends on the nature of the resources. For now, the most common scenario is performing computations, but Golem is not limited to this use case.
Pay for the resources usage
The last step is to pay for the usage of the resources (unless the provider is offering them for free :). There are many possible payment scenarios, but Ethereum-based payment is the default one.
As requestors are based on each specific business need there is no single requestor agent that fits all the use cases.
There are many possible scenarios defining the actual form and shape of a product that is based on Golem.
The simplest scenario is when the requestor binary is running on a device that the end-user has physical access to, e.g.:
a mobile device (phone/tablet)
a desktop box
In this scenario, your product front-end layer and the requestor can be integrated into one binary package.
In this scenario, it doesn't matter what the end user's local device is, as long as it can run a web browser.
Here, your application code is running inside a web server and the front-end layer is accessed through a browser.
The basic requestor development tutorial is here:
The main or most typical benefit for the requestor is to have instant access to a very large pool of hardware. Instead of using local hardware, the requestor is able to use the IT resources available on the decentralized market.
For instance, you could think of training a large ML model in seconds instead of hours.
For the basic computations scenario the details of the resource usage are as follows:
Specify what docker image to use:
existing one, for example from the docker hub
create a custom docker image
For each of the providers whose resources a requestor wishes to utilize, (there is no set limit on the number) define the files containing the input data for the computations.
For each of the docker containers created on the provider's hardware:
transfer the input files to a volume available within the docker container.
execute the "run task" command (actual command string is defined in the requestor agent code)
transfer the output files from the docker container's volume to the requestor.