Could anybody explain advantage of using json-rpc over json-api and vice-versa? First and second format are JSON-based, but where I should use one, and where is another?
Note: I may come across a little biased. I am the author of the Json-RPC.net server library.
Json-RPC is a remote procedure call specification. There are multiple libraries you can use to communicate using that protocol. It is not REST based, and is transport agnostic. You can run it over HTTP as is very common, you can also use it over a socket, or any other transport you find appropriate. So it is quite flexible in that regard. You can also do server to client along with client to server requests with it by hosting the RPC server on either the client or the server.
Json-API is a specification for building REST APIs. There are multiple libraries you can use to get started with it. In contrast to Json-Rpc it requires you to host it on an HTTP server. You cannot invoke functions on the client with it. You cannot run it over a non-http transport protocol. Being REST based, it excels at providing information about Resources. If you want an API that is based around the idea of Create, Read, Update, Delete on some collections of resources, then this may be a good choice.
Json-API is going to be better if your API is resource-based, and you want your API to be browsable by a human without setting up documentation for it. Though that human would likely need to be in the software engineering field to make any sense of it.
Json-RPC is going to be better if your API is function based, or you want the flexibility it provides. Json-RPC can still be used to manipulate Resources by creating Create, Read, Update, and Delete functions for your resources, but you don't get the browsability with it not being REST based. It can still be explored (not browsed) by a human by generating documentation based off of the functions you expose.
A popular example of something that uses Json-Rpc is BitCoin.
There are a lot of popular REST-based API's and Json-API is a spec with a bunch of tools to help you do REST right.
--
Note: Neither of those (Json-RPC, or Json-API) are good when you consider for developer time, performance, or efficiently using network resources.
If you care about performance, efficiency, or developer time then take a look at Google's gRPC which is fantastic in those regards, and can still reduce developer time more than using a REST API as client and server code can be generated from a protocol definition file.
Related
I'm looking for a way to implement basic Publish / Subscribe between applications written in different languages, to exchange events with JSON payloads.
WebSocket seems like the obvious choice for the transport, but you need an (arguably small) layer on top to implement some of the plumbing:
aggreeing on messages representing the pubsub domain "subscribe to a topic", "publish a message"
aggreeing on messages for the infra ("heartbeat", "authentication")
I was expecting to find an obvious standard for this, but there does not seem to be any.
WAMP is often refered to, but in my (short) experience, the implementations of server / clients libraries are not great
STOMP is often refered to, but in my (even shorter) experience, it's even worse
Phoenix Channels are nice, but they're restricted to Phoenix/Elixir world, and not standard (so the messages can be changed at any phoenix version without notice.)
So, is everyone using MQTT/WS (which require another broker components, rather than simple servers ?) Or gRPC ?
Is everyone just re-implementing it from scratch ? (It's one of those things that seems easy enough to do oneselves, but I guess you just end up with an half-baked, poorly-specified, broken version of the thing I'm looking for...)
Or is there something fundamentally broken with the idea of serving streams of data from a server over WS ?
There are two primary classes of WebSocket libraries; those that implement the protocol and leave the rest to the developer, and those that build on top of the protocol with various additional features commonly required by realtime messaging applications, such as restoring lost connections, pub/sub, and channels, authentication, authorization, etc.
The latter variety often requires that their own libraries be used on the client-side, rather than just using the raw WebSocket API provided by the browser. As such, it becomes crucial to make sure you’re happy with how they work and what they’re offering. You may find yourself locked into your chosen solution’s way of doing things once it has been integrated into your architecture, and any issues with reliability, performance, and extensibility may come back to bite you.
ws, faye-websockets, socket.io, μWebSockets and SocketCluster are some good open-source options.
The number of concurrent connections a server can handle is rarely the bottleneck when it comes to server load. Most decent WebSocket servers can support thousands of concurrent connections, but what’s the workload required to process and respond to messages once the WebSocket server process has handled receipt of the actual data?
Typically there will be all kinds of potential concerns, such as reading and writing to and from a database, integration with a game server, allocation and management of resources for each client, and so forth.
As soon as one machine is unable to cope with the workload, you’ll need to start adding additional servers, which means now you’ll need to start thinking about load-balancing, synchronization of messages among clients connected to different servers, generalized access to client state irrespective of connection lifespan or the specific server that the client is connected to – the list goes on and on.
There’s a lot involved when implementing support for the WebSocket protocol, not just in terms of client and server implementation details, but also with respect to support for other transports to ensure robust support for different client environments, as well as broader concerns, such as authentication and authorization, guaranteed message delivery, reliable message ordering, historical message retention, and so forth. A data stream network such as Ably Realtime would be a good option to use in such cases if you'd rather avoid re-inventing the wheel.
There's a nice piece on WebSockets, Pub/Sub, and all issues related to scaling that I'd recommend reading.
Full disclosure: I'm a Developer Advocate for Ably but I hope this genuinely answers your question.
I'm trying to build my first Sproutcore App and I struggle to connect it to a MySQL-Database or any datasource other than fixture. I can't seem to find ANY tutorial except this one from 2009 which is marked as deprecated: http://wiki.sproutcore.com/w/page/12413058/Todos%2007-Hooking%20Up%20to%20the%20Backend .
Do people usually not connect SC-Apps to a Database? If they do so, how do they find out how to? Or does the above mentioned tutorial still work? A lot of gem-commands in the introduction seems to already differ from the official Sproutcore getting-started-guide.
SproutCore apps, as client-side "in-browser" apps, cannot connect directly to a MySQL or any other non-browser database. The application itself runs only within the user's browser (it's just HTML, CSS & JavaScript once built and deployed) and typically accesses any external data via XHR requests to an API or APIs. Therefore, you will need to create a service wrapper around your MySQL database in order for your client-side app to be able to load and update data.
There are two things worth mentioning. The first is that since the SproutCore app contains all of your user interface and a great deal of business logic, your API can be quite simple and should only return raw data (such as JSON). The second is that, I should mention that the client-server design, while more tedious to implement, is absolutely necessary in practice, because you can never trust the client side code, which is in the hands of a possibly nefarious user. Therefore, your API should also act as the final gatekeeper to validate all requests from the client.
This tutorial I found helped me a lot. Its very brief and demonstrates how to implement a very simple login-app, how to send post-requests (triggered by the login-button-action) to the backend-server and how to asynchronously process the response inside the Sproutcore-App:
http://hawkins.io/2011/04/sproutcore_login_tutorial/
What is the difference between a simple Async servlet and the Comet / Bayeux protocol?
I am trying to implement a "Server Push" (or "Reverse Ajax") kind of webpage that will receive updates from the server as and when events occur on the server. So even without the client explicitly sending a request, I need the server to be able to send responses to the specific client browser.
I understand that Comet is the umbrella term for these kind of technologies; with 'Bayeux' being the protocol. But when I looked through the servlet spec, even the 'Async servlet' seems to accomplish the same thing. I mean I can define a simple servlet with the
<async-supported>
attribute set to true in the web.xml; and that servlet will be able to asynchronously send responses to the client. I can then have a jQuery or ExtJS based ajax client that just keeps doing a
long_polling()
call into the servlet. Something like what is described in the link below
http://www.ibm.com/developerworks/web/library/wa-reverseajax1/index.html#long
So my question is this:
What is the difference between a simple Async servlet and the Comet / Bayeux protocol?
Thanks
It is true that "Comet" is the term for these technologies, but the Bayeux protocol is used only by few implementations. A Comet technique can use any protocol it wants; Bayeux is one of them.
Having said that, there are two main differences between an async servlet solution and a Comet+Bayeux solution.
The first difference is that the Comet+Bayeux solution is independent of the protocol that transports Bayeux.
In the CometD project, there are pluggable transports for both clients and servers that can carry Bayeux.
You can carry it using HTTP, with Bayeux being the content of a POST request, but you can also carry it using WebSocket, with Bayeux being the payload of the WebSocket message.
If you use async servlets, you cannot leverage WebSocket, which is way more efficient than HTTP.
The second difference is that async servlets only carry HTTP, and you need more than that to handle remote Comet clients.
For example, you may want to identify uniquely the clients, so that 2 tabs for the same page result in 2 different clients. To do this, you need add a "property" to the async servlet request, let's call it sessionId.
Next, you want to be able to authenticate a client; only authenticated clients can get a sessionId. But to differentiate between first requests to authenticate and others subsequent requests already authenticated, you need another property, say messageType.
Next, you want to be able to notify quickly disconnections due to network loss or other connectivity problems; so you need to come up with a heart-beat solution so that if the heart beats you know the connection is alive, if it does not beat you know it's dead, and perform rescue actions.
Next you need disconnect features. And so on.
Quickly you realize that you're building another protocol on top of HTTP.
At that point, it's better to reuse an existing protocol like Bayeux, and proven solutions like CometD (which is based on Comet techniques using the Bayeux protocol) that gives you:
Java and JavaScript client libraries with simple yet powerful APIs
Java server library to perform your application logic without the need to handle low level details such as HTTP or WebSocket via annotated services
Transport pluggability, both client and server
Bayeux protocol extensibility
Lazy messages
Clustering
Top performance
Future proof: users of CometD before the advent of WebSocket did not change a line of code to take advantage of WebSocket - all the magic was implemented in the libraries
Based on standards
Designed and maintained by web protocols experts
Extended documentation
I can continue, but you get the point :)
You don't want to use a low-level solution that ties you to HTTP only. You want to use a higher level solution that abstracts your application from the Comet technique used and from the protocol that transports Bayeux, so that your application can be written once and leverage future technology improvements. As an example of technology improvement, CometD was working well way before async servlets came into picture, and now with async servlet just became more scalable, and so your application, without the need to change a single line in the application.
By using a higher level solution you can concentrate on your application rather than on the gory details of how to write correctly an async servlet (and it's not that easy as one may think).
The answer to your question could be: you use Comet+Bayeux because you want to stand on the shoulder of giants.
I'm planning to setup an scalable architecture capable of providing web services on a REST interface where JSON will be sent as a result.
The web services will be quite simple for a CRUD web 2.0 app.
I think javascript (nodejs + mongodb) is a good choice for the following reasons:
Easy to find javascript developers
Good performance
Easy to scale
Shared logic/language or possible reuse of code between database query language, back-end and web-client.
There are testing and logging frameworks for node
By the examples I've seen node seems light in terms of the lines of code needed to implement web services.
Questions:
I think of scaling a node app which supplies a web service as having
a central node which will be routing/balancing charge to each of the
node instances. Which will also help doing seamless updates, is
there any piece of software already implemented which can fit that
task?
Please point all the disadavantages or other advantages you find in this back-end stack
If you feel this question opens too much of a debate and doesn't fit the stackoverflow policy please indicate a forum where I could get feedback.
Any other good persistence choices other than MongoDB? Mainly this choice comes from the javascript query language and JSON schemas.
Regarding your "router" piece:
Since your REST api will be composed of HTTP requests, it's common practice to use a high-speed proxy such as NGINX or HAProxy to distribute requests among the many servers who actually perform the work (in your case, NodeJS servers). This generally works well and allows easy scaling and failover.
I have few questions regarding HornetQ:
What are differences between HornetQ core API and the JMS API ?
is there any advantage or disadvantage on using one of these ?
Is it true to say if I use the core API and then I decide to
change my Messaging Bus (let's say to ActiveMQ) then I have to
change all my codes ?
HornetQ Core API is a proprietary API from HornetQ, while the JMS API is a standard API defined by the Java Community Process.
There are a few features that are not supported on JMS API, that are available through core-api:
It's not possible to have multiple consumers on a single topic subscription (say if you wanted to have multiple consumers to scale it better)
It's more generic on how you create the subscription. You just create a queue within an address. Very simple.
We have a nice API for asynchronous confirmations. No need to block ever if you use this feature.
The advantage on the JMS is portability. Your code stays the same if you decide to move between providers.
The disadvantage on JMS is that it lacks some features and it's a bit verbose, what's under works on JMS 2 JSR right now.
Yes, because as I have said here, Hornetq-core api is a proprietary API, hence it will only work on HornetQ. The same way as some message systems will have a proprietary API.
If you encapsulate your Messaging access you can minimize that a lot though where you could just replace a single class on your system using standard OO techniques.