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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
