Under the hood

Join emulation works by transparently analyzing the requests that are performed by the frontend and customer API in your Back-end, and translating them into multiple requests to the relevant data sources. For instance, assuming that:

you defined a jointure between 2 Collections: books and authors
both Collections are hosted on different SQL databases
you display the books list in your back-office

-- The frontend needs the result of that query to display the 'list view'
-- which cannot be performed, because books and authors are on different databases
SELECT books.title, authors.firstName, authors.lastName
FROM books
INNER JOIN authors ON authors.id = books.id
WHERE books.title LIKE 'Found%'

The request will be transparently split and its result merged to produce the same output as if the original query was run.

-- Step 1: Query database containing books (including foreign key)
SELECT books.title, books.authorId FROM books WHERE books.title LIKE 'Found%';

> | title      | authorId |
> | Foundation | 83948934 |

-- Step 2: Query database containing authors (including pk)
SELECT authors.id, authors.firstName, authors.lastName FROM authors WHERE id IN (83948934);
> | id       | firstName | lastName |
> | 83948934 | Isaac     | Asimov   |

-- Step 3: Merge results (using books.authorId === authors.id)
> | title      | authorId | firstName | lastName |
> | Foundation | 83948934 | Isaac     | Asimov   |

Automatic query splitting handles complex cross-datasource queries, however not all queries are created equal.In this simple example, it is a straightforward three-step process, but the feature can come at the cost of performance on more complex queries.

Computed foreign keys Workflows

⌘I

Overview

Connect

Process

Build

Execute

Collaborate

Manage

Embed

Control

Project Settings