Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] Using dedicated backend services for single artifact processing

I hope this is not a repost.  Che-dev gave me a bounce on the first send.

Pavel:

Hello.  Thanks for taking your time to provide some thoughts.

In the current and past versions of Che we have had a mixture of client side and server side abstract tree processing.  We have found that the performance was substandard.

In 4.x we have been working on a cleaner set of abstractions that are only server side.  We will make it possible for language analysis to be portably injected into a workspace machine and that process can operate against the set of files there.  In our latest tests the performance is significantly better than our current web worker and server side approach.

As a result we do not have plans to support a switcher that would let the processing take place in different locations.  It would be incumbent upon client-side developers to ignore the workspace dev machine services in favor of their own.

We have auto save of the files and the clients that work on files can do batch updates of changes to minimize the impact of having to trigger too many requests to the server side.

Also by doing any sort of processing on the client side it is easy to create an inconsistent view between two parties in the same workspace if the state machine is assessing a different syntax state at any given point in time.

Tyler Jewell | CEO | tyler@​codenvy.​com | 9​78​.8​84​.53​55


On Mon, Jun 22, 2015 at 12:33 AM, Sosin, Pavel <pavel.sosin@xxxxxxx> wrote:

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

 

 

 


_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev



Back to the top