| [che-dev] Using dedicated backend services for single artifact processing |
|
Hello colleagues, In the past, in our design of Web development environment we assumed that single artifact processing like tokenizing, parsing and validation can be executed either at the frontend side, i.e. by _javascript_ running in the browser or at backend
side by "native" compiler for the artifact's language. Which strategy to select depends on several parameters: ·
Availability and performance of _javascript_ implementation of processor ·
Availability of rest api for the backend "native" processor ·
How much the "global" metadata, like, Data dictionaries, symbol tables, etc., is involved and if it is possible to transfer this data to the client side We, even, proposed option to allow to switch strategy via user preferences change. Now we are adopting our tools to work with Che and I have doubts whether server side processing is relevant in the Che environment from the scalability point of view. I have to take into account that processed artifact can be in the uncommitted
(unsaved!) state, i.e. the it has to be posted to server. Processing can be triggered very frequently – each few keystrokes. In most cases Web worker provides the good alternative if required tools are available in _javascript_ implementation. Another question is whether dual client side / server side implementation is useful and what is the "selector" parameter for client side /server side switch? Maybe, the client side strategy shell be preferred whenever performance allows
it? BR Pavel Sosin Development expert SAP Labs Israel |