The latest train of thought in AIRport development is enabling discrete data sharing between Organizations. Organizations could range in type from a family to a governmental agency.
...

For a while now there has been a plan to run Sapoto.net and Votecube.com as the first Apps on Turbase. Sapoto.net is a social support network and Votecube is a public opinion poll record. These are very important projects but there is something even more important that recent events brought up.
...

With the current solution of copying records between Repositories there would still be multiple records in the database for the same exact record - one per repository that has a copy of that record. This is hard to maintain and comes with a performance penalty.
...

Storage of Repository data is pretty straight forward - every entry in its transaction log can be a separate file, timestamped at the time of its creation (preferably the proven time of persistence of the transaction log entry). But the retrieval of data is a lot more complex.
...

This morning I finally arrived at the idea of how to efficiently and effectively ensure repository Atomicity at query time.
...

As it stands right now, repositories are linked via @ManyToOne relationships. This is easy to do since the Many side of the relationship contains the foreign key into the parent table. However, as I've been writing the first internally provided DApps I realized that there is a need for linking from the @OneToMany side as well. And the proposed solution opens up the possibility of a Graph database implementation on top of AIRport.
...

I've recently learned that some organizations value working with raw SQL. Keeping your queries in raw SQL makes sense and I am starting to design an additional, SQL-first ORM for AIRport.
...

AIRport has a very useful feature: all objects passed into @Api() methods get updated with the latest state (when they are returned back to the Client). This is very useful - the Client doesn't have to re-query the object to get the latest state: less code to write and maintain (and faster applications). However there are cases where objects in the passed in object graph must be overwritten.
...

As I'm using AIRport APIs I'm realizing that the existing records passed into AIRport APIs need to be verified as such. This is leading me to finalize the Id API for AIRport.
...

In 2015 I wrote a Family Organizer and realized that families would have to trust a company with their plans. I started to write a relational adapter for Google Docs to store data in personal accounts. Overtime it evolved into AIRport . I have been thinking that AIRport can also work in centralized environments and seamlessly serve both centralized and decentralized data. Now I'm realizing how siloed, centralized databases can join a fine-grained, privacy oriented network of virtually decentralized databases. ...

At the core of AIRport are Autonomous Interdependent Repositories. Repositories contain all of the records necessary for work on a particular unit, such as a UI page while storing everything in a relational database via a virtual Repository layer.
...

AIRport Id scheme has an optimization for local storage of globally unique Ids. It is a limiting factor that is leading to a new way of doing things.
...

One thing I'm starting to think about is adoption of AIRport. It will certainly be useful for building production applications but it's query syntax lacks a bit when it comes to quickly cranking out prototypes.
...

Working with raw AIRport ids is cumbersome. The reason for that is the fact that an Id of an entity is spread across 3 different entities:
...

A key factor in Turbase (and thus AIRport) adoption will be the ease of writing applications. One key feature that needs to be done in a developer friendly way is Dependency Injection.
...

A key feature of AIRport framework is the ability of applications to interoperate. This is possible because of two reasons:
...

As the name states, Autonomous Interdependent Repositories are meant to be interdependent. This basically means that records in one repository can have columns with ids pointing to records in other repositories. In itself its a simple concept however it presents a number of technical issues when actually implemented.
...

Recently I've have arrived at a breakthough in thinking about how Highway can be implemented in a strait forward and simple way, provided that some assumptions are kept about underlying data usage.
...

Recently I got the inital implementation of application isolates working (in browser only, without pulling application code from remote location) and as part of that did a pass on API implementations.
...

Unlike JPA/Hibernate, AIRport entity management is sessionless. The way it accomplishes change detection is via original values tracking in a hidden object property. Recently I've been debugging Insert vs Update detection and realized that everything is easier with Ids that are generated. If the Id is present in the input it cannot be an Insert. That got me thinking - should all entities be forced to have generated Ids?
...

Schema migrations are hard in general. In AIRport/Turbase schema migrations are even harder for a number of reasons:
...

In AIRport any given virtual repository can be in multiple states at the same time. This is because multiple users can be using the same virtual repository. Since they may be using a repository while being offline, the repository will get out of sync with the rest of the devices that have it. Hence, to keep track of that Turbase version controls all of virtual repositories using a simple Directed Acyclical Graph. ...

For a while now AIRport has been the brand for the AIR technology. And also for quite some time we've been dicussing building an adverisement engine on top of AIRport to generate revenue that can be shared with Apps and users. Now finally I've come up with a good enough of a brand for the actual App that will be installed on phones and other devices - Turbase. ...

I've now come to a full realization of what logic in isloates mean - locally-run vetted components. This trully changes the way AIRport applications can be written. Apps are no longer required to maintain expensive (to most people on the planet) server side components. Also that allows for a degree of independent developer specialization that is already standard among most professional programmers and UI designers. ...

Internally Airport used "on the stack", token based dependency injection to allow for seamless framework upgrades on each device. However this type of injection is non-standard and can throw schema developers off (as something unfamiliar and therefore unnatural). With introduction of isolates adding more tranditional constructor based dependency injection scheme becomes possible. ...

The next step after code execution isolates and schema upgrade strategy is defining exactly how schemas will be installed and how they will run. Here is my first (detailed) take on it. ...

Naturally occurring
Another issue that has been bugging me for quite some time is how exactly schema upgrades will work. My initial thoughts have been about building a framework that will enforce backwards compatibility for schemas. Switching to natural DAO logic lead me to re-think the approach and make it more natural, give more freedom to schema developers and define schema interoperability rules.
...

The solution to natural DAO logic
For quite a while now I've been dreading having to write Firebase-like rules for mutation logic. I have a number of reservations about writing a custom syntax engine:
...

4 month have passed since my last blog post and I didn't have any time to devote to coding. Hence I'm open sourcing the projects "as is" (with a bit of additional documentation).
...

I haven't head as much time as I have hoped to develop Highway last year. So during the beginning of this year I'm focusing on developing a prototype product based on Highway and developing Highway itself in the process.
...

Ability to support transactions has always been important with AIR but the API has been in flux until now. Here is the description of the final version of the API.
...

Quite a bit of code written as part of the Airport effort really has little to do with the concept of Autonomous Interdependent Repositories (AIR).
Here is a list core, already working features...

Since the beginning of the Airport project the question of how to share data was outstanding.  Eventually I started the automated-gateway-transit library to act as a gateway between airport instances...

Initial designs behind Airport called for an all-in-browser framework. However after I did enough research this proved to be impractical for the following reasons...

Just like with persistence operations it is possible to process query operations at build time, while keeping all of the benefits of TypeScript type checking and auto-completion

The first (to be) Airport application Votecube was originally written with Firestore as the backend. While it's own central backend will be moved from Firebase to another solution, writing it with that technology exposed me to its Security Rules ...

The relevant part of the first Airport application Votecube has been finished. The application itself is still a prototype (currently running on Firebase) and is yet to get it's long term back-end. But the font end is finished! ...