Appwrite: [Proposal] Extension API

[TorstenDittmann]

Introduction

To extend Appwrite with third party extensions in the future I write here a proposal as a basis for a discussion.

Extensions are modules which can be integrated into Appwrite and can do the following things:

• Integration into the console
• Create custom API Routes
• Set hooks for different functions

To minimize work it would be advantageous to stay linguistically with PHP.

Appwrite provides an isolated environment with different functions and hooks, which are defined by permissions. Extensions can be installed by uploading a zip file or linking a git repository (which can be utilized to have a marketplace in the future). Extensions then reside on the server.

By default, extensions should only have full access to their own databases. They should be able to grant permission to hook into different actions (like Webhooks) and write/read different data (like API keys).

Hooks are provided by Appwrite to allow your extension to 'hook into' the rest of Appwrite; that is, to call functions in your extension at specific times. For example when a user is created.

Each extension should get its own unique namespace to create custom API routes. To not mess with consistency, extensions should not be able to modify any default API routes.

Each extension needs a Manifest of what permission it needs and the database structure needed that will be created on install.

Developers should be able to register pages into a predefined Extension section in the Appwrite console. The content of the routes should be fully customizable.

The SDK's should have the possibility to call custom routes, so they can be used or even extended to call custom routes.

Summary

With these few interfaces, it should be possible to write very powerful extensions for Appwrite.

[eldadfux]

I think a marketplace will have a huge positive impact on developers using Appwrite.

I’m not sure I would restrict extension to be written directly in PHP for 2 reasons:

1. One of Appwrite’s main mission statements is to be platform and language agnostic. Forcing extensions to be written in PHP will contradict that mission.
2. Writing extensions in an un-isolated environment could become a gateway for malicious code. This will contradict our promise to create a secure solution by design.

I think that once cloud functions we’ll have minimum execution latency, that could be a very good solution for an isolated execution environment for extensions which could also operate for multiple languages. It should be relatively easy for us to leverage existing functions to act as a more complete extension solution.

I think the only way to offer a secure extension to the Appwrite dashboard would be by using Iframes, this have the downsides of not been able to enforce a consistent UI and design with the Appwrite dashboard, and a limited ability to interact with other dashboard components. I would love to hear more thoughts on this. With more different use-cases in mind we might be able to think on a more creative solution for extending the UI.

[lohanidamodar]

I like the idea of not restricting the extensions to be written in PHP only and leveraging the Functions for extension solution.

However, iframes in Appwrite Dashboard sounds scary. If we can, I think its better to have a sandbox kind of environment withing dashboard for Extensions to tap into, so that they can provide additional functionalities without creating security issues. I am not yet sure how.

Anyways, I am in favor of having Extensions API and making it as accessible and easy as possible for any developer to tap into to take its advantage by not limiting language and platform.

[PineappleIOnic]

This sounds awesome! I would love to get involved and make this thing a possibility. I think a good idea would be to have an addon's tab in appwrite's console where all the add-ons reside in a list. Options could open as a popup and within this options could be controlled by the add-on to add forms and stuff.

A design language written in JSON to keep the UI Consistent would be a cool prospect something like

{
  "components": [
    {
      "type": "image",
      "properties": ["center"],
      "width": "300px",
      "height": "200px",
      "src": "https://example.com/exampleicon.png"
    },
    {
      "type": "input",
      "properties": ["center"],
      "placeholder": "Please enter your name",
      "id": "nameInput",
      "width": "300px",
      "height": "100px"
    },
    {
      "type": "button",
      "properties": ["center"],
      "text": "Submit",
      "onClick": "submit",
      "preventDefault": true
    }
  ]
}

I haven't validated the JSON, I just quickly wrote it as an example of what something like this would be like.

[TorstenDittmann]

I don't know if going langauge agnostic using functions makes sense for extensions. In terms of security, you are always vulnerable to malicious actions once you use third party code. This applies to the function and non-function approach.

Also using functions for this might end up in a lot of overhead for extension developers and defining UI by JSON might be too limiting. I mean, we offer the CSS for consistency anyway. Also I don't think that missing consistency is affecting Appwrite's reputation, rather the extensions authors.

Surely we could re-use existing UI, like parts from Database to edit Documents from a Extension specific collection.

We might have to take a look at how Wordpress & co are handling this.

PS: iFrames 😨

[payne8]

I've written plugins/extensions for NextCloud and I liked the way they did it... for the most part. For most of their project they have a well defined interface that allows you to interact with other parts of NextCloud's system. For them it was all in PHP talking directly to the other components. But that doesn't need to be the case. If appwrite were to define a clear 'plugin' API that allowed more access than a project normally would that would be sufficient for any backend code in any language.

As for the front-end code I've found that my clients tend to want to modify the existing UI as much as add a new section for their own functionality. I think the best way to handle the security risks is to moderate what tools get added to a plugin marketplace but allow users to install any plugin from any source at their own risk.