Category-defining iPaaS and PaaS hybrid solution

10x easier integrations

Developing applications and services with Qworum is 10x easier than with other technologies such as REST, because:

• The API caller does not need to authenticate the end-user; each API endpoint takes care of authenticating the user itself if needed.
• The API caller does not need to obtain an API key, as Qworum API calls are very similar to hyperlinks across websites, which are naturally permissionless.
• Qworum APIs bring their own UIs, so the UI-related production costs are greatly reduced for the API caller.

A built-in service orchestration engine

Without Qworum, even simple reusable user flows are difficult to implement for web applications, and the main reason for this is the fact that the web was initially conceived as a platform for content, not applications.

Here is an example of how hard it is to implement a simple user dialog on the web without Qworum.

In a web application, if the user is trying to access his/her account page at /account but hasn't signed in yet, then the user is typically redirected to a path similar to /login?returnTo=/account. But even for a simple login dialog, there are several questions that the current web platform cannot address satisfactorily:

• What to do when the login does not succeed? Do we redirect to a fixed path such as / (this is the widely used option) or do we specify different paths for different error conditions, such as in /login/?returnTo=/account&returnToIfCancelled=/login-cancelled-by-user&returnToIfTooManyBadPasswords=/suspected-account-hijack ?
• If the dialog is made of several pages, then do we have to copy the dialog parameters from page to page, in addition to the current dialog state, such as in /login/page-2?username=xyz&returnTo=/account&returnToIfCancelled=/login-cancelled-by-user&returnToIfTooManyBadPasswords=/suspected-account-hijack ? This becomes very unwieldy very quickly.
• What if the login dialog has to make use of another user dialog such as "Sign in with OpenID Connect" ? Does the login dialog have to send all its parameters to the OIDC dialog, such as in /oidc/?returnTo=/login/oidc-result%3FreturnTo%3D%2Faccount%26amp%3BreturnToIfCancelled%3D%2Flogin-cancelled-by-user%26amp%3BreturnToIfTooManyBadPasswords%3D%2Fsuspected-account-hijack ? (Hint: yes it does.)

Qworum elegantly solves these issues by defining a domain-specific language called the Qworum script, which is used for orchestrating calls to Qworum API endpoints. In Qworum-based applications:

• User dialogs (i.e. Qworum API endpoints) don't need to know how the application will continue once the dialog has finished running: this is the responsibility of the dialog's caller. And as a result, the dialog does not need to receive any parameters related to return paths. In that, Qworum is very similar to modern runtime environments where a function or an object's method is not concerned about what happens after it has finished executing.
• URLs only need to contain paths (and possibly fragments), with the dialog parameters conveniently tucked away in the Qworum session states of browser tabs, and available for reading/writing from Qworum scripts as well as from in-page JavaScript.

Support for complex service dependency graphs

The simple fact of the matter is, without Qworum, the integration of interactive processes involving deep dependencies between applications and services is a technical impossibility.

For example, in the architecture outlined below, how does Application 1 authenticate the end-user for Service 2 and Service 3?

In real-world settings such multi-tier integration scenarios will appear more and more often as new specialised SaaS offerings come online. Here is a plausible example:

• Application 1: A project management application such as Airtable, Monday.com, Zoho or Jira.
• Service 2: An artifact management service such as Confluence, Basecamp or SharePoint.
• Service 3: A messaging service such as Slack, Matrix or Microsoft Teams.

Let's see what would happen without Qworum:

• Authenticating the user for Service 2 is possible (because Application 1 knows that Service 2 must be used), although authenticating the user for a 3rd-party service is an overhead that is best avoided. But even for Service 2 there is already a security problem, because now Application 1 can now impersonate the end-user on Service 2!
• It is fair to say that authenticating the user for Service 3 is a technical impossibility. Indeed, Application 1 doesn't even know that Service 2 is using Service 3 behind the scenes, not to mention all the conversation-tunnelling that must happen between the authenticating service and the end-user.

For these reasons, today's composable architectures such as the MACH architecture only support one-level deep dependency trees, and they put on the main client application the burden of building all the UIs for all involved services.

With Qworum all these limitations are removed:

• Each applications/service has direct access to the end-user and so can take care of authenticating their own end-users.
• Qworum preserves the confidentiality of user authentication information for all involved services.
• Qworum makes user-authentication a non-issue for all possible dependency-graph topologies.

What are microservices architectures?

Microservices architectures enable rapid software delivery by allowing different parts of a software system to be developed, deployed and updated in parallel by different teams within an organization and also across organizations.

Microservices architectures organise developer teams around vertical slices of software systems rather than the horizontal UI, business logic, and data layers. In order words, microservice teams are responsible for all of these 3 layers within the boundaries of a particular slice.

What is wrong with monolithic user interfaces?

For microservices architectures, having a monolithic component at the UI layer represents a bottleneck for the software development lifecycle, because the team responsible for the UI monolith cannot scale with the number of microservices.

Are micro frontends the right solution?

Today, the only solution that software developers have at their disposal for breaking UI monoliths into smaller parts involves micro frontends.

Micro frontends are UI components that are plugged into dashboard-style web pages for building web applications. In this case web applications become simple containers for micro frontends.

Micro frontends are implemented using various technologies such as React.js components, web components or iframes, none of which are specific to microservices architectures.

Besides being only suitable for dashboard-style applications, other limiting factors for micro frontends include:

• Bounding context — Micro-frontend solutions are typically only usable within a particular context rather than being universally applicable. This limiting context can be a particular organization (which precludes cross-organization applications), a particular web application, or a particular frontend framework such as React.js or Angular for example.
• Data exchange — The data exchange mechanism between a micro-frontend and its container is ad hoc at best. For example, if a micro-frontend is implemented as a React.js component, then the micro-frontend can use React.js's built-in mechanism for receiving data from its container. On the other hand, how and if a React.js component can return a result to its container is an implementation detail that needs to be resolved on a case by case basis. This is because micro frontends are conceived as UI components rather than full-blown services.
• Nesting — Micro frontends typically cannot be nested beyond 1 or 2 levels, because the allocated screen area becomes significantly smaller with each nesting level.

Interactive microservices with Qworum

Qworum is a UI technology that was made specifically for microservices architectures. In contrast to micro frontends, which are parts of web pages, Qworum takes the web-API approach to user interaction.

In effect, Qworum defines a new type of web API where each end-point can receive data, interact with the end-user if needed, and then return a result. Note that Qworum services are not components embedded in web pages. Rather, they offer full-page UIs to end-users.

Also, in contrast to micro-frontend solutions where there are two types of entities (micro frontends and container applications), with Qworum everything is a Qworum service, including applications.

So, while Qworum complements micro frontends rather than making them obsolete, by the same token Qworum does not have many of the limitations that micro frontends are burdened with:

• Range of usage scenarios — Qworum is a web-scale microservices platform that is usable both within organizations and across organizations. Qworum is also independent from any particular application or web framework.
• Data exchange — Qworum defines a standard mechanism for exchanging data between Qworum services and their callers. This obviates the need for developing ad hoc data exchange solutions that are specific to a given application, framework or organization.
• Nesting — Qworum allows for unbounded nesting levels.