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