Alternatives to Duo

Nexmo vs Twilio ?

Back in the early days at SmartZip Analytics, that evaluation had - for whatever reason - been made by Product Management. Some developers might have been consulted, but we hadn't made the final call and some key engineering aspects of it were omitted.

When revamping the platform, I made sure to flip the decision process how it should be. Business provided an input but Engineering lead the way and has the final say on all implementation matters. My engineers and I decided on re-evaluating the criteria and vendor selection. Not only did we need SMS support, but were we not thinking about #VoiceAndSms support as the use cases evolved.

Also, on an engineering standpoint, SDK mattered. Nexmo didn't have any. Twilio did. No-one would ever want to re-build from scratch integration layers vendors should naturally come up with and provide their customers with.

Twilio won on all fronts. Including costs and implementation timelines. No-one even noticed the vendor switch.

Many years later, Twilio demonstrated its position as a leader by holding conferences in the Bay Area, announcing features like Twilio Functions. Even acquired Authy which we also used for 2FA. Twilio's growth has been amazing. Its recent acquisition of SendGrid continues to show it.

Hello,

I'm trying to implement a solution for this situation:

There is a restaurant in which users can access RestAPI, using Google, Facebook, GitHub. There is even the possibility to login inside using the SPID authentication. In the first case I was considering Keycloak as a better solution for this case, but then i've read about Okta and its pros.

I cannot understand reading and searching on Google if SPID authentication is supported by OKTA. Looks like to be, because it should be using SAML, but I haven't found a clear solution.

I want some good advice on which one I should prefer. (Keycloak or Okta) Since Keycloak is open source, it will be our first preference, but do we face some limitations with this approach? And since our product is SAAS based and we support the following authentications at present. 1. AT DB level 2. 3rd part IDP providers 3. LDAP/AD...

Hi, I am building an enhanced web-conferencing app that will have a voice/video call, live chats, live notifications, live discussions, screen sharing, etc features. Ref: Zoom.

I need advise finalizing the tech stack for this app. I am considering below tech stack:

• Frontend: React
• Backend: Node.js
• Database: MongoDB
• IAAS: #AWS
• Containers & Orchestration: Docker / Kubernetes
• DevOps: GitLab, Terraform
• Brokers: Redis / RabbitMQ

I need advice at the platform level as to what could be considered to support concurrent video streaming seamlessly.

Also, please suggest what could be a better tech stack for my app?

#SAAS #VideoConferencing #WebAndVideoConferencing #zoom #stack

Using Screenhero via Slack was getting to be pretty horrible. Video and sound quality was often times pretty bad and worst of all the service just wasn't reliable. We all had high hopes when the acquisition went through but ultimately, the product just didn't live up to expectations. We ended up trying Zoom after I had heard about it from some friends at other companies. We noticed the video/sound quality was better, and more importantly it was super reliable. The Slack integration was awesome (just type /zoom and it starts a call)

You can schedule recurring calls which is helpful. There's a G Suite (Google Calendar) integration which lets you add a Zoom call (w/dial in info + link to web/mobile) with the click of a button.

Meeting recordings (video and audio) are really nice, you get recordings stored in the cloud on the higher tier plans. One of our engineers, Jerome, actually built a cool little Slack integration using the Slack API and Zoom API so that every time a recording is processed, a link gets posted to the "event-recordings" channel. The iOS app is great too!

#WebAndVideoConferencing #videochat

Uploadcare is mostly remote team and we're using video conferencing all the time both for internal team meetings and for external sales, support, interview, etc. calls. I think we've tried every solution there is on the market before we've decided to stop with Zoom.

Tools just plainly don't work (Skype), are painful to install for external participants (Webex and other "enterprise" solutions) can't properly handle 10+ participants calls (Google Hangouts Chat).

Zoom just works. It has all required features and even handles bad connections very graciously. One of the best tool decisions we've ever made :)

I use Slack because it offers the best experience, even on the free tier (which we're still using). As a comparison, I have had in depth experience with HipChat, Stride, Skype, Google Chat (the new service), Google Hangouts (the old service). For self hosted, Mattermost is open source and claims to support most Slack integrations, but I have not extensively investigated this claim.

Hello everyone, I plan on building a platform that supports 100s of forums out of the box, it would give the user the ability to create forums, where other users can comment, post images, and videos (the size of videos would be limited). Each forum would have the ability to trend. I have been doing a lot of research and I have arrived at Golang and Erlang as the backend languages and PostgreSQL as the DB. Erlang would be used for the routing of chats and messages, while Go would be used to manage the forums. We would also be implementing a one on one chat system like WhatsApp chat, where users can add contacts.

Please I would like to know if the languages picked are appropriate for this project. Suggestions would be appreciated.

Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

https://eng.uber.com/distributed-tracing/

(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark