[DISCUSSION] Appwrite Messaging API - Community feedback is required* about appwrite HOT 7 CLOSED

As initial point i agree that this should be an API. It will facilitate first and third point in concerns list. For push messages and to not increase costs and maintain the actual budget you could test: https://gotify.net/ seems a pretty good thing and start from there. For email will be a huge challenge, maybe someone in the community have experience and know-how for doing this and bring what we need to prevent spam and other traps.

from appwrite.

As initial point i agree that this should be an API. It will facilitate first and third point in concerns list. For push messages and to not increase costs and maintain the actual budget you could test: https://gotify.net/ seems a pretty good thing and start from there. For email will be a huge challenge, maybe someone in the community have experience and know-how for doing this and bring what we need to prevent spam and other traps.

Gotify i think only supports plain text and has no support for Rich Text messages. OneSignal was great , but it is not longer free and opensource .

from appwrite.

Hey @miguelramos, this a great idea that was in Appwrite original blueprint.

We left it out of our first versions because implementing it had a few issues we didn't have time to address.

It's something we definitely would like to come back to in the future!

from appwrite.

Cool, maybe mosquito(MQTT) for the infra and it is well know in IOT world and mailhog/maildev too, but is just a consideration and yes will increase the infrastructure but they are cool options.

from appwrite.

Yeh, no doubt, this is a massive feature in terms of infrastructure and user integration. I would love to get some more community feedback on this one.

Our initial idea was to create a messaging API that has multiple adapters for sending messages to different endpoints.

Some of the adapters we had in mind included:

• Email - Using Appwrite current SMTP server or a user-defined one (will have to find a good solution for SPAM preventing)
• Push Messages - Should probably support at lease iOS, Android and Web
• Telegram - Probably the easiest one to implement
• SMS - will require external provider, might also allow us to use this for future 2fa feature

Some of the main concerns I have, including but not limited to are:

• How to easily allow developers to integrate correctly with adapters
• The infrastructure overhead - we need to keep default setup cheap (5-10$ servers)
• Making sure the API is consistent and predictable
• How should the dashboard look like, should we have stats alongside adapters configuration, what else is needed in the console?

from appwrite.

There are two kinds of messaging that Appwrite should support.

1. User notification via push messages on different communication channels.
2. Internal application bus. A hi level bus api where the underlying broker is hidden and where is it possible to post events, queries and commands (CQRS)

As we need to subscripe for push messages in our applications it requires a websocket connection point in Appwrite.

from appwrite.

@wentzlau great feedback, the push messaging is definitely something we'll have on our roadmap.

I also really like the idea of having dedicated support for server-to-server communication. Do you have any suggestions for a communication protocol that will be good for this type of communication?

from appwrite.