Those are all valid points, but for many applications, I would say are not 
actual problems. If we're discussing the context of archetype editing tools, I 
would say REST with JSON is fine. HTTP traffic is usually compressed and 
browsers have heavily optimized their JSON parsing, making it much more 
efficient than it would seem. Very good tools are available in many languages 
to parse and validate JSON encoded data against a given model and given types. 
Many people know how to use it so they can start developing right away, and 
debugging is easy due to the fact that is human readable.

For microservices with enough traffic, or for devices with limited processing 
power or limited bandwidth, a binary encoding makes sense. However, GRPC would 
not be my first choice for OpenEHR - you would have to find a way to map all 
the inheritance in the OpenEHR model to protocol buffers.

Regards,

Pieter Bos
Nedap Healthcare

On 23/02/2018, 15:30, "openEHR-technical on behalf of Bert Verhees" 
<openehr-technical-boun...@lists.openehr.org on behalf of bert.verh...@rosa.nl> 
wrote:

    On 23-02-18 14:37, Pieter Bos wrote:
    > A small amount of JavaScript working with Json from a backend works very 
well for us.
    >
    > You don’t always need explicit class definitions. it does require a 
different programming style than a more object oriented language.
    
    Thomas has a point,
    
    JSON/REST is not efficient,
    - text takes a lot of bandwidth, an Integer f.e. 3,000,000,000 is only 4 
    bytes in binary but 10 bytes in text,
    - the translating from datatypes to text and back again takes a lot of 
    CPU cycles,
    - semantical is REST not fitted for many function-calls, HTTP-errors are 
    misused for functional error-codes
    - the http-protocol with all the headers is not efficient and has 
    unnecessary overload
    - REST is not error or type safe, you can send anything to a 
    restservice, it processes the whole request-headers, and then looks if 
    the parameters are sufficient in number and in type
    
    Check this, it is a good explanation (if you have time for that, it 
    hardly handles about Go):
    https://www.youtube.com/watch?v=J-NTfvYL_OE
    
    The question is only of a license-restricted product as ICE is the 
    answer to this problem
    For microservices GRPC works very well, it has a performance of 
    sometimes 100* the performance of rest, it supports also bi-directional 
    streaming, and it is safe, because the interface-code is generated.
    
    There are some promising projects for GRPC in browsers which support 
    HTTP/2 (this are all browsers in their latest versions)
    I did not test it, but I will, in a few weeks in a project I am working on.
    https://github.com/improbable-eng/grpc-web
    
    Bert
    
    >
    > Regards,
    >
    > Pieter Bos
    >
    > Op 23 feb. 2018 om 14:21 heeft Bert Verhees 
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>> het volgende geschreven:
    >
    > The problem with Ice is that it is not open source licensed when used in 
a non GPLv2 product.
    > Another problem is that they do not publish the price of a commercial 
license.
    >
    > That are restrictions that cause many programmers not to use it.
    >
    > https://zeroc.com/licensing
    >
    >
    > On 23-02-18 13:59, Thomas Beale wrote:
    >
    > Belated thought on this topic: a much better way to connect a JavaScript 
front end with a Java back end, or any similar combination, would be with a 
binary RPC protocol like ICE<https://zeroc.com/products/ice>, that comes with 
tools to make it all work.
    >
    > - thomas
    >
    > On 05/02/2018 22:04, Thomas Beale wrote:
    >
    >
    > yes, JS = javascript, TypeScript etc. No, nothing to do with Java of 
course. Just that JS/TS are the languages that seem to be popular for web app 
development these days, and Java for the back-end. The connection between front 
and back-end that people seem to prefer these days is REST APIs, which both 
Java and JS can do easily enough.
    >
    > - thomas
    >
    > On 03/02/2018 07:56, Peter Gummer wrote:
    > On 1 Feb 2018, at 05:13, Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:
    >
    > ... But the main interest is that we will be able to build new tools such 
as a Java/JS replacement for the ADL Workbench, and of course things like a 
high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
workflow implementations and many other components.
    >
    > Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how 
Archie (written in Java, disappointingly) would enable JavaScript 
implementations. JavaScript has nothing in common with Java (apart from the 
name).
    >
    > Peter
    >
    >
    >
    >
    > _______________________________________________
    > openEHR-technical mailing list
    > 
openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>
    > 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
    >
    >
    > _______________________________________________
    > openEHR-technical mailing list
    > 
openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>
    > 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
    > _______________________________________________
    > openEHR-technical mailing list
    > openEHR-technical@lists.openehr.org
    > 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
    
    
    
    _______________________________________________
    openEHR-technical mailing list
    openEHR-technical@lists.openehr.org
    
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Reply via email to