A look into both the origin story and the backbone of the Brightspot work methodology
The best content management solutions are flexible and meet ever-evolving business requirements and use cases; however, not every solution can deliver on these aspects. When looking for the right content management solution, it's worth taking a peek under the hood to see how the platform is engineered. Does the vendor practice what they preach?
This was top of mind when we built the Brightspot CMS. Publisher-informed and integration-ready, Brightspot combines flexibility with highly intuitive architecture, enabling organizations to not only create data models rapidly, but ensure teams are enabled to work efficiently without having to worry about any extraneous details. And that’s thanks to a layer called Dari, which has made Brightspot what it is today.
What is Dari?
Dari means "bridge" in Korean, and the naming was intentional: Dari is an abstraction layer that bridges the gap between the underlying technology that powers various features and the editorial or technical team members who use this technology.
We built Dari before we built Brightspot because dealing with databases is traditionally a tricky process. We wanted to have an abstraction so that developers could interact with data without having to think about the underlying database.
Dari = A bridge beyond the database
Think about the traditional process of building a web application. Engineers will often begin by conceptualizing what kinds of tables they will need, whether it’s an article table, an image table or anything else.
Once the engineers have conceptualized what is needed, they will typically choose a database solution. Next, they will create those tables in the database—defining all of the columns, character counts, etc. After that, they will write code that enables them to write SQL statements so they can query for articles and join them with the image table or author table.
Dari takes the database almost entirely out of the equation.
While engineers may begin with a concept beforehand, Dari enables them to rapidly create data models on the fly. At no point must they deal with choosing a database or creating tables.
Brightspot allows you to move directly from defining data models to your business requirements.
Traditional data modeling vs. the Brightspot approach
- Conceptualize required tables
- Choose a database solution
- Create tables in database
- Write code
- Adjust to business requirements
- Define data models
- Adjust to business requirements
When changes are made to data models in Brightspot, there is no work required in the database, and any database decision made in Brightspot is made from a company perspective and not from an application or business logic perspective.
With Dari, a data model can change without changes to the database, and vice versa. The same is true with querying. Without knowing whether Dari is hitting Solr, MySQL or some other database, developers can write queries that express what data they want to get back, removing the burden of having to think about the underlying database.
Everyday applications of Dari
Once we discovered how well this worked, we extended it to the day-to-day dealings of developers. This began as a result of reconsidering file storage in Brightspot. We were already saving metadata, title and author data, but what would we do with binary data?
Without Dari, if a developer needed to upload a file, they would first need to figure out where to put that file, whether that’s on the local disk, on the cloud, etc. The developer would also need to write the code that puts the file in whichever location they choose. With Dari, on the other hand, the developer simply expresses that they want to store binary data, and then they can make a configuration decision about where that data will be stored, thereby removing the burden of having to code the back end (and the CMS user experience).
This concept still exists in Brightspot methodology today. When we train developers, we teach them this principle so they aren’t required to do large amounts of re-work when they develop new features. They can simply rely on Dari and develop more rapidly going forward.
After creating Dari's StorageItem process described above, we took it even further and decided to apply Dari to editors and other users using the Brightspot interface.
When editors are searching for an image, for example, they shouldn’t be concerned with the API that fetches the image or whether the image is coming from the local image library or from a third-party source (like it does with Brightspot’s Federated Search feature); instead, they should only be concerned with finding the image, and they should be able to do so in a consistent Brightspot search experience. Everything else is extraneous detail that shouldn’t impact their workflow.
Dari = Brightspot
Dari is then, really, both the origin story and the backbone of the Brightspot work methodology.
What started as an abstraction layer that allows rapid data modeling then transformed simultaneously into a methodology that guides our everyday development activities.
Dari enables Brightspot to be a powerful tool for businesses since it enables, at the individual level, more efficient work to be done.
For more on Dari and how it supports the development of robust web applications compatible with a variety of databases, read the Dari guide in our developer documentation library.