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

Reply via email to