Today’s leading applications are so dynamic that sometimes it requires developers to use complex tools and infrastructural changes to adapt and facilitate them. Cases like running OCR on images, running filters and resizing images or even sentiment analysis on texts are
very common use cases that require one part of the system to react to something that’s happening in another part of it. We will show how you can build such an application using Zoho Catalyst.
With the modern approach of embracing microservices, where each service is data driven, runs (and fails) on its own, without affecting the rest of the platform it makes even more sense to compose applications as a combination of data driven autonomous services, where each of the services respond to change in data.
This is a common programming paradigm that has lead to the rise of Functional – Reactive – Programming frameworks such as RxJava, RxJs in the recent times where programs listen and respond to changes in a variable/data.
In the context of microservices and even system design as a whole, event driven computation is a model in which a function (computation) is automatically triggered in response to a publishing service its subscribed to. This helps create automated workflows while keeping the functions decoupled. Catalyst embraces this concept to fullest to offer highly functional event-driven compute. Triggers can be set in Catalyst components such as Database, Filestore etc, which is then subscribed by an event function so that the function listens and operates whenever there’s a trigger from these Catalyst components.
Let’s walk through a common use case that most of us as application developers face – Image resizing. Image resizing something widespread in most user facing applications. Any application be it web or mobile – some kind of “profile information” is shown, there’s room for optimization. It makes sense to load a compressed/resized version of the uploaded user image to optimize load speeds and network activity.
Ideally we’d want the resizing to be done right after the user uploads the image on to the servers. For this reason, a common practice is doing the image processing alongside the image upload code.This is how the code looks
As you can see the function to resize image is tightly coupled with the image upload logic while the logic of resizing Is not just restricted to this REST API.
The way to solve it in an event based way is to first separate responsibilities. The REST API will just take care of uploading the image and storing it in the Catalyst filestore.
We then create an “Event function” that responds to events and then create a trigger event for the event function to respond to. You can set up event triggers in the “Event triggers” section likewise
We’ve created a trigger that listens to the folder name “FullSize” for every “Upload” action, so every time a file is getting uploaded to the “Fullsize” folder on the Catalyst Filestore, the “image_resize” function is called.
You can already see the advantage of decoupling the image resize function to a separate event function, because now we can create more event triggers that evoke events from other folders and wire it to the same target function “image_resize”.
The code for “image_resize” will look something like this:
This is one of the ways you can use event driven compute to your advantage. You can find tutorials on event driven compute over here and try it out on Catalyst right away by signing up on our website. We cannot wait to see what you do with Catalyst.
Disclaimer: Catalyst is the sponsor of TalkingServerless.com