Reliable Store Management
When we began porting a aging Objective-C/Swift, four-year-old codebase to cross-platform Flutter, the Greenbits team envisioned a more sensible way of managing data. The application had to function while it was offline - regardless of API accessibility or connectivity. The tired version: check for internet connectivity and use one data store (REST) versus another (SQLite) depending on the connection. The wired version: only access offline data.
Brick is an extensible query interface for Dart applications. It's an all-in-one solution responsible for representing business data in the application, regardless of where your data comes from. Using Brick, developers can focus on implementing the application, without concern for where the data lives.
Brushing Complexity Under the Rug
Brick tries to do a lot at once, and under the hood is not a simple engine. Based on the request, the availability of data, and the freshness of the data, Brick may pull from three or more different providers (e.g. from memory, from SQLite, from REST).
But the implementing developer doesn't need to care. The system was designed to be used as a single entrypoint: Brick determines which provider to accept. The focus is returned to implementing the right filter, similar to Rails or Ecto.
Humanized, Automatic Migrations
Instead of complex, handwritten SQL:
Migrations are generated automatically. If a new field is added to a model, an insert migration is generated. This just make sense: a record of the old schema exists and it can be compared to the model definition. No rails g migration required.
Idiomatic Querying
Similarly, the querying interface is designed to reduce friction in a legible way. The syntax is designed to reflect a natural speech pattern while still being familiar in a Dart ecosystem. Without reflections available in Flutter, the syntax won't reach the idiomatic level of Rails, but it comes close. Instead of:
Open Source
Once the team felt Brick was in a stable place and beneficial to the community, extensive documentation was written. Every package had an example, and a gratuitous README to flesh out documentation for anyone seeking to build their own provider, to extend Brick, or to simply use it. On launch, several resources were published:
- A Flutter By Example tutorial
- A Flutter Community post
- A video covering the basics
- A video covering the architecture
And it's still an ongoing work in progress. I've had discussions from London to Minsk with developers experimenting with Brick and plenty more active on Github Issues