I'm writing notification system and faced a challenge of how to name an API for sending notifications over network, that will also save ones into a database. Imagine that we don't need to distinguish those two responsibilities in own methods.
I've came up with the idea of "publish", however I think this decision is biased.
Which one would you recommend?
Related
I’m new to Dialogflow CX and after reading its node.js documentation (I’m a jr Dev) I’m still struggling to get the problem below solved.
PROBLEM: I need my chatbot to receive the question “do you have Toyota Corollas (cars!) in black with less than 20,000 miles, 2017 or newer and cheaper than $15,000 for sale?”
CONTEXT: I have a database with all car makes, models, years, versions, mileage, colors and prices available. The problem is that I can’t (and sorry for how silly this looks) even initiate the bot and I know that after initiating it I would need to create a zillion entities through code (can’t do it manually) so the bot would be able to read all car parameters of the user’s question. Then after reading those parameters (entities) the bot should query my database to check availability of those particular Corollas and then give a proper answer.
ASK: I would be very grateful if you could please help me initiate the Dialogflow CX bot, load all car makes, models, years, versions, colors and prices into it AS ENTITIES and then give the answer that the user needs.
I’ve checked the GitHub quickstarts and read the documentation multiple times but am still very confused.
It looks like you have a few different issues with some of the Dialogflow CX basics. Let's try to clear them up.
How do I initiate the Dialogflow CX bot?
It isn't clear what you mean, exactly, from this.
Dialogflow CX, itself, isn't a bot client. Instead, it provides integrations with various ways to communicate with your agent. This may include telephone integrations, web-based chat systems, and an API so you can integrate with other clients such as Slack.
Your Dialogflow CX agent, itself, is setup using Google's Cloud services, and can support one or more of these integrations.
How do I create a zillion entities through code?
It isn't clear why you need to create a zillion of them, nevermind through code itself.
You likely will want to create a custom entity type for the make/model combination. And it should probably have aliases, so that people could say "Ford Explorer" or just "Explorer" and have it resolve to the same type.
If you really wanted to use an API to do this, you could use EntityType.create to do so. That points to the REST documentation, but based on the language you want to use, there may be a library able to handle it.
Some of the other types, however, can be handled with system entity types such as #sys.color or a numeric type. There's no reason for you to create those.
But what happens if someone asks for a combination that isn't valid?
Then you'll need to tell them it isn't valid. Just like if someone was talking to you in person and asked for something that didn't make sense.
How will it check the database for a good response?
You'll need to make this database call as part of a webhook that you create to implement the business logic.
These days I am finding myself in the position of having to implement for one of my college courses a system that should act as a giant wrapper over many communications apps like Gmail , Facebook Messenger maybe even WhatsApp .To put it simply you should have a giant web interface where you can authorize Gmail , Messenger and use them at once when required. I am thinking of going with an REST API to manage the user's services authorized by OAuth2.Also I am thinking of using Node.JS and Express.js in the backend and React.js in the frontend. I found some sweet libraries in npm that should take care of interacting with the involved APIs(https://www.npmjs.com/package/node-gmail-api this one for instance), but I am also doubtful about this approach , for example I have no idea how to keep the use notified about its incoming mails or messages for example . I am in dire need of some expertise since I forgot to mention but I am quite the newbie in this field. To sum it up for once my question is how would you implement such an infrastructure ? Is it my approach viable or I am bound to hit some really hard to overcome obstacles?
As a college exercise, it would be a really fun experiment, so it definitely worth the time you want to put into it. However, once you want to add more features, the complexity will go up pretty fast.
Here are a couple of ideas you can think of:
It's pretty clear that your system can't do more things than the capabilities exposed by the APIs of communication apps (e.g. you can't have notifications in gmail if the API doesn't have this capability).
For that reason, you should carefully study the APIs and what functionalities they expose. They have public docs that you can check out: (Gmail API, Facebook Messanger API)
Some of the apps you want to communicate with may not have an official API (e.g. WhatsApp) - those kinds of details you definitely want to know from the start.
Based on the analysis of those APIs, you should lay out a list of requirements for your system, which can be extracted from all the APIs, for example: message notifications, file transfers, user profiles, etc.
In this way, you know exactly what capabilities your system should have, and you don't end up implementing a feature that is available only in 1 API out of 4.
Also, it would be a bit challenging to design your system from a user perspective, because the apps have different usage patterns - chat apps, where messages are coming in real-time, vs email, which is not real-time communication. That's just a detail anyway, the gist of your project is to play with those APIs.
Also, it may worth checking out the Gateway Aggergation Pattern, which is related to this project - you may want the user to send a message to multiple apps, by using a single request to your service.
I'm thinking to do Chat application in AppGyver. For now I have chat app on web with NodeJS and SocketIO, messages are store in MySQL. I was thinking how to keep on phone messages history like whatsapp.
The first thing that came to mind is that i store messages in SQLite on phone. But now bothering me the following problem, how to refresh the changes that were made while the user was not online? Perhaps to make a new table in MySQL which would contain changes made while the user is offline.
For keeping the changes involves information about the deleted conversations, deleted or added messages.
The second thing that came to mind is that all the data which get from the server, to keep as json files. However, it is difficult to carry out the changes that have made while the user was not online. At every refreshment need to open all files, then find the appropriate value and make the change.
Which of these methods would you choose, or you may have a better solution?
I wonder if someone has done something similar and whether there might be a better solutions than mine?
Best regards.
The API provides the emit/send callback mechanism to acknowledge received messages. However, this callback doesn't get fired in case of disconnect or error. It appears to me that upon a disconnection one would need to go through some rather messy procedures to clean up outstanding sent messages (e.g. - assume a use case where you may want to store messages for forwarding later, etc.). Any simple ideas out here on how to accomplish this? Wondering if I'm missing something.... Thanks.
The Real Underlying Issue
This issue isn't just limited to socket.io. It is a well known problem called the Two Generals' Problem.
Two armies, each led by a general, are preparing to attack a fortified city. The armies are encamped near the city, each on its own hill. A valley separates the two hills, and the only way for the two generals to communicate is by sending messengers through the valley. Unfortunately, the valley is occupied by the city's defenders and there's a chance that any given messenger sent through the valley will be captured (this scenario assumes that while the two generals have agreed that they will attack, they haven't agreed upon a time for attack before taking up their positions on their respective hills).
You are trying to reach Common Knowledge over an unreliable link.
At any stage of the communication over socket.io the link can be broken, and a callback can be sent but the other side could not be sure that it arrived.
What Can Be Done
You need to embrace the fact this is always a possibility. There is no trivial solution for this. This problem and its generalization are still actively studied in fields like Multi-Agent Systems research.
What can still be done in your specific case
There are some common approaches to mitigate this issue.
What I did when designing an application using socket.io is attach IDs to messages, if a disconnect happens and one side tried to send an already-sent message, the receiving side will be aware that the message was already received.
Note that in practice you don't need to do this everywhere.
More Reading on the Issue
Related question here in SO
The Byzantine Generals Problem by Microsoft Research (LESLIE LAMPORT, ROBERT SHOSTAK, and MARSHALL PEASE) which discusses the problem and suggests some solutions
Acclaimed Book by Yoav Shoham that talks about Multiagent systems and how they address this issue.
Blog post about this problem in TCP.
While the are many social networks in the wild, most rely on data stored on a central site owned by a third party.
I'd like to build a solution, where data remains local on member's systems. Think of the project as an address book, which automagically updates contact's data as soon a a contact changes its coordinates. This base idea might get extended later on...
Updates will be transferred using public/private key cryptography using a central host. The sole role of the host is to be a store and forward intermediate. Private keys remain private on each member's system.
If two client are both online and a p2p connection could be established, the clients could transfer data telegrams without the central host.
Thus, sender and receiver will be the only parties which are able create authentic messages.
Questions:
Do exist certain protocols which I should adopt?
Are there any security concerns I should keep in mind?
Do exist certain services which should be integrated or used somehow?
More technically:
Use e.g. Amazon or Google provided services?
Or better use a raw web-server? If yes: Why?
Which algorithm and key length should be used?
UPDATE-1
I googled my own question title and found this academic project developed 2008/09: http://www.lifesocial.org/.
The solution you are describing sounds remarkably like email, with encrypted messages as the payload, and an application rather than a human being creating the messages.
It doesn't really sound like "p2p" - in most P2P protocols, the only requirement for central servers is discovery - you're using store & forward.
As a quick proof of concept, I'd set up an email server, and build an application that sends emails to addresses registered on that server, encrypted using PGP - the tooling and libraries are available, so you should be able to get that up and running in days, rather than weeks. In my experience, building a throw-away PoC for this kind of question is a great way of sifting out the nugget of my idea.
The second issue is that the nature of a social network is that it's a network. Your design may require you to store more than the data of the two direct contacts - you may also have to store their friends, or at least the public interactions those friends have had.
This may not be part of your plan, but if it is, you need to think it through early on - you may end up having to transmit the entire social graph to each participant for local storage, which creates a scalability problem....
The paper about Safebook might be interesting for you.
Also you could take a look at other distributed OSN and see what they are doing.
None of the federated networks mentioned on http://en.wikipedia.org/wiki/Distributed_social_network is actually distributed. What Stefan intends to do is indeed new and was only explored by some proprietary folks.
I've been thinking about the same concept for the last two years. I've finally decided to give it a try using Python.
I've spent the better part of last night and this morning writing a sockets communication script & server. I also plan to remove the central server from the equation as it's just plain cumbersome and there's no point to it when all the members could keep copies of their friend's keys.
Each profile could be accessed via a hashed string of someone's public key. My social network relies on nodes and pods. Pods are computers which have their ports open to the network. They help with relaying traffic as most firewalls block incoming socket requests. Nodes store information and share it with other nodes. Each node will get a directory of active pods which may be used to relay their traffic.
The PeerSoN project looks like something you might be interested in: http://www.peerson.net/index.shtml
They have done a lot of research and the papers are available on their site.
Some thoughts about it:
protocols to use: you could think exactly on P2P programs and their design
security concerns: privacy. Take a great care to not open doors: a whole system can get compromised 'cause you have opened some door.
services: you could integrate with the regular social networks through their APIs
People will have to install a program in their computers and remeber to open it everytime, like any P2P client. Leaving everything on a web-server has a smaller footprint / necessity of user action.
Somehow you'll need a centralized server to manage the searches. You can't just broadcast the internet to find friends. Or you'll have to rely uppon email requests to add somenone, and to do that you'll need to know the email in advance.
The fewer friends /contacts use your program, the fewer ones will want to use it, since it won't have contact information available.
I see that your server will be a store and forward, so the update problem is solved.