Hi all, I am looking for advise and direction between these two Real-Time methods to use for my mobile application. It’s not really messaging I’m looking for, however it’s very similar. Here’s what I need: one user using the application can broadcast short 100-300 character sentences to other users that connected to their channel. Users can only channel in on 1 broadcaster at a time. Other info is sent along with the message such as the name of the language of the message. Now that I’m explaining it, seems pretty straightforward. And sounds like Real-Time messaging is the way to go. However, which is more instantaneous? Also, I want them to be able to connect to a channel without needing to subscribe. They can simply connect to any channel and receive messages. Can disconnect. And connect to another user’s broadcast easily with just one button click on their profile. Also, listeners can be notified when the broadcaster is logged-in and broadcasting again. Is the subscription part bypass-able in R-T Messaging? Or should I just go with Real-Time Database because no subscription is needed? Which would be more efficient and elegant? I know there are many other factors to consider here. Please help me flesh this out. Thank you beforehand. -Michael
*Also want to know (might be a stranger question): why are Real-Time Database and Messaging only listed in the Backendless SDK for JavaScript API Documentation and not in Rest API Documentation? I used the codeless blocks for integration with my Thunkable app using Web API for logging in and user object post/get/etc. Will I be able to use the Web API to utilize these Real-Time services?
I would use RT DB if I needed a persistence in my data. in other cases RT Messaging is looks like a more lightweight and instantaneous way.
As for subscriptions - they will be required, but you could maintain only one broadcast channel, and just filter messages by chatId/senders/receivers.
why are Real-Time Database and Messaging only listed in the Backendless SDK for JavaScript API Documentation and not in Rest API Documentation?
Real-Time Messaging and Real-Time Database rely on WebSockets, which REST APIs do not support. But in codeless you could find messaging blocks that will help you.
Thank you Dima! This reply helps a lot. I would like to clarify that Subscriptions are required for both? DB and Messaging? Also, Messaging could maintain only one broadcast channel? If I understand you right, that would make sense since messaging is 1 to 1…
I looked up what WebSockets means and see that I can’t use the http way
to maintain live 2-way channels. When you say that the messaging blocks in codeless will help me… How so? If I were to use the JavaScript Web Bridge component in Thunkable, could I still use the codeless messaging blocks in Backendless? I’m very new to this… Thanks again for your help!
Yes, you can use the JavaScript Web Bridge in Thunkable together with Codeless messaging blocks in Backendless.
It should be noted that:
Backendless and Thunkable operate independently, but they can interact through HTTP requests, API Services (custom events).
The JavaScript Web Bridge can be used to manually call Backendless APIs.
Practical scenario:
In Backendless:
create logic using Codeless (for example, retrieving data from a table and sending a message). This logic is accessible via the Backendless REST API.
In Thunkable:
Call this API using either the Web API component or the JavaScript Web Bridge.
Receive the response and handle it within Thunkable.
So yes, you can combine Thunkable with the Web Bridge and Backendless messaging, but they communicate via APIs — not directly through “Thunkable blocks ↔ Backendless blocks.”
Oh My friend. Thank you for getting back to me. It’s been a productive few days. I started out approaching it the way you described (Thunkable–>WebAPI–>Backendless (save to database)–>Codeless Logic (RT Messenger). However after wrestling with ChatGPT for days, I was able to gather about a page of script for the JS Web Bridge in Thunkable to send the message through RT Messenger and then using the Event Handler with Codeless Logic to save the info to the Database as the message goes through. Cleaned the code up with Grok. Testing now. Supposed to be a little bit faster, exposes API keys in the Web Bridge though. Backendless security with Tokens in the Handler should cover this though (to keep the message channels from being hijacked)? Thank you for your kindness and getting back to me! Developing is really something else! God bless!
Wonderful! Guess what. I had trouble with getting it to publish through the JS Web Bridge component of Thunkable. So reverting back to doing the way you suggested! (WebAPI and then Backendless Codeless to send the message when saving the latest message to database, fractions of a second slower, maybe… and much less coding, problems and of course more secure. Will use handlers for counting number of subscribers, etc. Thanks again! God bless!