Grindery Integration Options
Last updated by Jamiu Idowu 4 months ago
Grindery Nexus supports three primary means of integration.
No/low-code integration via the Nexus dApp
A user can create workflows using existing drivers using the now/low-code Nexus dApp . First the user configures a trigger . To do this the user selects an existing web2 driver (Google Sheets) or web3 driver (Gnosis Safe) and sets the parameters that need to be met for the workflow to execute into a web form. Then, using another simple web form, the user creates an action including fixed parameters (“hello world”) set by the user and variable parameters obtained through the trigger from the source system. Finally the user enables the workflow with the click of a button.
The advantage of this approach is that workflow creation is fast and does not require any experience with programming language beyond simple if-then logic.
The limitations of this approach are several.
First, users rely on existing drivers. Adding new web2 drivers requires software development, deployment and hosting. The skills needed to add new web3 drivers varies. Adding support for new blockchains can involve extending Nexus integration to an already supported API (ANKR) or developing an entirely new integration with another blockchain API or SDK. Once a blockchain is supported there are two ways to allow workflows to interact with smart contracts. A developer creates a Connector Description Schema (CDS) that allows the Nexus dApp to show users the above-mentioned, easy to use web form. Alternatively the user can rely on a generic ABI trigger/action that allows them to interact with any smart contract without creating a CDS. This allows users with entry-level programming skills to create workflows with smart contracts that are not yet added as CDS and officially supported.
Finally developers can create recipes to make it even easier for users to create more complex workflows.
Recipes allow to
Hide unnecessary form fields from users when creating triggers and actions in the Nexus dApp. For example, a smart contract event may have 10 fields but only two are relevant to users, we may hide the other 8 from users and present only 2 fields to users, reducing confusion.
Automatically set parameters of triggers and actions without requiring the users to do so in the forms. For example, a polling smart contract may offer an event that triggers on both voting yes and no indicated by a number field; we can use a recipe to wrap it as separate “voted yes” and “voted no” triggers so that users don’t have to mess with event fields.
Add advanced logic to triggers and actions and provide the user with simple ways of accessing them in forms. For example, we can create a recipe for triggering a workflow when someone transfers a token to a wallet and the amount is above a certain value.
Combine/package specific triggers and actions, for example, we can build a recipe to allow user to set up a workflow to send someone tokens when he votes in a DAO proposal, the recipe only presents one field (proposal ID) to users, making it easy to use.
In short the Nexus dApp makes it not only easy and fast to integrate different systems but also does not require the user to deal with any of the organizations, their APIs or their policies to implement them.
Native Embedded Integration using the Nexus Protocol
While Grindery’s no/low-code integration allows any user to create any integration quickly and easily without writing code rindery’s native embedded integrations allow developers to deliver integrations for their users preferred third-party applications. For example, a product team might want their multi-sig wallet to be able to send notifications to email addresses set by their users.
These native embedded integration can be added to self-standing apps (e.g. Grindery Ping), directly into an applications user interface (e.g. user notifications for DCP ) or packaged into so-called extensions, plug-ins or add-ons (e.g. DAOHaus Boost). They allow product teams to deliver integration features to their users without having them use the Grindery Nexus dApp.
<High level description of how how self-standing and packaged integrations are build. I’ thinking we could use Ping to start. Then describe how Ping would be build as self-standing specifically for Gnosis Safe. Then how it would be packaged to run as a Gnosis App. Finally we caa describe the hypothetic case of Gnosis addid the Chrome notifications directly into their app.>
Self-standing apps and packaged integrations can use Grindery API and SDK to programatically create Nexus workflows on behalf of the user. An app or integration can provide its users with a custom interface, dedicated to the specific use case, collect user input and submit workflow definition to the Nexus engine.
In the custom interface users don't need to select drivers, triggers and actions. And the amount of required fields can be reduced, depending on the exact use case. Developers can decide which parameters of the workflow will be pre-defined, and what should be filled by the user.
An example of the integration can be a Gnosis Safe App, that will allow its users to connect to a Slack account and receive notifications when a new deposit happens. All the App needs to do is get the user's Slack workspace, channel name, and submit a pre-defined workflow definition using Nexus API. All the heavy lifting operations such as listening for a new Gnosis Safe deposit event and sending Slack messages will be handled by Grindery.
Creating such an app allows developers to list it in both Slack and Gnosis app directories.
It is also possible to establish integration in the opposite direction - Create withdrawal requests in the Gnosis Safe when a user sends a message to the Slack bot. This will require the developer to create a fork of the Slack driver, and update the bot to handle messages from users.
Creating Web3 Drivers
Web3 Connector Description Schemas (CDS)
Creating Web2 Drivers
There are three reasons why developers would create new Web2 Drivers. The first is simple: the required system is not yet supported. For example there might not be a driver for Microsoft Excel. The second is to add features very specific to an integration use case. For example, we have a Google Sheet driver for listening for new rows in a sheet. However, a user may want to add more complex data transformation on new rows before sending them to other actions, in this case a modified Google Sheet driver or a new processing driver may be needed. Finally there are two more reasons. One is to personalize or brand the end user experience and the other to list your product brand in marketplaces.
For the first of the two cases it's simply about what the end user sees. For example, end users will usually not see or care what user was impersonated to create a new row in a spreadsheet via the API. However, users will notice the name of a Slack Bot or the sender address of an email. Personalizing these appearances can justify cloning and adjustment of existing web2 drivers.
The second case might simply require cloning an existing web2 driver, adjusting the logo and other details and then resubmit it as a new entry for a web2 Apps directory. For example a product team might clone the Grindery Slack App, rebrand it and submit it as a new App to the Slack App directory. This app would now be entirely under the brand and control of that product development team. As a result end user will be able to find the Slack App and identify it under the brand of the product team instead of seeing the default Grindery Slack App.
While personalization of user experience and listing on strategic 3rd party app marketplaces can be of much value it is necessary to consider that the product team will have to not only have to develop but also host, support and maintain that integration independently.
All Web2 Drivers will need, similar to Web3 Drivers, to create and register a CDS on the Nexus Platform in order for Nexus to be able to interact with it.
Workflows that execute blockchain transactions need to pay for the gas of the transactions. Grindery provides a gas wallet that can and has to be funded by the workflow owner no matter the type of integration used. Initially these wallets will be blockchain specific and limited to gas payments. In the future Grindery might provide cross-chain gas payments as well as the ability to pay for workflow executions and the use of 3rd party drivers and services.