Nowadays we see the rapid growth of solutions number for spatial data processing in the Web (i.e. geoprocessing). One of the main trends of Web geotechnologies evolution is the transition from Web map applications to the Web GIS applications, which are supplement the maps delivery with the analytic tools providing to the end user through Web interface. The only general open standard describes implementation rules for Web geoprocessing services. This is the Open Geospatial Consortium Web Processing Service standard (OGC WPS), which is server-oriented standard [Schut at al., 2007]. Moreover, the vast majority of currently used solutions (both open source and proprietary) are server-oriented, i.e. assume the using for computations the server resources only. However, some researchers underline that it is possible way to transmit the executable code to the client for client-side computations and geoprocessing [Keens at al., 2007]. Also, some general Web architecture concepts assumes the effectiveness of client-side computations, e.g. Fog Computing concept [Hong at al., 2013]. Our practical experience also shows that in some cases it is useful to have ability of client-side geoprocessing, which is not opposite but complement technology to the server-side processing technologies. In addition, we believe that it is more useful to have the ability to run the same processing tool by choice on server or client side. We name such double-sided services as Hybrid Geoprocessing Web Services (HGWS) [Panidi, 2014]. We study and discuss the approaches to fill the gap of client-side geoprocessing general schema. For this purpose, we implemented previously the getProcess request as addition to the WPS protocol [Panidi, 2014]. Additionally at the previous steps of our study, we proposed a possible structure of getProcess request and draft XML schema for its response, which describes the list of executable resources and their dependencies [Kazakov at al., 2015]. Currently we working on detailed methodology of processing tools implementation, and prototypes testing in use cases of geospatial data processing for small-scale research projects. We use the Python programming language as primary development tool, because of its applicability to build both server- and client-side processing tools using single core program code. We use Python also for implementation of needed infrastructure components, such as HGWS server that supports the getProcess request/response performing, and client-side runtime environment that provides executable code orchestration on the client. Achieved results need to be discussed widely and carefully. However, main conclusion of our current work is that client-side geoprocessing schema in general could be relatively simple and compatible backward with current standards. The HGWS concept is applicable when implementing client-side geoprocessing Web services in small-scale projects and could be the entering point for study of distributed geoprocessing systems implementation.