I am looking for some advice on how to design the code to handle the fulfillment of requests sent by Dialogflow to my server. Dialogflow only lets setup a single webhook to handle all the intents. Let's say that I have 5 different intents; all of them will call the same webhook on my server. Now, how can I elegantly manage server-side different workflows depending on the intent?
The parameter that I would ideally use to make a distinction is contained in req.body.queryResult.intent.displayName; and indicates the name of the current intent. Right now I have two ideas, using express redirect method using the intent as part of the path, or creating a dictionary of handlers where the intents are the key.
Do you have any suggestions?
The dialogflow-fulfillment library, although deprecated, uses your latter approach - creating a Map from Intent name to Handler function and handing this map to a Dispatcher. It is a simple, straightforward, and speedy approach.
The multivocal library takes a similar, tho more expansive, approach, letting you register a handler against either the Intent name or the Action value assigned and having separate configurations for the response based on either Intent, Action, or another value that is set in the handler.
Redirecting to a new, path-based, method does not seem to give you anything.
Related
https://www.apollographql.com/docs/react/data/mutations/
Is it possible to have some kind of subscription that whenever a certain mutation is called anywhere the client is being used, we will do some event such as console.log
I believe what you are looking for is the Apollo Link functionality: https://www.apollographql.com/docs/react/api/link/introduction/.
Here you are able to inspect each GraphQL query, whether outgoing or incoming. I'd suggest having a read through the documentation to determine how best to utilise it for your use case, as you are able inspect everything - even the query name being used.
Just want to say at the beginning. I'm really sorry if you will consider this as a duplicate but I'd like to ask you what is the middleware. I know stackoverflow has some similar questions but I'd be glad if you could answer this one. Also what is the .use ? Where do we use it? Thank you very much!
Middleware is a term that refers to request handlers that "pre-process" an incoming request. A given middleware will typically run on lots of incoming requests. Usually, it doesn't send the final response, it just does some setup or pre-processing on the request and then passes the request on to its eventual handler. There are thousands on things that people find to do with middleware.
The general idea is that it's easier to put middleware in one place and configure it to apply to lots of requests rather than have to add it to every single request handler that its supposed to apply to.
I'll offer a few examples:
Check to see if the requester is authenticated/loggedin on the site. If not, then redirect to the login page. If so, then pass the request through to the actual page request handler.
Log usage or performance statistics.
Pre-parse query parameters so they're already parsed for the request handler
Pre-parse post bodies so they're already parsed for the request handler
Preset desired cross origin headers for the response
Hopefully, you can see the general idea that middleware is often used as pre-setup work that can be done in one place rather than having to be added to every single request handler.
Keep in mind that middleware can be configured to determine which incoming requests it gets run for. It can be only for a single URL (not typical), a whole group of URLs such as everything start with a particular path, or all URLs on the entire site.
I'm creating an application that uses two step object creation into firebase realtime database.
What I want is that on a cloud function that catches onCreate event, if some rules are not complete, then the create action be stopped.
Is there a way to do that? Or I need to remove the node instead of reject the creation?
Thank you!
You might want to consider a command-response model for database writes. Instead of writing directly into the database and expecting that a function cancel the write, push a "command" object into the database that describes what you want to do, at a different location, and have a function respond to that command to determine what should actually be done. Your function can then determine whether or not to commit a final write if the conditions are OK.
I gave a talk at Google I/O 2017 that outlines this strategy with respect to a multi-player turn based game that intercepts all move requests to determine if they're valid before committing them to the game. The part about command-response starts here.
There currently is no way to reschedule a trigger. So indeed, you'll either have to create a new node or trigger a re-check in some other way, e.g. a regular cron trigger to clean up the previously unhandled nodes (blog, video).
I'd like to use an old s_code.js to generate a url that I can use to track an event, but I'd like not to use s.t() as it provides no way of keeping tabs on the request. Is there any way to get the url as a String before sending off the tracking request with s.t()?
You'd need to pull from a mixture of methods in order to get this data. There is no one method (at least in AppMeasurement) that will get this for you. A combination of s.pb (builds the domain and path, but also calls for the creation of the request), s.gb for the build of URL parameters, and s.t for the build of the cache buster. YMMV given this is in the core library with 0 expectations of internal methods not getting renamed.
I guess my question is why you're wanting to do this. There are options of preventing the call from being made, but needing to inspect the URL is a first for me.
In our codebase, we have recently migrated a lot of React components to a pure flux architecture. Thus, our data flow looks almost exactly like this image provided by the Facebook team:
(source: github.io)
One issue we're running into is that there's a lot of boilerplate code required to make a call to the server and get a result. The process is as follows:
View propagates an action called something like GET_DATA_FROM_SERVER to an action creator (let's say called ViewActionCreator).
ViewActionCreator dispatches this action, which has no payload in most cases, and then calls api.retrieveData
Upon receiving data from the server, api.retrieveData dispatches an action, in this case called SERVER_DATA_RECEIVED with the retrieved data as the payload.
Stores respond to the two actions dispatched. However, in most cases stores only do something for the second action (SERVER_DATA_RECEIVED), since we've found that optimistic view updates are, with a few exceptions like logging in, not usually required or very helpful.
Hence, my question is, is there any reason why we shouldn't have views call api's methods directly, and have those api methods dispatch actions only upon data reception?
Another related issue we're running into results from the use of constants, generated using https://github.com/STRML/keyMirror. We repeatedly run into an error where we forget to add a constant used in an action creator and store to our constants file, but this doesn't manifest until runtime, since our stores use switch statements to test which action they're receiving from the dispatcher, and when we use a constant that's undefined, this simply percolates down to the end of the switch statement.