Learn high-level relationship between various system parts
Core library
We designed the system in such a manner that our core library is not tied to any framework or data storage system. Everything it requires from the system is hidden behind interfaces allowing the bootstrapping application to use the most appropriate implementation.
Only things that we rely on are the PHP Standard Recommendations and here is the list of the PSRs we currently use.
- PSR-4: Autoloader
- PSR-3: Logger Interface
- PSR-16: Common Interface for Caching Libraries. We use it to cache Google NLP requests (saves money) and in HTTP client element
- PSR-15 HTTP Server Request Handlers – for handling public and admin HTTP requests.
- PSR-17: HTTP Factories – allows hosted application to use a specific HTTP implementation
- PSR-18: HTTP Client
- PSR-11: Container interface
What we accomplished is that you can integrate and bootstrap Convoworks inside almost any PHP application without too much hassle and with the ability to reuse existing PSR compatible libraries you already might have in your PHP app.
Check the Convoworks Prototype application for the plain PHP implementation example.
What does the core library contain?
First of all, in the core library, we define all service component types (interfaces) and we have concrete service instance \Convo\CoreConvoServiceInstance which knows how to execute/run those components. The /Convo/Core/Workflow namespace defines basic component requirements: conversation elements, processors and request filters.
/Convo/Core/Intent namespace defines Convoworks intent model definition.
Service and component factory infrastructure is in /Convo/Core/Factory namespace. It defines how and where the service components are created. Note that component creation itself is again hidden and it happens in external packages..
Public HTTP endpoints are exposing Convoworks logic to be used by the real platform requests which are occurring while users invoke or use our service. They are placed in \Convo\Core\Adapters namespace. Each platform has its own public HTTP handlers.
Admin handlers are exposing full Admin REST API, for creating, updating, and publishing your conversation service. You can find them in the \Convo\Core\Admin namespace.
What is missing?
When we create a service, we have to save it somewhere. Core library defines just IServiceDataProvider interface so you have to provide concrete implementation. One example implementation is our test filesystem implementation (saves data in JSON files) that can be found in the /Convo/Data/Filesystem package.
Core library does not have its own users, own login or anything like that. Instead, it defines IAdminUserDataProvider interface which will provide us with users and the IAdminUser to represent minimal user data we are requiring in Convoworks.
As this is a library type of project, there is no GUI in it. We have admin API REST, but the GUI itself is something that has to be implemented by a hosted application.
There is nothing here to bootstrap the application. You have to provide your own configuration, index.php, loading dependencies, and initiating the required infrastructure (service and user data providers, HTTP factory …).
The implementing application should also take care of registering available Convoworks extension packages.
All packages at glance
Besides the core library, we have other packages which can be distinguished into these three main groups.
Core functionalities packages – libraries
- Convo/Core –
- Convo/Data/Fs – Filesystem data layer implementation. Service data storage, cache. Note that there are no users here.
- Convo/Guzzle – Guzzle HTTP client adapter
- Convo/Monolog – Monolog formatter for more informative log output
Component packages – Convoworks extensions
- Convo/Pckg/Core – Initial set of general purpose components
- Convo/Pckg/Gnlp – Google NLP result filters
- Convo/Pckg/Dialogflow – Google actions specific display components
- Convo/Pckg/Text – Plain text result filters
Full implementations – Applications
- Convoworks Prototype – Example implementation that uses file system data implementation, has its own users, admins. It is written in plain PHP. Should be used only for testing purposes
- ConvoWP is a full-blown Convoworks implementation for WordPress. It uses the WordPress database for service data, WordPress users and admins… It can run WordPress specific Convoworks components.
