Meaning, is it possible (and scalable) to build applications with chat functionality using only usergrid as backend? Or should I use some other solution for this specific functionality?
Thank you
It probably wouldn't be advisable since UG doesn't implement any real-time protocols like websockets. If you used UG you would have to long poll for changes, which wouldn't make for a very good experience in something like a chat app.
Related
I am working on a small project trying to control some steps of a workflow in a web application using MS teams. My idea is to use R as an intermediate step between the application (which has a number of API endpoints I can call from R) and Microsoft Teams chats (or channels). Users would then use a set of keywords in the chat to lead to an action in the application. For example they might use "publish ABC-123" in a specific chat and this would lead to the application publishing document ABC-123 somewhere via R which would orchestrate everything.
I have a couple of ideas but there are drawbacks:
I thought originally about using microsoft365r. We have an app registered in Microsoft 365 which would allow us to monitor a specific chat for messages that trigger actions in R. The problem with this approach is that we would need to have the R code running and checking MS Teams every couple of minutes. It is certainly doable, but not very elegant.
Another option could be setting up a plumber API and an outgoing webhook in MS Teams. This seems like the ideal way to do it, but webhooks in MS Teams require https and as far as I understand this is not straightforward to implement in plumber.
I would appreciate any ideas on how to do this. I know I am not very specific, but mostly looking for high level pointers of what I could look at. Many thanks!
You actually have a bunch of options for this:
Create a bot directly in code, e.g. per https://learn.microsoft.com/en-us/microsoftteams/platform/bots/what-are-bots . There's a bit of a learning curve of course, and it depends on whether you have development skills outside of r, e.g. python, .net, whatever. The bot would then call your code as needed.
Create a no-code bot using Power Virtual Agents. This is the equivalent, for bots, of Power Apps or Power Automate, if you're familiar with those.
Create a workflow, either in Power Automate or Azure Logic Apps, that can listen for and respond to messages. This is kind of similar to a bot, but with finer scope (and therefore less capability). If you want it to call out to your app, e.g. to an endpoint, you'd need a Premium Connecter for Power Automate, or you can use an Azure Logic App directly (uses the same engine, but the pricing model is different for these and Power Automate is a little easier to work with.
Outgoing webhook - you can implement these as standalone, but actually from your use case it sounds like a bot would be better anyway, and it's kind of what you need to build to make this kind of webhook work properly anyway.
I've never used Firebase (or Firestore) before and I'm considering using it for my new mobile application. And I'm wondering if using Firebase only, without any additional server is a good idea. Firestore does a lot of things I guess, like authentication, security and scalability. So I really hesitate putting an another server into Architecture. But I have a plan to do many server-side stuffs like searching for text or calculating something.
I think the answer is "it depends", but I want to hear some advices from people who have used Firebase before about this topic. Thank you in advance!
Is it a good idea to use an additional server with Google Firebase?
Firebase will help you build apps fast, without managing infrastructure. So you'll be able to focus on your app development and not on how to maintain servers. Perhaps, if you have requirments that Firebase cannot handle, which I doubt it, you can use an additional server.
I've never used Google Firebase (or Firestore) before and I'm considering using it for my new mobile application.
If you have never used the Firebase suite, I recommend you get started by reading the official documentation. Before starting to use Cloud Firestore, I recommend first get more familiar with NoSQL databases.
And I'm wondering if using Firebase only, without any additional server is a good idea.
There are many apps out there that are not using any other server than Firebase.
Firestore does a lot of things I guess, like authentication, security and scalability.
Firestore is a scalable NoSQL cloud database that allow you to store and sync data for client- and server-side development. It does not authenticate users. For that, there is another product named Firebase Authentication that I encourage you to use it.
But I have a plan to do many server-side stuffs like searching for text or calculating something.
Here you can find more details about Firestore search options. Regarding calculations, you can do pretty much everything you can do in a regular SQL database.
I've been reading about Firebase and playing with it for a short while. The idea (BAAS) and implementation are impressive, and having programmed with Javascript it seems a viable choice. Not having to deal with scaling and other server side concerns makes it even more attractive.
My question is: generally speaking, is Firebase a first class back-end candidate for any average data-based application? e.g. billing, CRM, e-commerce, social, location based, etc. I do not include super light or heavy extremes such as a basic chat, or a nuclear plant monitor...
The answer may not be a clear yes/no, but was it built to support the general application space, or just stand out as a real-time read/write data service?
Would appreciate answers based on experience and existing production applications.
Thanks
Yes, Firebase is intended to be a first class back-end for any data based Web, iOS or Android application. The service offers real-time data reads and writes, but also comes with a powerful and flexible security system that allows you to write secure client-only apps, without needing any server code to enforce data boundaries.
There are several apps in production listed on the front page as customer and on the app showcase page on https://firebase.google.com/customers/
Firebase is now more capable and is considered as a full stand-alone back-end, especially after the introduction of cloud function. https://firebase.google.com/docs/functions/
Firebase may not have support for transaction spanning multiple business objects.
e.g. When a sales order is booked then it needs to update inventory for multiple items, update billing in receivables, give sales credit to multiple sales persons etc.
Firebase team is supposed to come up with a database trigger option which will make all these happen.
I've been looking for IIS based solutions for comet/push/reverse-ajax pages, and came upon asynchronous controllers
It seems like that allows xhr long polling without the problem of running out of threads, am I correct? Does this allow fairly decent scaling for long polling pages?
I would say take a look at signalR. Nodejs for iis is also an option
If you are looking for a pro solution with built in websocket, pick PokeIn
See ASP.NET MVC 3 real time events.
To make scaling easier/less of an issue I'd recommend using a dedicated realtime server (see this realtime technology guide; something that has been built from the ground up with realtime communication in mind.
I was wondering how IM+/IMO --multiprotocol web messengers would be able to support skype instant messaging without SC(Skype Client),even pidgin does support skype but SC has to be installed in case of pidgin.I am very curious about the imo web messenger.Do they establish connection using skype API(i dont know) or some other way... Any one who have idea/clue about how it can be done please let me know.
Any help is appreciated!!
Well, skype uses propriatery protocols, and there are some efforts of reversing them:
http://en.wikipedia.org/wiki/Skype_protocol
Update
It is now possible to connect through “Skype for Web”, allowing you to just use your browser to connect to the (clunky) web client.
Way better: a recent plugin for Pidgin lets you use it directly through Pidgin, effectively adding true support for Skype in Pidgin.