What is an Active Record Pattern?
This is a class of design patterns that describe how one interacts with a database. A classic case of the Active Record or AR pattern is to let the entity object encapsulate the data itself. It also includes any data operations you can perform functioning only from within. This ensures that the developer knows where to go to both fetch data models and how to query for them. Creating a standard way to treat that data object the same across your application.
This allows you to use the same data model for things like insertion of new data and updating existing data. Deleting known data elements through its intended attributes is sometimes also available. This is all done via the design pattern using Structured Query Language or SQL to write to the database.
There are many famous frameworks that use this pattern including:
In all these cases the reason these dependencies are powerful is that they make data simpler. Simplifying data access via the code instead of writing complex SQL with every query. This helps improve greater adoption amongst developers by obfuscating complexity. and example provided below shows the obfuscation of searching for a user by name and occupation with a descending order based on when the user was original created.
User.where(name: 'David',
occupation: 'Artist')
.order(created_at: :desc)
What is an ORM?
A sub pattern of Active Record is something called ORM or Object Relational Mapping. AR only handles the reads and writes for models into and out of the database. ORM makes it possible to address, access, and manipulate objects without a source. It doesn't have to concern itself with how those objects relate to their data sources.
While Active Record pattern wraps a database view or table into a class and takes a single table row to instantiate an object. ORM's are more wrapper independent and can treat the properties and attributes differently. It's more of a non-linear approach compared to what's required by a database system.
With the advent of databases adding hash indexing and JSONB types and their support by ORM's. It's time to think about the possibility of a more web centric ORM structure using GraphQL.
What is GraphQL?
GraphQL is a web based API query language that is changing the way we interact with data. Unlike more popular standards like REST, GraphQL lets you reduce payload request and response size. This has proven important for mobile where query size and response length matter. Much like SQL it also handles relationships between data objects but through a web API.
Learn more about GraphQL API’s
Using GraphQL as a query language in a web based ORM could very well become a paradigm shift in SDK development. This is applicable both when building and designing web apps on the client and server sides.
Most GraphQL libraries function as simple client libraries that allow you to write out a GraphQL query and get JSON. What liblab will do is take a page from existing and known design patterns and apply them to the web. Our goal is to create more than GraphQL capable SDK clients that allow straight GraphQL query. We are building that object instantiation in the most liblab way possible.
What is the liblab way?
Instead of just giving you a simple client to send your existing queries to, the goal should be to make it easier on devs. Instead of them having to build out their object models in the client, we'll partner with other popular clients. With the goal of using our auto SDK generation tools to create a custom web ORM for our customer's existing GraphQL API.
The liblab Engine will figure out the existing models and their relationships. Using the existing schema structure it'll give you an out of the box web ORM that understands your data. This will be valuable not only for your internal teams but also for your API customers in an easy to use way.
Our mission is to revolutionize the SDK space and to allow API developers to focus on their world class API's. Your GraphQL SDK will be accessible to your developers and customers in any language. With the goal of giving your developers and customers a simpler way to interact with your API in the long run.
The SDK itself generates models on the fly which allow us to simplify the GraphQL query process Users.cars.licensePlates would get converted into GraphQL query association with a maximum payload returned while Users(:name, id).cars(:make, :model).licensePlates(:plate) would provide a more refined Active Record like query of a GraphQL API with a minimum payload requested by the user, great for mobile and other types of devices.
In conclusion, what Active Record and ORM patterns did for SQL and databases was crucial. liblab will set the bar a little higher for the whole development process by bringing to the GraphQL space a web ORM experience.
