I don't like tools that do many things at once. So GRPC seems to me overhead, it's like kubernetes.
GRPC is the tool that combines actually two things: extended Protobuf (Service support) and HTTP2.
I read a lot of articles saying that using GRPC is awesome for performance. And there are two reasons
protobuf is used, it's smaller than json or xml.
GRPC uses HTTP2 for transport protocol
Here is main part: protobuf and HTTP2 are independent projects, tools, whatever. With that understanding i can say that GRPC is nothing but combining several different tools, like kubernetes combines docker and orchestration tools.
So my questions is: What's actual advantages of using GRPC vs HTTP2 with any payload (CSV, XML, JSON, etc).
Let's skip part about serialization because as i mentioned protobuf is independent library from grpc
As you pointed out, gRPC and Protobuf are often conflated. While, in the vast majority of cases, gRPC will be using protobuf as an IDL and HTTP/2 as the transport, this is not always the case.
So then, what value does gRPC provide on its own? For starters, it provides battle-tested implementations of each of those transports, along with first class support for the protobuf IDL. Integrating these things is not trivial. gRPC packages all of them into one nice pluggable box so you don't have to do the legwork.
It also provides you with functionality that HTTP/2 on its own does not. Pluggable authorization/authentication, distributed tracing instrumentation, debugging utilities, look-aside load balancing (including upcoming support for the xDS protocol), and more are provided.
Related
In general, supposing your server, written in Javascript in the node.js environment, is assembling a response to an end user from services provided by other servers, is there any reasonable alternative to having them all talk JSON?
RPC calls usually use XDR, which is binary, or JSON, which is ascii. There are handy libraries to take care of all the boring sockets stuff for you for these cases.
Node.js tools to use RPC are available for RPC in JSON, but is there any easy way to access RPC calls in binary formats such as XDR, ASN.1 PER, or Avro Apache from node.js. Or to do something similar?
I am not asking what is the best way, or what can be done, because anything can be done with enough hard work, but rather what ways have standards to avoid reinventing the wheel, and libraries to do as much of the work as possible.
avsc implements Avro's RPC specification, you can use it to expose "type-safe" services over any transport (e.g. HTTP, TCP, WebSockets). The quickstart guide goes through a simple example that should help you get started. (Disclaimer: I wrote it.)
Why are there two MQTT agents:
https://github.com/telefonicaid/iotagent-mqtt
https://github.com/telefonicaid/fiware-IoTAgent-Cplusplus
Isn't this duplicated work?
Which one should be used?
BR,
Drasko
https://github.com/telefonicaid/iotagent-mqtt is a full-working agent that bridges context information using MQTT into NGSI, developed in Node JS. This software is ready to go out of the box, but only supports MQTT (there are other protocols supported in other IoTAgents).
https://github.com/telefonicaid/fiware-IoTAgent-Cplusplus is a C++ development framework. This means that you can use it to fit to your specific protocol needs (could be MQTT, but could be other) and using C++ as programming language. This software requires that you implement several functionalities and will not do much out of the box, but offers maximun flexibility.
We're designing a communications system for supporting asynchronous near-realtime server pushing of events/messages to thousands of clients acrros JVM, .Net and mobile platforms. We have a mixed model (both publish-subscribe and request-response) and binary data.
We are using Netty and Google Protocol Buffers and we need to encapsulate all this in http(s).
We were looking into the Bayeux Protocol and its Netty implementation and were inclined to use a modified version of it with protobuf codecs instead of JSONs' or roll our own starting from the WebSockets example (client and server). For performance concerns we would stay out of Base64 encodings an the like.
Are there any implementations that we are missing? How feasible would it be to do a protobuf-based Bayeux protocol? Any pointers are greatly appreciated.
How about STOMP over Web Sockets?
This is related to an earlier question I had asked about what sort of middleware one can use for developing a client/server app.
Among the options suggested, I was intrigued by zeroMQ and its capabilities.
Since morning, I have been researching on using zeroMQ for my application. However, since my client is a Adobe AIR/FLEX, I see a steep curve in using zeroMQ since there are no bindings available for actionscript.
Google search shows a popular client called STOMP that can be used for messaging in flex based applications but there doesn't seem to be any STOMP adapter for zeroMQ either.
This leaves me with other alternatives such as RabbitMQ or ActiveMQ (since they both seem to have STOMP adapters) as possible middleware choices.
How hard/easy it is to develop to stomp adapter for zeroMQ? I hardly found any documentation on writing an adapter. Or is it worth writing an adapter for zeroMQ than focus on, say, using RabbitMQ that supports STOMP.
Finally, what are other popular alternatives to STOMP for Flex on the client side and leverage zeroMQ on the middleware part.
Thanks
Dece
STOMP is probably going to be the only option from FLEX since it's by far the simplest MOM protocol available. Furthermore, since it's such a simple protocol, I'm surprised someone has not yet implemented a bridge from STOMP to zeromq.
I am currently working on a design for a collection of subsystems, and I would like to be able to offer the API's exposed by a given subsystem for use by other subsystems.
In the past, I have used SWIG to expose C api's to a variety of other languages. This has worked well for me, but ultimately the API is defined in C. So basically one side of the API is language agnostic, and the other isn't.
What I would really like is to have something similar to SWIG that could generate the interface between 2 arbitrary languages based on some description of the API.
I don't want to use web services.
For example, I would like to call a 'function' from java, and implement the 'function' in Python. I'd like to be able to generate the language interop using a code generator.
Is there anything that exists which can do this today? At least for simple 'function' calls - ignoring the more complex cases like callbacks and situations where you need to maintain references outside of the 'function' call itself.
I found this after following gooli's link to Protocol Buffers .
This looks so compelling I'm going to propose it as an answer to my own question.
http://incubator.apache.org/thrift/
Thrift is a software framework for scalable cross-language services development. It combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml.
From the whitepaper:
...we were presented with the challenge of building a transparent,
high-performance bridge across many
programming languages. We found that
most available solutions were either
too limited, did not offer sufficient
datatype freedom, or suffered from
subpar performance
Also from the whitepaper:
A. Similar Systems The following are software systems similar to Thrift.
Each is (very!) briefly described:
SOAP. XML-based. Designed for web services via HTTP, excessive XML
parsing overhead.
CORBA. Relatively comprehensive, debatably overdesigned and
heavyweight. Comparably cumbersome
software installation.
COM. Embraced mainly in Windows client softare. Not an entirely open
solution.
Pillar. Lightweight and high-performance, but missing
versioning and abstraction.
Protocol Buffers. Closed-source, owned by Google. Described in Sawzall
paper.
The last part about Protocol Buffer's is out-of-date - its been open sourced
COM (and to a lesser extent Firefox's XPCOM) might be what you are looking for. In COM, you define the API using a language called IDL which can then be compiled into different languages. When using the same language the calls usually degenerate into efficient function calls.
However, COM is a very complex and dying piece of technology that I would never use for a new project.