X
X
Xip
Search…
Basics
A quick primer of the various pieces that comprise Xip Kit.

Anatomy of a Xip Bot

A Xip bot has two primary processes: a web server, and a background job processer. If the messaging platform being used supports it, Xip will push a message to a queue where a reply will be constructured by a background job. This allows you to easily scale your Xip bot across many threads and processes.

Data Store

Xip requires Redis. Redis is used for session storage as well as the queue for background jobs. You can access the Redis store yourself via the global variable: $redis. You can use it as your primary data store if you are building a simple bot, but you'll likely want to use a SQL or NoSQL database for more complex bots.

Environments

Xip bots can be booted into three environment types: development, testing, production. By default, if an environment is not specified via the XIP_ENV environment variable, the development environment will be used. The testing environment is automatically used when running your specs.

ActiveSupport

Xip automatically includes active_support. So if you're used to using certain core extensions in Ruby on Rails, you can continue to use them in your Xip bots!

Lifecycle of a Message

This is just a brief outline of the lifecycle of a message to help you understand how Xip processes messages. For more detailed information that you can use to build your own message platform components, check out those docs.
    1.
    A message is received by the web server.
    2.
    If the message platform supports it, the message is backgrounded to be processed by a background job. If the message platform does not support it (Alexa Skill or Voice), the message is processed inline by the web server process.
    3.
    Xip uses the respective message platform component to normalize the message into a standard format.
    4.
    Xip calls the route method in BotController. If a session exists for the user, they are routed to their current state. If a session does not exist, by default the route method will route the user to the HellosController#say_hello method.
    5.
    The controller action will either do nothing, step to another state, update the session, or generate a reply. In the latter case, the reply will be delivered via the message platform component.

Directory Structure

When you use the generator xip new to instantiate a new bot, here is the directory structure that will be created:
1
├── Gemfile
2
├── Procfile.dev
3
├── README.md
4
├── Rakefile
5
├── bot
6
│   ├── controllers
7
│   │   ├── bot_controller.rb
8
│   │   ├── catch_alls_controller.rb
9
│   │   ├── concerns
10
│   │   ├── goodbyes_controller.rb
11
│   │   ├── hellos_controller.rb
12
│   │   ├── interrupts_controller.rb
13
│   │   └── unrecognized_messages_controller.rb
14
│   ├── helpers
15
│   │   └── bot_helper.rb
16
│   ├── models
17
│   │   ├── bot_record.rb
18
│   │   └── concerns
19
│   └── replies
20
│   ├── catch_alls
21
│   │   └── level1.yml
22
│   ├── goodbyes
23
│   │   └── say_goodbye.yml
24
│   └── hellos
25
│   └── say_hello.yml
26
├── config
27
│   ├── boot.rb
28
│   ├── database.yml
29
│   ├── environment.rb
30
│   ├── flow_map.rb
31
│   ├── initializers
32
│   │   ├── autoload.rb
33
│   │   └── inflections.rb
34
│   ├── puma.rb
35
│   ├── services.yml
36
│   └── sidekiq.yml
37
├── config.ru
38
└── db
39
└── seeds.rb
Copied!
Last modified 9mo ago