Frequently Asked Questions

See the following list for answers to frequently asked questions about Ritc. As we are just starting, there are only a few questions. Come back again to see more. If you have a question that isn't covered, please post it on the form to the right.


Rule engine basics

Ritc is a type of rule engine that executes business rules - as written by you. Expressed elsewhere as "If this then that", Ritc is more like "When this then that outcome". That is, Ritc rules (and apps) are declarative, as opposed to procedural - ie. goals (nouns) vs processes (verbs). Conceptually, rules are at a higher level than the processing (code) that they employ.

Ritc rules have one or more triggers and one or more actions. Triggers are like conditions. Ritc triggers and actions make requests to REST APIs. Triggers use the responses to determine if the rule should fire or not. If the rule fires, the actions are then performed.

Why should I consider using rules as an alternative to writing code?

As described under Rule Engine Basics above, Ritc rules and apps operate at the declarative level, which is conceptually higher than the procedural level (ie. code). And so they align more naturally with how we think about the world, and especially how we think about change. ie. we first think about "what" before we think about "how".

Rules have a flexibilty that hard-coded logic doesn’t – a factor becoming more significant as the pace of change increases.

Rules are autonomous, and can be added or removed without breaking the application. This is generally not true of code. This essentially separates the definition and the implementation of the rule, making it understandable to non-technical people, and facilitates control by the business side of the organization.

How is Ritc different from other Saas rule engines?

Some of the main features of Ritc are:

  • Rules are easier to manage than code
  • Triggers and actions can access any defined REST API - without using SDKs
  • You can import Swagger files for immediate access to your REST APIs
  • You can build composable apps
  • Ritc apps and rules behave like - and can be treated like - microservices
  • Ritc can run in the cloud such as on Amazon Web Services, Digital Ocean, on premise, etc., and on microcontrollers such as Raspberry Pi, Beaglebone Black
  • Ritc can scale up to very large numbers of instances - using services such as AWS Lambda

You are recommended to watch the video introduction to Ritc. This should give you a good outline of the features that differentiate Ritc from other rule engines.

I am not a developer - can I use Ritc?

Ritc provides a Visual Rule Editor that runs in the browser, accessible from laptop, mobile, and tablet. Within minutes, developers and non-developers alike can build production-ready applications, integrating public and private microservices without writing code.

What's the big deal about composability?

Composability means that you can build your application out of components. The functionality of your application is therefore not located in only one big (monolithic) blob. This gives you flexibility in handling complexity. But in addition the loose coupling inherent in the Ritc architecture (and as applicable in general to a microservices architecture) also means that you do not break the application when you add, update, or remove components.

Why is the integration with Swagger significant?

Swagger (at swagger.io) is a tool by which you can create definition files for your REST APIs. Ritc allows you to import Swagger files and make them immediately available to Ritc triggers and actions. ie. you can create a rule that accesses your APIs within minutes! This enables rapid development of rules and applications.

In addition to enabling quick access to your private APIs, this also facilitates access to public APIs that have made Swagger files available.

How does Ritc not use SDKs?

Ritc has effectively generalized the kinds of things that SDKs do, placing the variables and differences in the Channel Functions instead. This makes it much more scalable, as well as reducing the clutter of multiple SDKs lying around that will surely become a management nightmare.

Contact form

* Indicates required field.