What Is the Relationship Really?
Let's compare a bit — it may be funny, but let's do it.
Testing Relations in Lesan
On the What Is the Relationship Really? page we saw how relations behave in Lesan and how they compare to SQL and NoSQL. Now let's see it in action. This page walks you through a full hands-on test of the relationship engine using the Playground's E2E feature, based on the country, city, and user models.
Receiving Data: The Challenge
One of the biggest challenges we faced when implementing data retrieval in Lesan was a seemingly simple customer request: fetch a schema's dependencies with more than two levels of penetration in depth — a country with its provinces, and each province with its cities.
Lesan's Solution: Communicating Between Server & Client
The idea of connecting client-side applications to the backend in Lesan is inspired by GraphQL — but we tried to make the connection simpler and more practical to solve the problems described on the previous page.
Why NoSQL?
As you have seen on the previous page, data duplication reduces the number of multiple requests to the database, which affects both the speed of receiving data and the way SSG content is created. In addition, the number of ways to receive embedded data in these databases — especially MongoDB's aggregations — makes managing and filtering this data easier.
Queuing Data Changes
On the previous page we said that with repeated data updates, we have created a process to send data to smaller parts for updates in different time periods. This page explains that process — the Query Queue (QQ) — and an alternative worth knowing about: in-memory databases.