{"id":12594,"date":"2021-12-15T14:44:31","date_gmt":"2021-12-15T22:44:31","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=12594"},"modified":"2025-06-13T22:40:21","modified_gmt":"2025-06-14T05:40:21","slug":"data-validation-with-the-eventing-service","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/data-validation-with-the-eventing-service\/","title":{"rendered":"Data Validation with the Eventing Service"},"content":{"rendered":"

Data Validation is an interesting topic to cover for a NoSQL technology, purely down to the fact that the core principles of the system revolve around a “schema-less” architecture. For many years, SQL and schemas have controlled application data, ensuring the conformity of information inside the database. These restrictions prevented the modernization of most applications by slowing down development time.<\/span><\/p>\n

Regardless, you still need to govern and validate the information underneath your applications. With that in mind, how do we achieve this with Couchbase?<\/span><\/p>\n

The flexibility of a schema-less architecture makes it harder to enforce the structure of information coming from multiple sources, such as sensor and edge device interaction, where the number of communication points is vast. There are ways to achieve <\/span>data validation within the database itself<\/b>, using the Couchbase Eventing service. The service, on its own, is extremely powerful and flexible, giving the administrator control over the specifics of the validation on the documents and resulting actions to take.<\/span><\/p>\n

The blog post will walk you an example of using the eventing service to validate the information living in your cluster. As you will see, there are many different ways to build this, but let’s just focus on one to begin with.<\/span><\/p>\n

NoSQL Fundamentals<\/span><\/h4>\n

At the center of any database is the data \u2013 the actual information that we wish to store. Before adopting NoSQL, we would insert the data into our system, but it had to adhere to the structure developers or DBAs defined. DBAs would spend time <\/span>normalizing<\/span><\/a> the information up to the 6th normal form to reduce data redundancy<\/span>. <\/span>This whole structure was commonly known as a schema and was great for validating the integrity of information, ensuring the system of record quality, and becoming a source of truth.<\/span><\/p>\n

Despite the benefits, the schema-based architecture presented some disadvantages, mainly introduced when applications started operating on a higher level and companies started innovating faster. The structured approach to storing data began to slow down development, and schema changes became a nuisance.<\/span><\/p>\n

This is where the schema-lass approach started to take precedence\u2014allowing users to store any information they wished to and allowing the acceleration of innovative development to flourish.<\/span><\/p>\n

\"\"<\/p>\n

SQL but NoSQL<\/span><\/h4>\n

Despite the move to a more flexible and agile database, some attributes of the old model are desired with the new approach; Data Validation is one of those topics. Couchbase has made considerable changes in the recent releases to bridge the gap between SQL and NoSQL technologies.\u00a0<\/span><\/p>\n

Scopes and Collections were <\/b>released in Couchbase Server 7.0 and opened the door to greater logical organization and multi-tenancy use cases. It allowed us to map data from schema to schema-less while still holding the flexible development practices at the core.\u00a0<\/span><\/p>\n

Providing ACID guarantees <\/b>from a distributed system was another big step, ensuring all-or-nothing semantics across unrelated data for transactional workloads back in v6.5.1.<\/span><\/p>\n

Data Validation <\/b>is another topic that comes through alongside these. How do I evaluate the information in my database when there is no schema to enforce it? Like the previous features that complemented the schema approach, the ability to choose whether you have this or not is beneficial. Although, it isn’t necessary to incorporate this into the fundamentals of the application itself.<\/span><\/p>\n

With the proliferation of the 5G network and Mobile\/Edge devices, the chances are, the requirement of data governance and management may still be there. Utilizing tools in the Couchbase arsenal can provide you with an easy and fully controlled method of applying this validation without affecting the performance of either the application or database nodes.\u00a0<\/span><\/p>\n

Edge Computing with Multiple Application Sources<\/span><\/h4>\n

Before we dive into the fun ways of validating on the server, let’s discuss the other option available. Validation at the application level will probably be the first thought that comes to mind. If we want to ensure that information is suitable for storing, why don’t we check it before inserting the documents into the database? Applying application logic on the data before ingestion by the system would guarantee that no document would get anywhere near the database unless the system had already validated it.<\/span><\/p>\n

\"\"<\/p>\n

Theoretically, this sounds like a good idea\u2026. for a single application talking to a single dataset. However, when you start to look at the mobile application space, where we could be talking to several edge devices, all talking to multiple datasets, in a single database, the maintainability will suffer. All teams writing to the database would need to maintain and share the validation logic consistently, and you start to lose the guarantees which were there for the single app scenario.<\/span><\/p>\n

\"\"<\/p>\n

Eventing Service<\/span><\/h4>\n

Considering the application validation problems, we need a way to achieve the same result but at a different point; this is where the eventing service comes in. For those that don’t know about it, the eventing service allows you to act on data mutations in the database programmatically. These actions are defined within JavaScript event handlers and are triggered on any updates or deletes to the data.<\/span><\/p>\n\n\n\n
function<\/span> OnUpdate<\/span>(doc, meta) {<\/span>
\n<\/span>\u00a0 \u00a0 log(<\/span>‘docId’<\/span>, meta.id);<\/span>
\n<\/span>}<\/span>
\n<\/span>
\n<\/span>function<\/span> OnDelete<\/span>(meta, options) {<\/span>
\n<\/span>\u00a0 <\/span>
\n<\/span>}<\/span><\/em><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Since the eventing service can run this logic after the data has come into the database, nothing stops us from incorporating the application logic into these functions. We will pass the responsibility over to the eventing service to check the information whenever it is inserted or modified.<\/span><\/p>\n

This does two things:<\/span><\/p>\n