Speaker 1: Hey, everyone, welcome to another episode of React Ground Up.
Speaker 1: I am your host today, Paige ne dream House, and
Speaker 1: I am joined by our panelists TJ.
Speaker 2: Vantol, Hey everybody.
Speaker 1: And Jack Harrington.
Speaker 3: Hey there.
Speaker 1: And our special guest today is Victory Nwani.
Speaker 3: Looking welcome.
Speaker 1: Victory. We're really happy to have you here with us,
Speaker 1: and if you'd like to introduce yourself to our audience
Speaker 1: and tell us a little bit about why you're famous,
Speaker 1: I think that would be a great place to start.
Speaker 3: Thank you for giving me the opportunity visically, I'm Victor Money.
Speaker 3: I'm based in Africa. I work remotely with an IoT
Speaker 3: company in Austin, Texas called Ambionik, and we viewed an
Speaker 3: I application for old detection. So it's used primarily in
Speaker 3: the healthcare line. And aside that, I'm also a technical
Speaker 3: author on Smashing Magazine, Love Growth, It, Digital Ocean, and
Speaker 3: her so I write organizations as a technical OO and
Speaker 3: I'm also interested in cloud in DA so when I
Speaker 3: love working on the front and side, working as an
Speaker 3: architect and the Google Cloud and Azure and yes, that's
Speaker 3: pretty much about it.
Speaker 1: Wow, that's that's plenty. I think you've got a lot
Speaker 1: going on, so I see that you have. Like you said,
Speaker 1: you're an author for a lot of different awesome publications.
Speaker 1: But the one that we were interested in or that
Speaker 1: we came across most recently was integrating a dialogue flow
Speaker 1: agent into a React app. And I was wondering if
Speaker 1: you could tell us a little bit more about that,
Speaker 1: and I'll link it for anybody in the podcast who
Speaker 1: wants to check it out later on.
Speaker 3: Yeah, So that was actually a two part article, so
Speaker 3: it focused on that log flue. I needed to use
Speaker 3: that log flue for a project, so I had to
Speaker 3: mean about it, and during the process, I also wrote
Speaker 3: that article on that flu. So what it doesn't it
Speaker 3: basically explains our dialogue flue is that's the first part
Speaker 3: of the au and the second one talks about integrating
Speaker 3: that log flu into your React application. So we use
Speaker 3: that stand alone dialogue flu agent into a React application.
Speaker 3: So it's a two path. That's a cool and are
Speaker 3: glad to explain?
Speaker 2: Yeah, maybe you can start by explaining just what dialogue
Speaker 2: flow is because I definitely am familiar.
Speaker 3: Okay, So that look flow is a savage oft on
Speaker 3: the Google Cloud, and it's what it does basically is
Speaker 3: to it makes building natural language procession applications much much
Speaker 3: more easier, so real and having to build the machine
Speaker 3: learning models, having to train everything on your own. What
Speaker 3: that log Flue does It gives an opportunity to do
Speaker 3: this while leveraging the cloud, so you could basically build
Speaker 3: the natural language professional application straight up from your iPad.
Speaker 3: It all leverages the cloud for you.
Speaker 2: Some curious that you come across this for like a
Speaker 2: work purpose or was this just I'm curious what your
Speaker 2: use use case was for diving into this.
Speaker 3: So my my was to build a food application. So
Speaker 3: wanted to build a chat assistant for a food application.
Speaker 3: So it's one of the things which allow Flue does.
Speaker 3: It helps you build chat assistance, so where you have
Speaker 3: chat boats like Cey, those series quite complex as we
Speaker 3: all know. But what it does is it helps you
Speaker 3: build chat assistants, chat boats applications that can classify texts
Speaker 3: and things like that. So that was what I needed
Speaker 3: to use it for. It was to be used for
Speaker 3: the chat assistant for a food software. Whether instead of
Speaker 3: having a human respond to chats, the chatboats would do
Speaker 3: that on behalf of a human.
Speaker 1: That's very very cool. So give me a little bit
Speaker 1: more about dialogue flow. Does it use like machine learning
Speaker 1: or some kind of artificial intelligence to drive it, or
Speaker 1: how does it If you say, I guess I'm looking
Speaker 1: for a recipe, or maybe I'm looking for a restaurant
Speaker 1: recommendation or something like that, how does it know what
Speaker 1: to respond with as a human might?
Speaker 3: Okay, so I'd just like to say a little bit
Speaker 3: of a disclaimer. One of the things that long flud
Speaker 3: does is it's abstract a Lady onderline complexity. So I
Speaker 3: cannot fully say I understand how it operates because it
Speaker 3: abstracts a way that complexity from you. But it does
Speaker 3: it gives you a service to use. But like you said,
Speaker 3: dialogue flu performs text classification, text extraction, intense classification, and
Speaker 3: special cognition. So, like you said, what it does in
Speaker 3: that scenario would be it would be able to classify
Speaker 3: your text knowing that page wants to buy something. It
Speaker 3: classifies your intents you want to purchase something, and it
Speaker 3: responds back using a trained model.
Speaker 4: Very cool.
Speaker 5: So your article is actually a really nice like end
Speaker 5: to end the full stack system. I mean, it's you've
Speaker 5: got like the training or the agent definition of the
Speaker 5: Google Cloud stuff upfront. Then you've got an express server,
Speaker 5: you've got MOBS, and you've got React up on top
Speaker 5: of am I summarizing that correctly.
Speaker 3: Yeah, so those are actually two parts split the path.
Speaker 3: First off is the dialogue Flue application and cond part
Speaker 3: is the front end application. So that log flow is
Speaker 3: quite standalone or do. It's offered through the Google Cloud.
Speaker 3: So to use that log flow you need to have
Speaker 3: Google Cloud project because it's one of the offerings of
Speaker 3: the Google Cloud. But there are several ways you could
Speaker 3: use that log flu Basically, you could also use it
Speaker 3: through the Google Assistance, so you could deploy Google that
Speaker 3: log for application to the Google assystem. We all know
Speaker 3: Series for io s. Why the Google Assistance is for
Speaker 3: Android devices, so you do not need to have like
Speaker 3: a front end application to use that log flu. You
Speaker 3: could deploy to Google Assistant platform and use it Vibe
Speaker 3: and a smart works.
Speaker 5: Oh nice, so we have like the smart speaker or
Speaker 5: an Android phone that's got the assistant. You can actually
Speaker 5: integrate with that too, exactly. Yeah, nice, very cool.
Speaker 4: Yeah.
Speaker 5: No, it's a nice full stack system there. So if
Speaker 5: somebody wants to learn essentially what go from fro an
Speaker 5: end to full stack. This is actually a really nice
Speaker 5: demo application to walk through.
Speaker 3: Yeah, exactly, And I wrote that in the second part
Speaker 3: of the article.
Speaker 5: Yeah, so I'm just curious, why did you choose my backs.
Speaker 5: It's like a controversial choice in the React world.
Speaker 3: Mobex is just quite like a state management package for reacts.
Speaker 3: It's quite simpler than REDUCS. Like that argument is kind
Speaker 3: of yes, that's kind of Mobis brings in the object
Speaker 3: oriented programming into step managements, while REDUCS is more functional programming.
Speaker 5: That's about the best synopsis I think I've ever heard
Speaker 5: about those two. I can never hone it down to
Speaker 5: that level.
Speaker 1: Yeah, I've never actually used Mobex or flux or any
Speaker 1: of the other ones. I've only used REDUCTS. Although I've
Speaker 1: been hearing pretty good things about the new Redux toolkit,
Speaker 1: which I think is kind of REDUCS two point oh,
Speaker 1: that it's abstracting away a lot of the boiler plate
Speaker 1: and the things that people didn't particularly like about REDUCS.
Speaker 1: But I mean that's cool. Mobex is definitely still a
Speaker 1: good a good option. And I think there's an other
Speaker 1: one that Facebook came out with, and now I'm trying
Speaker 1: to think of the name of it.
Speaker 3: I think that's the context API.
Speaker 4: Context is.
Speaker 1: I mean, that's definitely been a game changer. But there
Speaker 1: was a new a newer one, and now I can't
Speaker 1: think the name of it. I'll have to look it up.
Speaker 1: That it seems like was maybe it was Recoil.
Speaker 3: Oh, yeah that was yeah, yeah, I think recoil is
Speaker 3: quite new. Or do I read the ad crew the
Speaker 3: while back? So I didn't think there was a context
Speaker 3: API when I read that, I've used the context API.
Speaker 5: Well, context API has been undocumented for a long time,
Speaker 5: and then it got formal. Finally, I think I can
Speaker 5: read it like sixteen, I think it got formal, and
Speaker 5: then then reactors came in and got.
Speaker 1: Yeah, that's I think really revolutionized using the context APIs
Speaker 1: as a real solution. So Nwani our victory, what what
Speaker 1: kind of spurred you to learn about dialogue flow Because
Speaker 1: this is a it's a very cool API. But with
Speaker 1: all these cloud pro with Amazon, with Google, with Azure,
Speaker 1: even there's so much that's hidden in all the services
Speaker 1: that they offer. So how did you, I guess, find
Speaker 1: this and decide this is what I wanted to test
Speaker 1: out and see how it works.
Speaker 3: Basically, when I would when I needed this service. Dialogue
Speaker 3: Flu was kind of the most popular service. The other
Speaker 3: services apart from Dialogue Flue like the watson as system
Speaker 3: from IDM. What didn't Google Dialogue Flu was the simplicity
Speaker 3: and how easy it was to use, so I didn't
Speaker 3: have to lend the basic things because I'm not like
Speaker 3: a machine learning expot I'm more of a front end engineer,
Speaker 3: so it wasn't so difficult for me to pick up
Speaker 3: and that was what made me use that look flasically.
Speaker 1: Was the documentation for it pretty decent as well, because
Speaker 1: that's always my thing is I need to see working
Speaker 1: code examples and then I can figure out how to
Speaker 1: put it into my own applications for my own code basis.
Speaker 3: Yeah, pretty much pretty much you know of back Google.
Speaker 3: Everything from Google is quite comprehensive in terms of the documentation.
Speaker 3: It's also important to note that I think Google both
Speaker 3: dialog Flu. They're not the original creators. I'm trying such
Speaker 3: of the name, but it was originally called AI. That's
Speaker 3: something I can't remember the name now, which was both
Speaker 3: about by Google.
Speaker 2: So I'm curious and this is a little bit of
Speaker 2: a broader question, and I'm not sure a nice way
Speaker 2: to phrase this, but I'm curious if dialogue helps you
Speaker 2: build chatbots that are actually good. And I think what
Speaker 2: I'm the broader thing to me is like I feel
Speaker 2: like chatbots are one of the more underutilize things in
Speaker 2: software development because I feel like there's an absolute enormous
Speaker 2: amount of potential there, but every time I personally go
Speaker 2: to use one, I hate it. I've yet to use one,
Speaker 2: and I'm seeing on the call here page and Jack
Speaker 2: shaking their.
Speaker 4: Heads as well, like it's I avoid them every Yeah.
Speaker 2: But it's so frustrating because they should be good, right
Speaker 2: like this is twenty one, we should like you should
Speaker 2: have like the technology behind it. So I'm curious victory, like,
Speaker 2: have you had like positive experiences? Do you get like
Speaker 2: analytics from dialogue flow that tells you like how well
Speaker 2: this is performing? And I'm just curious your thoughts on
Speaker 2: that topic.
Speaker 3: I would pretty much say yes, dialogue flow is quite
Speaker 3: good because, like you mentioned monitoring, we have the Dialogue
Speaker 3: Fluw console which you can use to monitor statistics about
Speaker 3: your chatbots. So delog Flow is basically offered in two editions.
Speaker 3: We have the ES edition and the CX edition. The
Speaker 3: EES is for quite small use cases like small startups,
Speaker 3: while the ES is for larger use cases that are
Speaker 3: being used by larger startups and companies. So one of
Speaker 3: the things I really love about dialog FLUW is the
Speaker 3: console itself. You can do basically a lot of things
Speaker 3: with the console. You can export a dialogue flu application.
Speaker 3: You can also import a dialogue application. So the pretty
Speaker 3: much a lot of things you can do with dialogue
Speaker 3: flu and it's quite difficult to And so when you
Speaker 3: said there are love teams that are frustrated about using
Speaker 3: childboats because I don't really know those pin points which
Speaker 3: you have using childboat providers.
Speaker 2: Yeah, well I'm more curious, like how do you know?
Speaker 2: Like so, like, hypothetically I'm building a food application, right
Speaker 2: and I build a bunch of different chat conversations and
Speaker 2: dialogue flow. What would give me confidence that my users
Speaker 2: are actually using this thing and succeeding with it. Because
Speaker 2: I think a lot of people debating this, right, Like,
Speaker 2: like I said, there are tons of potential applications for this.
Speaker 2: Do you want to know that you aren't frustrating your
Speaker 2: users or your your customers that they're actually using this
Speaker 2: thing successfully? So I'm just curious like what sort of
Speaker 2: signals dialogue flow gives back that people are like successfully
Speaker 2: going through these things that you're creating.
Speaker 3: So dialogue flu at the basic level, it gives you
Speaker 3: some level of observability and monitoring for you to know
Speaker 3: that these are the parts of your caation being used
Speaker 3: all through the console. So after deploying application, you can
Speaker 3: run test yourself or you could give an interval to
Speaker 3: know to see the statistics coming from an application.
Speaker 4: So okay, walk me through this flow a little bit
Speaker 4: with this food app.
Speaker 5: So you're you're trying to sell wine essentially, what how
Speaker 5: does how does the agent know.
Speaker 4: What wines are available? Like or is that part of
Speaker 4: the service.
Speaker 5: Can I say, like give me a good pino or
Speaker 5: something like that, Like how does that actually? Like walk
Speaker 5: me through the whole data flow here just at a
Speaker 5: high level.
Speaker 3: So at a high level, that loog flow is broken
Speaker 3: down into entities, and like you mentioned, the first thing
Speaker 3: you would have to do would be to create intents.
Speaker 3: So your first intents would be I want to buy wine.
Speaker 3: The block flow agents is going to be able to
Speaker 3: classify do some extraction from that text to know that
Speaker 3: this individual wants to opportunity whine, and there's going to
Speaker 3: be a key word. There's that keyword falls under a context,
Speaker 3: so it knows that this is the name of the wine.
Speaker 3: Funny enough, I did demo applications within the article is
Speaker 3: on a wine application. So if you put in the
Speaker 3: name of the wine, like for example, the Malotte Red Wine,
Speaker 3: it has the ability to extract that name. So while
Speaker 3: training the chatbots, you're providing a very long list of names.
Speaker 3: Then whenever the user and has that name, it has
Speaker 3: the ability to extract the name. I know that this
Speaker 3: is the wine exactly the user wants to buy. Then
Speaker 3: it can respond back using a restaurant that you have provided.
Speaker 4: I see.
Speaker 5: So as part of the message that you get about
Speaker 5: the intent like, you get essentially a broken down thing
Speaker 5: that says, here's an event is a customer wants to
Speaker 5: buy a wine event and here's the type of wine
Speaker 5: that they want to buy, and then you can go
Speaker 5: and respond to.
Speaker 3: That exactly cool, And they're also.
Speaker 4: Quite sounded good there. I think we lost.
Speaker 3: Okay, okay, I think yeah, type broke up. So those
Speaker 3: things are on a basic level, we can know them
Speaker 3: as keywords, but on the dialogue flow they're known as entities,
Speaker 3: so that lock Flue attracted those entities from a single
Speaker 3: user statement. And these entities could include price, So you
Speaker 3: could say I want to buy a red wine for
Speaker 3: five dollars. It's going to extract a five dollars from
Speaker 3: from that text and respond back its own response. The
Speaker 3: entity could also be a link. Well, most of the
Speaker 3: times you provide those entities while you're training the agent,
Speaker 3: So there's a whole training process that goes on before
Speaker 3: deploying your agents for use, and that's where you define
Speaker 3: most of these things.
Speaker 2: To keep going with this example, so you create intents
Speaker 2: it says, okay, the person wants to buy wine for
Speaker 2: five dollars or whatever the case may be. Presumably then
Speaker 2: you have a chance to wire that up to some
Speaker 2: sort of endpoint because like you might have like a
Speaker 2: service that returns here are the wines that we have
Speaker 2: for five dollars, So is there like some way to
Speaker 2: wire it up to a back end for that sort
Speaker 2: of thing exactly?
Speaker 3: And that falls on that for three minutes. So like
Speaker 3: I said, that luck Flu is broken down into several
Speaker 3: entities the same way within the objects in the programming
Speaker 3: could know them as objects. So that's on that the
Speaker 3: fulfillment entity. So the fulfillment allows you to call the webook,
Speaker 3: so you could have like a custom database of your
Speaker 3: own weby. You have like a cloud function, so when
Speaker 3: that intent is being recognized, it caused your cloud function,
Speaker 3: which achieves it from a database. So you say I
Speaker 3: want a wine of five dollars, it sends five dollars
Speaker 3: to the database and it retrieves a wine for that
Speaker 3: exact amount. So fulfillment allows you to give a better
Speaker 3: dynamic response to an intent rather than just some have
Speaker 3: cood add value.
Speaker 1: Interesting, So you were saying that you need to train
Speaker 1: the models before you can really kind of let the
Speaker 1: chat loosen to the world. How long How long did
Speaker 1: it take you to kind of train them up to
Speaker 1: get them good enough that they could interact with customers.
Speaker 3: It took about two weeks. But this varies basically based
Speaker 3: on your use case. Because you could have like a
Speaker 3: module larger application, it would definitely take you mucho long.
Speaker 3: Got time to trink Well, I'd like to clarify that
Speaker 3: on like where you're building a traditional machine learning application,
Speaker 3: it takes a few seconds to trim chatboats. So basically
Speaker 3: it's at it's almost instant at the click of a button.
Speaker 3: It takes a few seconds when you click the trim
Speaker 3: button and all goes up to what I'm trying to
Speaker 3: say is it doesn't take so much where you have
Speaker 3: you probably have to sit and list for the entire
Speaker 3: application to get tramed, then you have to come back.
Speaker 3: It doesn't take that process with that log flu, it
Speaker 3: all leverages the cloud.
Speaker 2: So then I'm curious, then, how what's the step that
Speaker 2: gets you this into a React application. So presumably there's
Speaker 2: you in your own app have to capture inputs text
Speaker 2: or maybe even like audio voice audio. I'm not sit
Speaker 2: so I'm curious about that. But then also like this
Speaker 2: dialogue flow give you like some API, some like javascripting
Speaker 2: you have to like MPM install that to send requests to.
Speaker 3: Yeah, so two major means to use dialogue Flu. There's
Speaker 3: a rest API which you could make yourself for There's
Speaker 3: a rest API with an end point for dialogue Flu,
Speaker 3: but you have to authenticate through the API. There's also
Speaker 3: an MPM package you can which you can install. But
Speaker 3: there was like a drawback to the MPM package, which
Speaker 3: is it uses gr PC within jrpcy is not yet
Speaker 3: fully compliance with the browser, so I had to build
Speaker 3: a back end for the entire for the dialog Flul application,
Speaker 3: so you can only you can use gepcy within the
Speaker 3: new the environments, but if you want to use it
Speaker 3: within the browser, you'd have to play around your web pack,
Speaker 3: which I wasn't willing to do, so I had to
Speaker 3: use it from an experts application.
Speaker 5: So, building on TJ's question from before about how to
Speaker 5: check if this is actually doing the right things the customers,
Speaker 5: I mean, there's obviously sales data in this case, but
Speaker 5: how would you imagine testing this from like a unit
Speaker 5: test perspective or just a is there a way where oh,
Speaker 5: I've uploaded I've uploaded a new agent, I mean, run
Speaker 5: a set of tests where it's like, let me just
Speaker 5: make sure that it's recommending the right one to me.
Speaker 4: Again, how do you manage that?
Speaker 3: I didn't actually make more such on that, because I
Speaker 3: don't really think there's a way you could unit test this,
Speaker 3: because it's it's more like I said, there's a lot
Speaker 3: of abstraction from the underlying implementation that looks through. What
Speaker 3: it gives you is basically the comes well. One of
Speaker 3: the things which you could write tests for are your
Speaker 3: integrations basically, Oh.
Speaker 4: Yeah, that makes sense.
Speaker 2: Yeah, if you're doing like a full integration test, I
Speaker 2: suppose you could use their endpoints. Let's say if I
Speaker 2: send in this, then I expect this to come back,
Speaker 2: which I think would work.
Speaker 3: Yeah, but that would mean you'd running live a FI tests.
Speaker 3: But wanting to notice the API requires some form of authentication,
Speaker 3: which is a Google account.
Speaker 2: Oh for for users, or well for like one like
Speaker 2: your like business or your personal cab for running it.
Speaker 3: Yeah, you would still need to use an authentication method.
Speaker 1: Yeah, I mean that could be that could be doable.
Speaker 1: So one thing that I was curious about, and this
Speaker 1: is this is kind of a good segue into it,
Speaker 1: is how is the pricing for something like this using
Speaker 1: this service?
Speaker 3: I guess yeah, so the present for dialog flu is
Speaker 3: quite low, and you can also use the pricing calculator
Speaker 3: on the Google Cloud. But I think for the for
Speaker 3: the ES version, which is majorly for small start ups
Speaker 3: and small use cases, there's a high amount of CAUs
Speaker 3: so each call you make is kind of methid. So
Speaker 3: there's an allocation of calls which you are given for
Speaker 3: free to use. I'm trying to pop up the present calculator.
Speaker 3: The present calculator is basically used for all services and
Speaker 3: Google Cloud, so you could just check up the price,
Speaker 3: how long it's going to take you to run dialogue
Speaker 3: flu for probably.
Speaker 1: More, but that's good to know. So if you were
Speaker 1: like kind of like you or like one of us
Speaker 1: getting started with it and you just wanted to try
Speaker 1: it out, see how it works, tinker with it, there
Speaker 1: is either practically no cost or a free out that
Speaker 1: you can use just to get started and figure out
Speaker 1: if it's right for you.
Speaker 3: Exactly. There's a very high free amounts. Basically, when you
Speaker 3: create a new project on a Google Cloud, you get
Speaker 3: awarded with three hundred dollars to use for free. You
Speaker 3: could use that, and you could also use the free
Speaker 3: code which is given to you. I'm trying to pop
Speaker 3: up that DATAI exactly excellent.
Speaker 1: Maybe we can link to that in the show notes,
Speaker 1: because that's always something that I'm curious about. Don't understand
Speaker 1: the price and calculators a lot of times because it's
Speaker 1: fractions of a cent. It's always helpful.
Speaker 3: Any time where I lead around with that. Look Flue,
Speaker 3: I didn't get to pay for it.
Speaker 5: They're usually pretty good about that sort of thing. This
Speaker 5: is a fantastic idea, by the way, for like a hackabon.
Speaker 5: If you work at an e commerce company, I know page,
Speaker 5: you know, for example, like at home Depot, this would
Speaker 5: be an awesome thing just you know, hook this thing
Speaker 5: up to your product inventory and the next thing and
Speaker 5: hell you're like, hey, I need a hammer and it's
Speaker 5: like yep, okay great, and you're like, yep, okay, thanks,
Speaker 5: I'll take the I'll.
Speaker 4: Take the drone or whatever. Which is the Akathon project win.
Speaker 3: Yeah exactly. I think I got the link, so I'm
Speaker 3: just going to piece it in the message now.
Speaker 1: Yeah, yeah, this kind of thing. I'm sure Home Depot
Speaker 1: is doing stuff like this. I can't remember. There must
Speaker 1: be a chatbot somewhere, either on the website or maybe
Speaker 1: in the mobile app. But yeah, this would be very
Speaker 1: very helpful I'm sure for customers as well as having
Speaker 1: to have less people trying to staff that kind of
Speaker 1: thing at all times.
Speaker 4: Oh yeah, definitely.
Speaker 5: I mean if you think about like discord bots or
Speaker 5: slack bots, I mean, the possibilities are endless for this
Speaker 5: sort of thing.
Speaker 3: Yeah, exactly, in high demand for services that do not
Speaker 3: have a lot of manpower to handle custom market so
Speaker 3: they could build a chat box and they could use
Speaker 3: it for their custom market fronts. And one good thing
Speaker 3: to also know is we have dialogue flu templetes. So
Speaker 3: if you, as let me say, Page doesn't know much
Speaker 3: about dialogue Flue, they have prebuse templates which you could
Speaker 3: make user You could just put it into your dialogue
Speaker 3: fluw project and make you a bit like that without
Speaker 3: having to go deep into building news.
Speaker 1: That's excellent. I can see that being really useful for
Speaker 1: when you want to, I guess give your maybe your
Speaker 1: customer use or your customer agents. You know, they can
Speaker 1: just tell you, like, these are the scripts that we
Speaker 1: typically use for helping our users, and somebody who's maybe
Speaker 1: not the technical developer or the lead on the team
Speaker 1: can just pop those in and get up and running
Speaker 1: with dialogue flow, which is awesome.
Speaker 2: Yeah exactly, I think, Yeah, I want to.
Speaker 3: Sorry, go ahead, keep bumping in. I just want to say,
Speaker 3: it's actually a zip file, so after you build your
Speaker 3: dialogue Flue application, you could choose to zip it and
Speaker 3: export it and someone else could use that could and
Speaker 3: rebuild their own dialogue flow projects.
Speaker 2: Yeah, because I think like it's a tall ass for
Speaker 2: an individual like restaurant or small business to do this
Speaker 2: sort of thing, because they just don't have like a
Speaker 2: development team that's going to build and maintain this sort
Speaker 2: of thing. But I could totally see if there was
Speaker 2: some sort of like reusable template where you can just
Speaker 2: plug in small things, like if if it's a scheduling
Speaker 2: thing like put in your hours or something like that,
Speaker 2: to sort of make this sort of thing possible.
Speaker 3: Yep.
Speaker 2: Seems to me too that like the easiest way to
Speaker 2: input this is if they're if you're you have some
Speaker 2: sort of flow where there's like clear input output, because
Speaker 2: I think, like if if people are going to be
Speaker 2: asking vague questions, I'm also curious what like air handling
Speaker 2: is like in dialogue flow because I'm I can almost
Speaker 2: guarantee you someone's going to use the like wine service
Speaker 2: and say something like where's the bathrooms or the videots
Speaker 2: some other like nonsensical things, So I presumably you have
Speaker 2: some way of telling people if the thing doesn't recognize
Speaker 2: like the user's intent at all.
Speaker 3: Yeah, there's there's some fun handling so which each intent
Speaker 3: to create you have the opportunity to add fallbacks, fallback
Speaker 3: statements so each intense gets a response. Whenever the intent
Speaker 3: the statement to be used with the intent is not much,
Speaker 3: you could fall back to a sentence. You could have
Speaker 3: just one or two sentence which you mak as full
Speaker 3: back sentences. So whenever your intent is not much, I
Speaker 3: could tell you, hey, page, I do understand what you're saying.
Speaker 3: Can you say this? So through your full back statements,
Speaker 3: you could even teach the user the right sentence to
Speaker 3: make to the new That is what you could say
Speaker 3: that you would recognize.
Speaker 2: So follow up to do you get like analytics or
Speaker 2: data and what people are saying?
Speaker 4: So like?
Speaker 2: Because I could totally see it being useful if you're
Speaker 2: building a wine service and like you're getting a bunch
Speaker 2: of requests for some other type of drink, or maybe
Speaker 2: like people are saying keep saying the same slightly wrong
Speaker 2: thing that's causing the path to screw up. So you
Speaker 2: get them like train it better? Do you get access
Speaker 2: to it like that sort of data?
Speaker 3: Yeah, so you get this dedicated analytics speech which shows
Speaker 3: you the various requests and all statistics for the entire
Speaker 3: dialogue Flue application. So when you're going through analytics speech,
Speaker 3: you could see that these are the intents being much
Speaker 3: These are the ones that are not really been much.
Speaker 3: So using the numbers, you could prioritize them, or you
Speaker 3: could know that these ones are not getting much to
Speaker 3: probably because I havn't hard time muching this intent and
Speaker 3: you could probably redesign it. Well.
Speaker 5: It's funny how we come back around to when we
Speaker 5: want to develop the service, it's like, oh, yeah, we
Speaker 5: need all that data. But then when Amazon or Google
Speaker 5: where the our home devices goes and collects diagnostic data
Speaker 5: from their you know, speakers, we're all like.
Speaker 4: That's germs, no privacy, you know.
Speaker 5: But when we need it, we're like, hey, we need
Speaker 5: the analytics.
Speaker 4: We need to know if it's working or not. You know.
Speaker 5: It's like, yeah, I just throwing that out there, there's
Speaker 5: no point, but like.
Speaker 4: It's just funny.
Speaker 2: I could see it though, because I think it depends
Speaker 2: on what you're building. Like for a wine app, it
Speaker 2: seems pretty inoculates and whatever, But if you're building like
Speaker 2: a medical application, chatbat or a financial one, then I
Speaker 2: think all of a sudden, you're really going to care
Speaker 2: about what exactly is getting stored and how this data
Speaker 2: is getting used. Your users are going to care about
Speaker 2: that too, for sure.
Speaker 3: Exactly that's quite true, considering that you could have your
Speaker 3: dialogue fl application become very big. So each dialogue flu
Speaker 3: application can contain multiple intents. It could go as much
Speaker 3: as over one hundred intents, so it'd be very very useful.
Speaker 3: Genetics pitch is very useful in such scenarios to know
Speaker 3: what is being used, when it's being used, and how
Speaker 3: it's being used. So with that you could know these
Speaker 3: are the intents that are being used by users and
Speaker 3: this I won't not be in used because in most
Speaker 3: cases you might not really have like a brand pitch
Speaker 3: to teach use us how to make use of your application.
Speaker 3: So through those four back sentences you have the opportunity
Speaker 3: to teach the user. And whenever it's not been much,
Speaker 3: you could use analytics to know that disons are quite
Speaker 3: difficult for users to know how to use, and you
Speaker 3: could redesign everything.
Speaker 1: Yeah, do you know when dialogue flow is taking in
Speaker 1: user queries, is it actually putting those back into its
Speaker 1: own models to get better at hopefully answering those questions
Speaker 1: or is it just like it goes to your application,
Speaker 1: it tries to figure out what you're looking for. And
Speaker 1: then that's where it ends.
Speaker 3: Do you know I would assume yes, because I would
Speaker 3: assume that over time it gets better and better as
Speaker 3: people use applications. But everything relies basically on your own
Speaker 3: provided training. So the more training models you provide, the
Speaker 3: more training you do, the more intent you have to
Speaker 3: cover EDU cases, the better it gets.
Speaker 1: Makes sense.
Speaker 5: So the kind of hard to steer this back to
Speaker 5: react for a second. So again with the mob backs things.
Speaker 5: So I'm sure we have a lot of listeners who
Speaker 5: are like reducts forever.
Speaker 4: You know that kind of thing, because.
Speaker 5: React reducts, and so can you give me a little
Speaker 5: bit more about like why the choice of mobacks in
Speaker 5: this case, what the advantages are in mobecks on this case,
Speaker 5: that kind of thing, so it gives some sense of
Speaker 5: why you chose it personally.
Speaker 3: For me, I choose mobis because of the learning cove
Speaker 3: that we all know. Everybody complains about reducts being quite
Speaker 3: hard to understand. And I was coming from a Java background.
Speaker 3: I was learning op at school and when I picked
Speaker 3: up more biks, I realized, Hey, could I apply object
Speaker 3: here that programming here? So I moved from mobis.
Speaker 5: It's funny how many can people complain about reducts, Oh
Speaker 5: my god, they're still boiler and then you know, like
Speaker 5: they still use it, but you know, page to your point, Yeah,
Speaker 5: Redux toolkit is a great way to reduce that amount
Speaker 5: of boiler plate.
Speaker 3: For sure.
Speaker 4: Killed the conversation on that one.
Speaker 2: No, well, we did continue on the path of the
Speaker 2: React angle for it. I am curious how you captured inputs,
Speaker 2: Like do you have like a little like chat dialogue
Speaker 2: thing that people are working with or are you giving
Speaker 2: like microphone access in your app? How are you sending
Speaker 2: data into the dialogue for.
Speaker 3: So start them from dialogue. Dialogue Flow supports both text
Speaker 3: and audio, so with the Express application in between both
Speaker 3: of them, the text first forgets sent to the express application,
Speaker 3: which in ton sends it to to dialogue flu so
Speaker 3: I was basically capturing both texts and audio. So using
Speaker 3: the audio, I was using the browser api for recording
Speaker 3: users audio, then I would send that to the express
Speaker 3: application and also sends it to to dialogue to so
Speaker 3: there was this Express application in between both of them,
Speaker 3: and for the audio recording, I was basically using the
Speaker 3: browser api. I didn't really do anything, what's for sure
Speaker 3: about it?
Speaker 2: It's so kind of cool that you can send audio
Speaker 2: because then presumably you're not doing speech recognition on your side,
Speaker 2: and money Google handle all of that as well, which
Speaker 2: is kind of slick exactly.
Speaker 3: It was one of the beautiful points of of the
Speaker 3: dialogue flow. You don't have to extract that text yourself.
Speaker 3: It automatically excepts distract the text for you and processes
Speaker 3: it then gives you back a response based on your text.
Speaker 3: It's also it's also important to note that you can
Speaker 3: also use dialogue flow A in a regular histem and application.
Speaker 3: So it gives you this sort of I frame which
Speaker 3: you can inject into a raw histem of file. So
Speaker 3: if you do not have like an spe application, you
Speaker 3: could just inject in an I frame.
Speaker 2: Yes, so if it's an I fram is it building
Speaker 2: in that situation? Is it building the UI for you
Speaker 2: as well?
Speaker 3: Yeah? So it's renders the dialogue flow agents within the
Speaker 3: I frame. Although it's not really very customizable because people
Speaker 3: get to see the dialogue flow layout. But if you
Speaker 3: want to do more customization, you could then go ahead
Speaker 3: to build an SPA. But a very basic level, you
Speaker 3: have the I frame, which you could just add the
Speaker 3: culture totemo file and when the request is made, it
Speaker 3: that lodes the dialog fluw agents and shows it up.
Speaker 4: Makes sense. I mean, if you want just an off
Speaker 4: the shelf solution to do customer engagement like a you know,
Speaker 4: hey click click on this help button and you'll get
Speaker 4: some help, you know, just drop an I frame in
Speaker 4: your code and the ware you go.
Speaker 1: Yeah, I can see that being extremely useful. First, like
Speaker 1: you said, small businesses who are just trying to get
Speaker 1: a website up and running so they can do whatever
Speaker 1: is that they actually want to focus on.
Speaker 4: And will be really good. Is like drag and drop
Speaker 4: Tuilio integration.
Speaker 5: So I can actually just like SMS this chatbot and
Speaker 5: be like, hey, I need more Pinot in my life,
Speaker 5: you know, and case shows up at home.
Speaker 4: There you go.
Speaker 2: Actually, that's a decent question. Are there other integrations that
Speaker 2: you can do, like because I know some of these
Speaker 2: chatbots will let you go to like Facebook Messenger and
Speaker 2: maybe SMS. I Are there other deployment options that it
Speaker 2: gives you.
Speaker 3: Yeah, you have Facebook on Facebook WhatsApp and I frame
Speaker 3: then also using the API, so you could deploy direct
Speaker 3: to a Facebook Messenger and it gets shown up.
Speaker 2: Yeah, because I could see, like Facebook Messenger is an
Speaker 2: interesting one because I could see like it being nice
Speaker 2: for a small business to just have something to just
Speaker 2: monitor their the random people that message their business and
Speaker 2: just try to point them in the right direction.
Speaker 3: Yeah, those are full small skill. You could the same way.
Speaker 3: I think on Messenger. We have quite a lot of
Speaker 3: Chadbottom Messenger, so you could just add us to that. Well.
Speaker 3: One of the deployment which I find very fascinating the
Speaker 3: Google Assistant because I got to try out the Google
Speaker 3: Assistant console while deploying this and it's quite beautiful. We
Speaker 3: have a lot of andloid devices out the market, so
Speaker 3: after doing this, you could just deploy straight up and
Speaker 3: that gives you access to quite a very large customer base.
Speaker 2: Do you need to so what would that look like
Speaker 2: from an installation? And is it like a customer extension?
Speaker 2: Like what would the user need to do to like
Speaker 2: you're building the next great wine importium, just a giant
Speaker 2: wine website. What do users have to do to get
Speaker 2: your wine extension into Google Assistant? And then with a
Speaker 2: follow up once they do, like what words do they
Speaker 2: have to say to Google to actually trigger you? Because
Speaker 2: presumably Google needs some indicator that it's talking to your
Speaker 2: service and people aren't just saying okay, give me directions
Speaker 2: to the store or whatever.
Speaker 3: So basically you start with using the chat assistant name.
Speaker 3: So each and every chat assistant has a name for
Speaker 3: the one within the application. I think I called it Zarah,
Speaker 3: so you could start by saying Hello, Sarah. Then it
Speaker 3: gives you its own greet in response, and you give
Speaker 3: it an intent and a response so that guys the chat.
Speaker 2: So then presumably Google or Android then takes care of
Speaker 2: detecting like whatever wakeword or whatever command that triggers your
Speaker 2: chat service so that it knows to like funnel these
Speaker 2: requests to you.
Speaker 3: Yeah, it starts with the name you mentioned, the name
Speaker 3: that kind of the conversation on that log flu you
Speaker 3: have the opportunity to create each is for you.
Speaker 4: Well, if I was gonna pick a wake word to be.
Speaker 6: Like wine more wine, that's yes, they would be why
Speaker 6: exactly you could even give it that name?
Speaker 4: That's great.
Speaker 6: Uh.
Speaker 5: Yeah, I gotta say kudos to you for picking a
Speaker 5: an absolutely fantastic topic. I know you do a lot
Speaker 5: of technical writing and I usually pick things like Pokemon
Speaker 5: and things like that. I will definitely have to think
Speaker 5: about picking wine in the future. It's a fantastic thing
Speaker 5: to talk about.
Speaker 3: Yeah, funny, funny enough. I don't drink wine.
Speaker 4: I don't either, but it's a great topic of conversation.
Speaker 1: It could be very applicable to actual businesses.
Speaker 7: Oh yeah, exactly, small sto retail business.
Speaker 4: Yeah, exactly, totally.
Speaker 1: Well, Victory, it has been a pleasure talking to you.
Speaker 1: If people want to get in touch with you, learn more,
Speaker 1: ask you any questions about any of this or anything else,
Speaker 1: where can they find you?
Speaker 3: You could find me on tweeta LinkedIn, you could send
Speaker 3: me an email, reach out to me. I'm basically everywhere.
Speaker 3: I'm glad to it didn't develop advocas you do. So yeah,
Speaker 3: I'm an advocate for a lot of technologies, so you
Speaker 3: could reach out to me any day.
Speaker 1: Excellent. We will link to all of those in the
Speaker 1: show notes. And now it is time to move into
Speaker 1: our picks for the week. So Jack, would you like
Speaker 1: to start us off with a pick?
Speaker 4: Sure?
Speaker 5: This week's pick for me is Resident Evil eight Village.
Speaker 5: I'm playing this with my teenage daughter and it is hilarious.
Speaker 5: When you know, I think we ran into this big
Speaker 5: mutant baby thing of course classic resident evil and she
Speaker 5: was you know, with the germs all dark and she's
Speaker 5: is priceless, absolutely priceless. So a great fun thing. Obviously
Speaker 5: not appropriate for everyone, but you know, for the right
Speaker 5: right age range, it is hilariously fun.
Speaker 1: Exactly for the right the right audience, it's great. Yes, TJ,
Speaker 1: would you like to give us a pick?
Speaker 4: So I'm going to pick a Biday which is a
Speaker 4: sort of a fun pick.
Speaker 2: But we are redoing our bathroom and we decided we
Speaker 2: went on a trip to Europe a few a few
Speaker 2: years ago and our hotel room had a bidet, which
Speaker 2: for I guess for our American visitors. Bidats are not
Speaker 2: common in the US at all, but they're very common
Speaker 2: in Europe, and we had one in our hotel room.
Speaker 2: We liked it, and we were redoing our bathroom, so
Speaker 2: we're like why not And I'm instantly loving the decision.
Speaker 2: So we have a day from Total. They it's Japanese company.
Speaker 2: They make a lot of bidats that they're like add
Speaker 2: ons to toilets too, so you don't have to get
Speaker 2: like a custom made they make them the bolt onto
Speaker 2: existing toilets. So I'll link to one that we have,
Speaker 2: but really anything from them should be should be good.
Speaker 2: I'm enjoying it nice.
Speaker 1: Yeah, my husband grew up with one because he grew
Speaker 1: up outside of the US as well, and he got
Speaker 1: one recently for our toilet, well not recently, a couple
Speaker 1: of years ago. Now loves that thing. He is so
Speaker 1: so much a fan, and Toto is like the best.
Speaker 1: They're like the top brand.
Speaker 2: Oh yeah, you'll pay, You'll pay a little bit of
Speaker 2: extra money for it, but I think it's worth it.
Speaker 4: My wife is.
Speaker 5: Similar sort of thing, just absolutely loves the day.
Speaker 3: Cool.
Speaker 1: So my pick for this week will be in the
Speaker 1: same video game line as you, Jack. I have been
Speaker 1: playing Mario Kart recently and yeah, for the end of
Speaker 1: Switch and it is so much fun. My husband and
Speaker 1: I will play it after work sometimes and it's just
Speaker 1: it's hours of enjoyment.
Speaker 4: So yeah, Michelle and Rainbow Road just.
Speaker 3: Not there. I was winning.
Speaker 1: That's a lot of what you hear.
Speaker 4: Yes, that's an awesome game.
Speaker 1: Yeah, it's great, especially when you have a couple of players.
Speaker 1: But yeah, we played that when we visited his brother
Speaker 1: out in San Diego a few like a month and
Speaker 1: a half ago, who played it with him and his
Speaker 1: girlfriend and then had to end up in getting our own.
Speaker 5: I can't wait until Mario party comes out for the switch.
Speaker 5: That's gonna be awesome. Some more sort of thing.
Speaker 3: Absolutely.
Speaker 1: Yeah, So Victory, do you have a pick that you'd
Speaker 1: like to recommend to us this week?
Speaker 3: My peak is not something fun, so I noticed everyone's
Speaker 3: is quite it's quite fun, but my mine is service
Speaker 3: on Ida bluest and it's called could deploy and so
Speaker 3: what could deploy? Does it auto meets your deployment? And
Speaker 3: I think this is a lifesaver and a pink saver
Speaker 3: for me. So I don't know how what does it
Speaker 3: magically deploys changes to your application running within compute services
Speaker 3: on AWS than going to manually redeploy a lot of
Speaker 3: compute services you could set up could deploy and then
Speaker 3: each change it would redeploy it for you. And that's
Speaker 3: something that thank you. Yeah, TG has helped me with it.
Speaker 3: Do you have experience work could deploy?
Speaker 2: No, I'm just really good at googling things and putting
Speaker 2: them in the chat so they end up in a show.
Speaker 4: Not fast.
Speaker 3: That's been act could deploy to everyone. It's it's a
Speaker 3: life saver and.
Speaker 2: I also say, hey, we're engineers, don't judge. We might
Speaker 2: find aws services fun. I mean, yeah, a good c
Speaker 2: ICD flow absolutely, yeah.
Speaker 3: Especially when it saves you the type of employments.
Speaker 4: Yeah, exactly.
Speaker 3: Absolutely.
Speaker 5: It can be a big cost though. I will say,
Speaker 5: like those costs can creep up on you. You know,
Speaker 5: if you end up like putting doing a lot of
Speaker 5: bills where it's like the c c D flow is.
Speaker 4: Link checking for you. Don't don't do that link check
Speaker 4: before you push.
Speaker 7: And c I c D things that ends up as
Speaker 7: technical depth. It's not my money as.
Speaker 1: Long as the company is paying for it.
Speaker 3: Yeah, exactly, they're making money from me.
Speaker 4: That's true. That's true. In comparison to your career per
Speaker 4: hour cost, it is nothing. I just feel bad.
Speaker 3: I do well.
Speaker 1: Awesome, those sound like fantastic picks and victory. Thank you
Speaker 1: again so much for joining us.
Speaker 3: Hey, thank you, Peach.
Speaker 4: It was wonderful having you.
Speaker 3: I think I look forward to doing this another time
Speaker 3: with my video.
Speaker 1: On absolutely next time video for sure, and I better internet.
Speaker 3: Thank you.
Speaker 1: Right, all right, we will see everybody on the next
Speaker 1: episode of React Round Up.
Speaker 4: Bye everybody,