Ok, let's say that there's a company (let's say e-commerce) that has to implement a support chat on its website. Do you know what are protocols/infrastructures needed?
I've seen XMPP but I don't know if it's really useful in my case...
Ty a lot!
If you need to implement all things yourself, and don't want to use XMPP server, you can create your own chat protocol.
Such a protocol can be based on JSON-RPC.
Also, you can make a simple protocol using only features from Socket.IO.
You can use Socket.IO both on the server and client-side.
You will also need a database for storing chats and messages.
If you anticipate very heavy traffic, you can use e.g Apache CASSANDRA, but a plain SQL (or noSQL) database will be sufficient for most implementations.
It is better to use a database you are familiar with. The PostgreSQL can be a good choice because it has nice JSON support.
If you prefer a noSQL database, MongoDB will be OK.
If you use React, for the frontend I recommend you to use a #chatscope/chat-ui-kit-react components together with the #chatscope/use-chat library (I'm the author of both of them).
Related
I'm searching a simple implementation to push changes from a free relational database (PostgreSQL, MySQL, SQLite, etc.) to clients' browsers via WebSocket or WebPush.
I want to avoid all the server-side JavaScript ecosystem (Node.js, npm & cie) and the NoSQL databases.
All must be hosted in the servers of my company, I can't use third-party services.
I found these interesting solutions :
http://initd.org/psycopg/articles/2010/12/01/postgresql-notifications-psycopg2-eventlet/ [with Python]
https://gist.github.com/drocco007/6e44ac1a581546c16e67 [the same one slightly improved]
https://coussej.github.io/2015/09/15/Listening-to-generic-JSON-notifications-from-PostgreSQL-in-Go/ [with Go]
Do you know other ways to get this done?
Is PostgreSQL the more suitable free RDBMS to do this?
Can it be accomplished with a SQLite database?
Can Apache or NGinx abilities be used to achieve this?
Update 01/23/17: I wrote an application called postgresql2websocket in order to send PostgreSQL notifications over websockets using Python 3 with asyncio + aiohttp + asyncpg https://github.com/frafra/postgresql2websocket; you could combine it with PostgREST in order to have both standard REST APIs and realtime updates using WebSockets.
As far I know, there is no HTTP server extension for using SQL databases with Websockets without anything in the middle.
You can use Python on the server side, like this: Real Time Web Apps with (just) Python and Postgres. I think it could be improved thanks to aiopg. If you don't need Websockets, you can just use ngx_postgres.
If you like Django, Django Channels will be probably included in Django 1.10 (Redis/in-memory/... layer for channels and SQL backend).
You could use SQLite, but bear in mind that you have to implement a separate server side publish/subscribe mechanism (like Django channel does), because SQLite doesn't have one.
If you're just interested in pub/sub over Websockets, you could use Webdis (Redis-based solution): it would be probably lighter than a full SQL database.
I developed a REST API with Play 2.2.0. Some controllers expose GET methods, other expose POST methods with authentication etc...
I developed the client using Play as well but I have a problem. How can I avoid duplicating the model layer between both applications ?
In the server application, I have a Model Country(code, name).
In the client I am able to list countries and create new ones.
Currently, I have a class Country in both sides. When I get countries I deserialize them. The problem is that if I add a field in Country in the server, I have to maintain the client as well.
How can I share the Country entity between applications ?
PS : I don't want to create a dependency between the API and the client, as the client could have been developed with another language or framework
Thanks
This is not very specific to play framework but is more of a general question. You either create reusable representations of the data in your protocol (the actual data structures you send between your nodes) and get a tight coupling in representation and language. Many projects does it like this, since they know they will have the same platform throghout their architecture.
The other option is to duplicate all of or only the parts of parsing/generating that each part of the architecture needs, this way you get a looser coupling and can use any language in the different parts.
There are also some data protocols/tools that will have a representation in a protocol specific way and then can generate representations in various programming languages.
So as you see, it's all about pros and cons - neither solution is "the right way (tm)" to do this, you will have to think about your specific system/architecture and what pros are most valuable and what cons are most costly to you.
Well I suggest to send to the client a template of what they should display, on the client with js take advantage of js template frameworks, so you can tell to the client how can show them, dynamic... if they want to override them well... more job
We can call them Rest component oriented...
well suggestions :)
should works!
I'm developing a website with a Lucene backend. Lucene connects directly to index files, making it difficult to develop the website from machines other than the index machine. Traditional databases have a server running to provide an intermediary between the raw data and the application.
I would like to create such an intermediary between Lucene and my web application. On first thought, Akka seems like the right tool, and I think I would use Akka futures or typed actors to perform the call. However, the Akka Typed Actors page warns:
"A bit more background: TypedActors can very easily be abused as RPC, and that is an abstraction which is well-known to be leaky. Hence TypedActors are not what we think of first when we talk about making highly scalable concurrent software easier to write correctly. They have their niche, use them sparingly."
I think the point is that RPC promotes centralization, but is my plan a good one or an abuse of Akka?
Why not use solr? It provides the application to manage your lucene indexes (as it is basically lucene with an application over the top to interact with the data. It would be easier than dealing with actors and it should provide everything you need.
There are now REST apis for Mongodb and redis.
I can connect to those databases with my language's driver.
Or I can use the REST api. I understand that the REST api is easier to grok, and easier to convert from language to language. But there's less features.
But is there any reason to use the rest api if I'm already doing fine with the language driver?
Thanks.
In my opinion a RESTful API is useful when you have to integrate multiple different clients in heterogenous environments. It's also good when you need features that are already solved for HTTP – like caches or load-balancing.
REST resources are supposed to capture use-cases of your application. I find it highly unlikely that an API to a database would do that for you. Mostly like the native language driver is the appropriate choice.
Rich web clients can talk directly to it, without any server side mediator. Also, for instance, if you have a JCR repository with NoSQL connector on hostA and NoSQL store on hostB, you're glad for RESTful api.
I am looking for an open source framework to build a proprietary protocol onto (Agent/Client talks to a Receiver/Server that stuffs things into a SQL database).
I need session handling (ie login/logout) and some kind of encryption.
I found the Spread Framework which looks great, but does not appear to support authentication or encryption of any kind out of the box.
My preferred language is C, C++, Python, or Perl.
Anyone know of anything off hand? Hoping for something to be out there to save me time rather than doing it the hard way all in *nix sockets ;)
Thanks in advance!
Why not use libcurl, as it can do SSL.
http://curl.haxx.se/libcurl/c/example.html
DJango and DJango ORM, or SQLAlchemy combinations can be a good start. A python base framework and ORM.
Since you are working at the socket level, I assume that you are trying to write an application from the ground up. Or are you trying to run within an existing web server?
Could you use lighttpd with HTTPS & mod_cgi? This isn't really a framework, per se, but it would keep your application portable to other infrastructures.
On the server side, CGI::Session could take care of the session management. Authentication could be done using mod_auth.
Why not use SSL/TLS? On the client you can use libcurl, which works with C, C++, Python, and Perl. On the server, use Apache, lightttp etc, with cgi or your favorite language. You can use mutual authentication to ensure verify the identify of both the client and server, as well as provided an encrypted channel.