Is it possible to achieve less than a second latency in a video broadcast? What if the stream goes to a thousand people? Yes. How? Let’s answer using the project WorldCast Live as an example. We did it using WebRTC. WCL streams HD concerts to an audience of hundreds and thousands of people.
Why would I reduce the broadcast latency?
Latency less than a second in a videoconference is normal, otherwise speaking is nearly impossible. For one-sided streaming, the latency of 2 or even 20 seconds is fine. For example, TV delay is about 6 sec. However, there are cases where you’d try to reduce it to 1 second.
It’s highly unlikely that the user will be happy when their neighbors shout, GOAL!, and he still sees the ball somewhere in the middle of the field. What if the user is also live betting?
Thanks to the pandemic, not only talks with friends have moved online, but also interviews with celebrities. Take an interviewer’s latency, add to the interviewee’s latency, and add the time spent while it all goes to the user. The more you get, the worse the experience is for all sides.
The WCL player is embedded in different sites. Concerts broadcast online to all of them. If you and your friend use different sites to watch the same concert, it will negatively affect your viewing experience. Thus, the concert organizers are trying to minimize the latency. Although the user wouldn’t really care whether he hears the guitar riff now or in 2 seconds, there is a general trend on minimizing the latency. The faster the better!
The examples above combine. In WCL viewers and performers talk via a video chat. Therefore, the latency has to be like that of a video chat, as we need the minimum difference in time between the question and the answer.
How to reach low latency in live streaming?
The standard WebRTC package offers average latency of 500 ms (half a second). We could’ve finished the article here: creating a video chat where people can connect with each other isn’t difficult. What’s difficult is making it all work stable for thousands of people and customizing streams to improve their quality.
Base WebRTC isn’t about HD streaming. Video and audio quality is enough for speaking but isn’t enough for streaming music. To decrease the latency, WebRTC can reduce the quality and skip parts of the content. To avoid it, you have to go under the hood of WebRTC, which we did.
Set up WebRTC
To ensure that the low latency doesn’t go against quality and the final user’s experience, you need to go for extra development. Here’s what we did for WCL so it can broadcasts concerts to thousands of people:
Enabled multi-channel audio
The standard audio in WebRTC is mono, it’s 1 channel. The stereo is 2 channels. There are 5 channels on WCL.
WebRTC settings limit the video transmission speed to 500 kb/s. That’s not much for action on the screen: if light colors change quickly with this limit, the quality will be lower because of trying to go inside that channel, pixels might appear. Not a great watching experience. Therefore we’ve increased the bitrate to 1,5 Gb to transmit HD video.
Increased discretization frequency
By this, we’ve improved the quality of audio and video, low and high frequencies. They are not lost anymore. We can’t disclose what exactly we did, but if you’re interested in that, let us know!
Kurento Media Server is an open-source WebRTC server. Set up Master Kurento to stream video. 500 hundred people will connect directly to Master Kurento, from where they’ll get the stream. If there are more viewers, Edge Kurento is in play, to which other viewers connect. The more viewers there are on the stream, the more Edge Kurento you need to use. All together it creates a tree-like scheme.
When do you leave the latency of more than a second?
When the budget is limited. WebRTC is more expensive than HLS if you need scaling. The WebRTC server on WCL costs $0,17/h which is $122,4 monthly if we take 30 days.
HLS, however, costs $0,023/h and can be turned on and off, unlike WebRTC. If we take 3 hour-long concerts a week, then we’ll spend a bit less than $0,28 for 12 concerts. Note that there are many server providers, the prices are always different, but you can see what it looks like using our project as an example.
The first stable version of subsecond latency on WCL took us 3,5 weeks. If there’s no necessity in very low latency, why spend?
Latency less than a second in a broadcast is necessary when there’s communication between participants or a stream where things change all the time. WebRTC makes it possible for even a thousand people if you work with the technology.
If your app is about something from here, make sure to take a look at WebRTC. Contact us, too, we’ll help! Contact us via our form or DM on Instagram, which we created not so long ago 🙂
Starting with Mojave 10.14, Apple has introduced serious changes in app publication. They are about signing and notarizing the apps. If your application is bad in the eyes of Apple, final users will see threatening messages upon the first launch. The messages would ask the users to delete the app, which is not really good for customers, right?
This is the 2nd part of the two-part article on signing and notarizing macOS Electron apps. You can find the 1st part here.
The author is an ElectronJS app developer himself, Around a year ago, faced the problem of having to notarize the app on Apple servers besides signing it. It means that you check whether the app has malware in it.
To notarize, you have to send the app, wait for 10 minutes tops, get your results, and be happy. For those who are not proficient in it, there is an article on our website. There we discuss basic concepts of publishing apps to macOS.
I began notarizing my apps and kept getting the Package Approved notification over and over and was pretty happy about it, until recently, when I noticed that the situation repeats itself. All right, I thought, let’s just notarize it once again.
In the end, the status had over 9000 authorization errors. Invalid certificate for some files, absence of hardened runtime even an absence of executable library files from NPM.
Sounds scary, doesn’t it? That’s right, Apple is making their system tighter, more secure, and doesn’t allow publishing a threatening, from their PoV, application.
I started discovering solutions. In the end, I was able to solve the problems and understand the rules of the game with Apple deeper. Actually, there are solutions in the internet but they are spread too wide. I’ve spent a considerable amount of time amassing experience in the field and now am willing to share it with my fellow developers so that their Electron apps are notarized faster.
I faced these problems when the app was using the ElectronJS library 5.0.0. I used electron-packager 13.1.1 to build an app and exelctron-osx-sign 0.4.15 to sign it.
To sign an app, we have a certificate Developer ID Application: <TeamName> (<UniqueID>) on the Apple site. A certificate like this allows releasing apps through any online service. We use the release server Electron to do that. You are going to need another certificate to publish apps to Mac App Store.
So where’s the pain?
In errors. I’ve split all of them into subparts and showed the solution which will make you more successful in the matter.
What Apple doesn’t like
The binary is not signed. Absence of certificates and timestamps for internal executable files
The notarization log from Apple for many internal app files had The binary is not signed error. Every executable file was a part of this, for instance, built FFmpeg and echopring-codegen libraries. which are used externally by the app. Some executable files from NPM libraries were there, too.
The solution here is simple. While signing apps, it’s important to sign all files that Apple doesn’t like with this certificate, not just the .app one.
If you use a codesign utility, it’s mandatory to list those files with a space. Use the electron-osx-sign library, activate binaries to create paths to binary files that need to be signed with this certificate.
It’s worth mentioning that this solution is also usable for The signature does not include a secure timestamp error. It’s because the certificate puts its own timestamp while signing a file.
The signature of the binary is invalid. Wrong routes in the general hierarchy of an Electron app
This error is, in my opinion. an Apple mistake. Whenever an .app file is sent to notarization, it automatically is packed into a .zip archive. Because of that the hierarchy of some paths corrupts, thus the certificate becomes invalid for some files.
The solution is packing the file by yourself into the .zip archive, using the integrated utility ditto. It’s important to use a special flag – -keepParent, which allows saving the hierarchy of all paths during packing. So, this is the command I used for packing:
After this, you can send the archive to notarization.
I use electron-notarize for notarization. When the notarization is successful, the library tries to return an archive of the app, so that you unpack it and swap an .app file with a notarized .app file. However, please note that XCode spectool can’t work with archives.
The executable does not have the hardened runtime enabled.
Now let’s discuss the most difficult and interesting notarization problem. In the latest macOS versions (10.15 Catalina and 11.0 Big Sur), Apple requires that the hardened runtime is enabled to launch apps. It protects the app from malware injections, DLL attacks, and process memory space tampering. Apple wishes to protect their users, therefore this is an important requirement.
To go with this requirement, you have to use a flag –options=runtime if codesign is used or mention a field hardenedRuntime: true if you’re going with electron-osx-sign. So, I took this action and found out that using this flag completely breaks an Electron app: it either doesn’t launch or fails with a system error.
One way or another, after having spent lots of time googling, I found a set of requirements. Completing those requirements helps building in building and signing an Electron app with hardened runtime
How to build and sign an Electron app?
First of all, forget about Electron v. 5
As sad as it may sound, you have to forget about Electron v. 5 and update it to v. 6 at the very least. As the source says, hardened runtime support was introduced in Electron v. 6, so any attempts to enable it in the predecessor are doomed to fail. Besides, if you’re using electron-packager, you must update it to v. 14.0.4 for the apps to be build correctly.
Testers will probably not be happy to hear about it but there’s so much we can do. Apple sets the rules of the game, and it will be necessary to complete a full regression test of the app with a newer Electron version.
Second, create a parameter file entitlements.plist
This practice often comes in handy when creating apps in XCode entironment, but when it comes to Electron apps – not so much. Electron builder will automatically enable a deafult file with a standard parameter set. The file is an XML code and it lists system prohibitions and permissions on using different resources of the OS. This file now has to contain 2 important parameters.
The first one, allow-unsigned-executable-memory, allows the app using raw memory. The second one, allow-dyid-environment-variables, allows using environment variables. Every JS developer knows what they are, but these variables are not exactly the same as those we use in the app. This parameter permits the Electron framework using the environment variables he needs for correct work. For example, a path to the system library libffmpeg.dylib. If this parameter isn’t in the file entitlements.plist, the app will fail on the first launch, and will show an error of that library not being where it’s supposed to, despite it actually being there.
Third, activate entitlements.plist correctly
The file must be connected during signing a built Electron app with a certificate. If you’re using codesign directly, type in a flag –entitlements, then space, then show the path to the parameter file. However, it might not work right away, and codesign will have an error unrecognized option for that flag. To deal with it, use the utility codesign not from XCode Developer Tools but from the full XCode environment with a more expanded version of the utility. Run these commands to do that:
There is a simpler way, too: use electron-osx-sign. However, it’s important to note that you have to enable the parameter file in entitlements and entitlements-inherit fields, otherwise nothing will work. It’s because entitlements-inherit is responsible for the parameters mentioned for distributive frameworks, and our app actually does work on Electron framework. This framework needs environment variables with paths to system files.
If you develop desktop apps for macOS on XCode, you likely won’t face these issues. Apple adapts its environment rapidly. However, as it turns out, Electron apps are out there, too. It’s possible to take care of the notarization problems, and the users can be absolutely happy without seeing the warning about potentially dangerous software.
I hope that this article was useful to you. If you have any other questions on the topic, do not hesitate to contact us via the contact form!
We have also launched Instagram, so feel free to check us out there, too 🙂
Developing a program code always brings joy. You get the instant outcome, you may check it out and see how neat the user experience is.
However, there are some formalities that act as a buzzkill here. Some of them are about publishing an app. Windows and macOS protect their users from malicious software, therefore publishing anything and everything isn’t possible. It’s imperative that the OS knows that the software comes from the trusted developer (signing), and its code doesn’t contain threats to the user (notarizing). Windows has only signing requirements, while Apple has been checking notarization since the macOS 10.14 Mojave was released.
This article came about after having to face some troubles while publishing an ElectronJS-app for macOS, and I would like to share my experience. We will begin with some starting information. If you’ve already developed and published ElectronJS-apps, feel free to skip through this part and we will see you when the more interesting one comes out – in a week or two 🙂
A short introduction to ElectronJS
ElectronJS is a tool to easily create a cross-platform app to launch it on all popular operational systems. The library uses the Chrome V8 engine and emulates a different browser window, where you can apply your HTML code, written with ReactJS. Electron uses its own backend to interact with an operational system, for example, to show system windows. Communication between what the user sees on the screen and the Electron backend happens with events.
Building an application is also fairly simple. Electron daughter libraries are in charge here, such as electron-builder, electron-packager. As an outcome, we have a ready binary file – .exe for Windows, .app for macOS, or executive binary file for Linux
You wrote and built an app. Ready to publish and send to the customer?
Unfortunately, not. For the users to launch an app, a developer certificate is necessary. This is a so-called digital signature of the app. It protects the program by mentioning who the author is. Apps with digital signatures are verified and are less-provocative to the system, antivirus programs, and firewalls. Software like that rarely ends up in quarantine.
If the app isn’t signed, macOS will politely ask to move the file to the bin.
Windows will notify the user that the developer is unknown and you’re at risk.
Do not scare your user with these messages, better go and get that developer certificate! Add it to the keychain of the OS you are making a signature for. Later, use the certificate to sign the app. XCode Developer Tools on macOS provides codesign to do that. Electron-builder and electron-packager libraries supply you with their wraps to sign an app. You just have to let them know that you’re willing to sign an app with that particular name after the building is completed. More than that, macOS has one more way to do so: a separate wrap library electron-osx-sign.
Got the certificate, signed the app. Anything else?
Yep. Notarizing is the next step. It means that you have to check the code on the Apple servers to verify that there is no malware in it. Otherwise, the user will see this upon the first launch:
XCode altool provides utility for notarization. Unfortunately, it’s not in the XCode Developer Tools pack, so we have to install the full XCode. That moment when you don’t use XCode, like, ever, but you need it so you kiss goodbye to around 30 Gb of memory 🙂
Electron developers have expanded electron-builder and electron-packager libraries by adding a notarization process into the general workflow. There is also a separate wrap library electron-notarize which does exactly the same things. Basically, you need for things ready: built and signed .app application, appleId, appleIdPassword,appBundleId.
If a notarization tool doesn’t stumble upon anything bad in the app, your status will turn to Package Approved with a status code 0. Otherwise, Apple will give you the Package Invalid status and a status code 2. Fear not, friends, as every “bad” notarization has a log attached. All problems are mentioned there, as well as the directories of the files that stopped you from publishing right away.
If notarization is successful, congratulations! You’re ready to release your app.
When you have that last piece of the jigsaw, everything will, I hope, be clear (Albus Dumbledore)
When starting developing a desktop app on ElectronJS, think about the certificate to sign the app in advance. Don’t forget about the notarization, either. If you skip these parts, the potential amount of software users will drastically reduce because of conflicts with an operational system.
The 2nd part of this text will be released soon, and it will touch on the problems one might face when notarizing an app on macOS. See you then!
There is no right answer to that question. However, the Fora Soft team is willing to share our knowledge with you. The knowledge that we have been nurturing for several years.
We also provide some COVID-era solutions, so make sure to check them out, too!
Make communication between employees less formal
When there are no barriers that formal communication brings, it’s easier for your team members to share things about their problems and say their opinion on things during Scrum meetings.
We tend to demolish those barriers with the help of monthly office parties with a ton of pizza involved. Formality becomes a difficult concept to maintain when you are sitting at the same table consuming that saucy pizza 🙂
Fun fact: it’s easier for people to start a dialog after they’ve established a visual contact, hence our choice of food. To get a bite of that delicious thing, you just have to hold the slice near to your face. Thus, we do not only have a great time eating pizza during the working day but also improve the working atmosphere.
In COVID times, we meet in Zoom instead, but weekly, not monthly.
Make your workspaces comfortable
Place them so that there is a distance of 1,5-2 meters between employees. That way the coworkers will find themselves within each other’s social distance. Read more about proxemics, the study of human use of space, on Wikipedia.
Comfortable distance between workstations allows employees to be open for discussion while still having enough private space around.
There is no correct way of setting devices, it all comes down to personal preferences. Your task as a manager is to give your team the furniture that they can easily adjust.
In COVID times, we work remotely. Each project team meets in a video call daily to compensate for the lack of communication. Effectiveness has even improved – we now talk more.
Lower distance between the boss and the team
In some companies, the boss doesn’t get enough trust and may even be feared by employees instead of respected. To make the relationship less formal, our CEO goes around the office and greets every and each employee face-to-face.
We also have an Open Door principle: if the CEO’s door is open, you can come into his office and rap with him about life ask some questions, or suggest a way to improve the processes in the company.
In COVID times, it’s Open Skype principle instead 🙂 (poor CEO)
Be clear about the company’s / project’s aims
Every member of a project team needs to know where the project or the company is going. It helps them plan their development and stay updated on perspectives.
In Fora Soft project members discuss upcoming features, their feasibility, and possible improvements together in a comfortable conference Skype room. In COVID, we do that on daily video meetings.
The company’s aims for the year are announced at the New Year’s party and monthly objectives are hanging in the dining room, which is – no surprise here! – the most visited venue in our office. In COVID, the CEO shares company’s aims at Thursday’s general company video meetings on Zoom. We post recordings on Instagram – catch a moment to see 🙂 They are in Russian, but you can feel the atmosphere.
That’s all, folks! Feel free to use our methods to establish a great working relationship with your colleagues! If you have any other questions on the topic or just wishing to share your secrets, don’t hesitate to contact us via the Contact form!
Many of our customers come up to us asking if we could make an MVP for them. Yep. Even big corporate clients want what used to be a startup fad — and what is now an industry standard.
But what is an MVP? The abbreviation, standing for Minimal Viable Product, is used to imply you hit the market before you’re done with all the features. Why is it that popular then? Is it a fancy way of saying “whatever works is fine”, a bargain solution for low-budget projects… or a misused football term after all?
What is an MVP?
Speaking of minimal viable products, let’s get started with setting on the viability criteria. For a software piece, viability definition may lie within the range of “not crashing on launch” to “being able to compete against the leaders”.
Within the Lean Production Methodology, where the MVP concept originated, V stands for “bringing value to the user”. That’s why they often read MVP as Minimal Valuable Product.
The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction, and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers
Frank Robinson, the author of the term
So, MVP is basically a killer feature, and the simplest buttons and handles one might need to make use of it. You cut all the bells and whistles off your concept, strip it of all the fancy design extras, and anything that is not crucial – as simple as that.
Why would you go for an MVP?
Here’s an example. Imagine you’re a fan of a particular sport — let’s say, boxing. And you want to become the new Muhammad Ali. So, you start training with all the passion and dedication and whatever else you may find in movies about Rocky Balboa. The question is: when will you take on your first fight?
Option one. You train for ages until you feel like you are two hundred percent fit and ready.
Option two. You get some pretty basic training and jump into the ring as soon the coach is sure you’ll make it to the last round without kicking the bucket. As soon as you are viable for the ring.
Option one is tempting: if things go well, you’ll plow through the underdogs and face the big guys without losing your breath. Option two appears hurtful: if things go well, you will win. But should you win or should you lose, you won’t leave without a bruise.
However, there is a but. “If things go well” is the critical part in both scenarios. Once you enter the ring, reality comes at you fast. What if you figure out you missed something in your training? What if those in the ring are still trained better? What if the blows you receive hurt too much (shocker!)? Or – why not – what if what you deemed boxing and your passion was actually wrestling, so all your great punching skills are totally inapplicable? You’d better know that in three months than in ten years after you put your gloves on for the first time.
So, MVP is a reality check done the quickest and the cheapest way. It’s not actually cutting functions, but ensuring they are needed before you spend time and money on those.
REALITY CHECK AND REAL CHECKS
The MVP-centric approach grows popular as marketing skills become commonplace for entrepreneurs, no matter which is their sphere. TTM is the reason for that. TTM, or Time-to-market, is one of the key metrics for a new product. Time is always money, but when the market launch countdown is ticking, every minute costs you cash in many ways.
You want to pay for what others will pay for.
With all the research and insight behind it, the great idea your new product is based on is still a hypothesis until proven. It’s not like you already know the market craves your product, but you assume it is. There are no other means to make this hypothesis a fact but to check it on real customers. The earlier you hit the market, the quicker the feedback is on what would make your product more desirable.
Your product might be lucrative, but before it is in the market, it earns nothing.
With all the variety of monetization models available today, your product may be able to generate revenue long before it’s done and ready. Think of World of Tanks, the videogame that earned billions while being still in beta, or of all the mobile apps that are paying back the investments made. Ad-supported or subscription-based, bought in a one-time purchase or enhanced via microtransactions, your product might add some green lines to your bank account report as soon as it can deliver any value to your clients.
And yes, while the scope is small yet, you are safer in your experimenting with monetization models per se. No matter what, your missed revenue numbers will be the least frustrating.
Think of almost every successful software product. Yes, even the hardcore enterprise one would work. They never start as a one-size-fits-all solution, but as a demanded yet simple tool designed to perform a specific task.
Take a turn before you’ll have to brake for that
Developing a complicated product before learning you have to adjust it to the market is not only about losing money on features discovered to be undemanded. The more had been done before a pivot, the more has to be done to perform one. You only have to remove seats and add panels to make a cargo van from a microbus, but should you try turning a Corvette into one, you’ll end up building it from scratch.
OK, are there any real-life MVP cases?
Telegram grew popular before it got the channels, stickers, secure calls, and bots. In the beginning, all it had was a boringly simple messenger with awesome encryption. It could do less than competitors, but it could keep your communication secure. MVP? Betcha.
SAP, the first ERP software coming into one’s mind, started from a pretty simple accounting system, which didn’t sport even 10% of what it has now. The term MVP was not even coined in by that time, but in fact, that was it – a basic solution, offering a new approach on quite a limited scope.
Zappos, the mid-2000 iconic apparel e-store began as a guy buying footwear on your demand from regular stores and sending it by mail. As simple as that.
Moreover, an MVP may prove an idea before you spend zillions on can even become a business even before you expect them to do it!
Dota and Counter-Strike, as lucrative as they are now, began as community mods for popular games (Warcraft III and Half-Life, respectively). No ginormous teams of developers, designers, and community managers, no weekly content updates or events: they offered the very basic setup needed for a new gameplay pattern. A Minimally Playable Product.
HOW TO SCOPE AN MVP?
There is a mnemonic rule designed by Eric Rice, the author of the famous “The Lean Startup”: you take your first idea for an MVP, then cut that in half, and cut it in half again – and there you got what actually is an MVP.
For those hesitant on cutting, here’s another – not that brutal – rule of thumb we nurture here in Fora Soft. You have to ask yourself three questions.
What is your favorite part of your big idea?
What do you need to use it?
If you had only 30% of your budget, what would you make first?
You may even put your imaginary budget threshold lower than that, until what fits it retains the uniqueness of your product and the very basic usability. Once you understand that you can’t push it down anymore, you got the MVP.
If it is still a complicated task like it may be, as you definitely love your idea, you can start with MVP-izing actual projects. Try to think about what makes Instagram, Google Docs, or your favorite game what they are. Take a shot on imagining they didn’t have all the features they boast now. Where is the border between “I’d go without this feature” and “Oh, it won’t be useless anymore”.
QUICK. CHEAP. DIRTY?
Once you develop a vision of your product’s MVP, you start revving your engine. Time is money, so you want your Minimum Viable Precious right away.
Setting your step towards the MVP on your own is where you might run into a dilemma. On one hand, coding or testing in a rush never results in good code. On the other hand, the MVP stage is somewhat forgiving to the code quality — if it works, it works.
It’s up to you to find the balance between those, but the golden rule is: no matter how much duct tape is there under the hood, the user experience for the killer feature should be streamlined and lovely. Whatever buggy and irrelevant to the key functions should be demolished mercilessly. Whatever is crucial and buggy should be a priority.
AND WHAT IF THEY COPY IT?
Well, everyone remembers the copycat cases – it happened to the MSQRD app, who’d had its minute in the limelight before every competitor got their own masks. Or Snapchat with its fading posts, which turned to be a fading fad (pun intended).
That’s the concern faced by everyone taking (or sugging taking) the MVP path. If there is a killer feature, isn’t delivering a quick-and-basic product the simplest way to unwantedly hand it to bigger competitors, who’d wrap it up in glossy paper and grab your market in no time?
The short answer is yes. It is. If your killer feature is that great, all the big companies gonna copy it. Or release their own renditions already being in development. But the first one to release is the first one to win the audience — and is able either to retain it, entering the top league (like Zoom or Miro, the COVID-era superstars whose leadership is yet to be shattered).
And even if the blue chips roll out their own, more refined solutions… Remember what happened to MSQRD? Facebook bought it. For a much bigger sum than they invested in development.
SO, WHY SHOULD I CUT FEATURES AND LAUNCH MY PRODUCT EARLY?
To check your idea and be able to refine it before there’s too much money spent;
To make the audience like your product before it is even totally complete;
To start earning before you’re done spending;
To make your product become a synonym to its killer feature.
Can Fora Soft help you with an MVP?
Most certainly! On the MVP stage, it’s not just skill but experience that matters. A developer with a massive background in a certain area (media processing, streaming, and low-latency solutions in our case) is a shortcut to an MVP. Our developers, absolute pros cut the time-to-market, as they already know solutions for typical time-guzzling problems. Please, feel free to contact us via the Contact form, and we will get back to you right away!
Imagine that a Project Manager has approached you with a question “how is the testing going?”. We will let you know how and what to answer in this article.
An inexperienced tester will dive into numbers straight away, and his answer will sound like this: “Why, everything’s cool. I’ve completed 234 test cases out of 500. 16 automated tests out of 100 have gone down”. This here is a bad answer. Dry numbers with no context whatsoever do not reflect the state of the product, thus, useless. They do not help the manager decide what to do next and how the team should proceed.
An experienced tester has to provide his team with useful information that will help assess risks correctly and set up the priorities.
How to present information?
At Fora Soft, we present the useful information in this order:
Explain the state of the product. What serious problems we’ve encountered, why they are serious, and how they can affect our customers. This information helps the team understand what to deal with first
Explain how the testing is going. What still needs testing, what has already been tested, what we will not test and why is that. It’s important to mention how the testing was being done, what environment was used and why. This data is mandatory to assess the risk of receiving problems in the untested product areas and correct the testing plan, should the need arise
Explain why we test the way we do it. Why the tests we’ve chosen are more effective than those we haven’t. When time and resources are limited, it’s crucial that we choose the right testing areas and sort out priorities
Let the team know about the problems we’ve encountered during testing. Namely, what makes testing harder, what may cause us to miss bugs, what could help us make testing faster and simpler. If your team knows about your problems, they can help you
The main task the tester has is finding problems that put the product’s value in danger and reporting on those problems to the project manager and the team. Providing this information in a timely manner allows creating a high-quality product without missing deadlines.
To catch any problem that endangers the product’s value quickly, we use test plans and test strategies. Stay tuned to find out how the plan and strategy are created!
Do you want to learn more about our processes and how we do things? Do not hesitate to contact us via our contact form! It is right here 🙂
Let’s take a look at how to estimate a video streaming platform after the launch.
The combined cost is based on the cost of traffic, data storing, and the server itself.
Traffic – the information that goes through our servers. In general, it’s audio and video streams. As a rule of thumb, services require way more money for the outgoing traffic than for the incoming traffic. So, we will only concentrate on the outgoing traffic here
Data storing – storing video conference recordings. You can store them on a rented server if there is not too much data. Otherwise, you will have to pay specifically for storing data
The server itself is the computer with the project. Usually, its rent costs a specific monthly amount. When one server isn’t enough because of too many users, people would use many servers instead. More on that later.
Counting the traffic costs is the first task as it is one of the main expenditures on video streaming services. To complete it, one must calculate the amount of traffic that will go through our server within a chosen period of time. We will use 1 hour.
There is a convenient website to help us calculate the size of video files. How to use it? Insert the video resolution, duration, and FPS. You can compare terms such as 480p or 4k against “real” ones here.
You will see a sheet that might look difficult to understand, but it’s not true. Just search for Video File Size. This sheet has possible sizes that our video will have after using different compressing algorithms. For simplicity’s sake, we’ll use the compression YouTube uses. It is easy to realize and WebRTC video compression is close to the one we went with. The price will increase drastically if we decide to go with a lesser compression. Using more powerful compression may result in losing quality. It all depends on what our goal is. We will still be using YouTube-style compression as an example, and the amount of traffic we get in result will correspond to a one-way video stream.
For 1-on-1 chats, there will be 2 streams. If there are 1 streamer and 20 viewers – 20 streams. 2 streamers + 50 viewers – 100 streams (each of the 2 streams is sent to 50 viewers) or 102, if streamers receive streams from one another. Now, since we have the amount of traffic for a period of time, we need to multiply it by the price of our provider set. By the provider, we mean AWS, DigitalOcean, or our telecom provider if the servers are within our reach.
We only look at the outgoing traffic. That’s because the majority of providers offer either free unlimited incoming traffic or set such a low price that it’s not even worth checking here.
So, here is our traffic price. However, it’s just one third, so let’s move on to…
Price for storing data
If you don’t keep your stream recordings, feel free to skip this section, as the price that doesn’t concern storing video content is very low.
So, you need to keep video recordings on your server and you don’t know how much it will cost? Let us help you. Get the video size per one stream from the previous section and multiply it by the number of streamers. Multiply the result by the price for storing data on your server (calculate the price of HDD/SDD if that’s your private server).
So, all we have to do now is counting the price of keeping and supporting the server.
The server itself
Media server price
If the project is going to be somewhat loaded, you will have to pay for the hardware that sends out your streams. The amount of servers depends on the load, and they all have to be paid hourly. If you know the cost, perfect. If not, try adding something like $0,3 per hour (this is an average price for some Amazon EC2 category c5 servers)
Price for a reserved server
It’s more likely that your project will have at least one more central server with the main website on it. One would usually pay a fixed monthly amount for it. It’d be amazing if you knew how much your server cost. If you don’t, feel free to use the market average as of now – $30-$70 monthly. If it’s a simple landing without added functionality, $15 will probably do. However, if that’s a good website with an account room, video conference rooms list, text chat, notifications, and a stable online amount of more than 100 people daily, the server will cost more (from $50).
Take a 9-max meeting room. We’ll go with 640×480, compression algorithm equivalent to YouTube’s, 30 FPS (in the calculator this goes as 29.97), Amazon AWS c5 xlarge servers. Don’t forget to swap seconds for minutes!
Let’s calculate the traffic costs. Use the calculator and fill in the resolution and FPS. Check the result – 1 hour of a one-way video will take 639 Mb. Every user receives 8 streams from other participants. Therefore, we have 9*8=72 streams like that.
We get 46 GB per hour. Since we use Amazon, the traffic cost is $0,09-$0,01 per GB, depending on how much traffic was used up in the current month. In order to get to $0,01, we will have to use an immensely huge amount of traffic (40 TB), so we will use $0,08 for calculation. 46 GB by $0,08 is $3,68/h.
Let’s say we want to store the video; the size of 1 hour is 0,639 GB. We want to keep the video streams of all 9 people. The server will keep one video where other clips will be combined in one grid. Therefore, it will still take 0,639 GB. We use General Purpose SSD by Amazon S2. It costs $0,1 per GB, monthly! Therefore, we have to pay ~$0,06 for each hour of our videos each month they stay on our servers.
Amazon AWS c5 xlarge server costs $0,17 per hour. Add it to the traffic cost. Therefore, we get $3,85 as a cost for each hour of active meetings, and on top of that, $0,06 monthly for storing 1 hour of meetings.
If we want to imagine how much it will take us, we are going to need at least approximate numbers of streams daily and monthly.
Let’s say we have 4 hours of meetings like that in a day. Assuming there are 30 days in a month. we multiply 4 hours by $3,85 to get the service cost per day – $15,4, which we then multiply by 30 to find out the monthly cost with 4 hours of meetings daily =$462.
Let’s assume that we allow storing up to 100 hours of video. Add $6 monthly.
Amazon c5 large is our main server. It costs $45,99 when reserved.
To sum up all our approximate estimations for a month, we’ll pay $513,99.
Webinar with 2 streamers and 50 viewers
We keep the similar parameters: 640×480, compression algorithm equivalent to YouTube, 30 FPS, Amazon AWS c5 2xlarge servers.
The stream will still be 639 MB per hour. Since each streamer streams for 50 viewers, we have 100 streams – 63,9 GB per hour. The average cost of traffic stays at $0,08 per GB. 63,9 GB * $0,08 = $5,11 per hour.
We are not storing this video, but if we were, it would have been just 1 stream (we have 2 streamers, so we store them in the grid as 1 video), so it’s still 0,639 GB per hour. With the price of $0,01 for an hour, we’d get $0,05112 per month, for each hour of stored video.
The final result is $5,11 for an hour of a stream or $0,05112 per month for each hour of stored video, should we ever need that.
We’ll reserve Amazon c5 large as the main server. Its cost is still $45,99. So with the server, the cost is $1599,59.
1-on-1 video chats via p2p
We can tell from experience that one c5 large server can maintain more than 1000 simultaneous 1-on-1 video chats via p2p. We’ll be using that server. In this case, the traffic cost is minimal because we just help two users connect with each other. We don’t send any video streams through our servers. Nor does our traffic go through the server and we don’t need to calculate it. The price is negligible. We don’t store recordings, too.
The servers cost $0,17 per hour. For the insurance measures let’s imagine that we get a new server up each time we get 1000 people.
The approximate price for a month if we have up to 1000 chats every day, and they last for 8 hours. 0,17*8=$1,36 a day. Multiply that by 30 to get $40,8 a month.
The server we reserve is Amazon c5 large. With added $45,99, we have to pay $86,79 monthly.
According to Businessofapps, mobile apps become more and more popular. They offer more functions that are in need of testing. This is a crucial process in development. No one wants to use a lousy app that keeps crashing or working bad, right? Also, what if there’s a payment function in an app? Working with a product that can let you down when you send money somewhere isn’t a good idea.
To improve the quality of an app, we need to test it. It’s believed that the developer’s eye eventually starts swimming and they can miss some problems. So, we have testers for that. To increase the speed of testing and implement a system in it, testers automate the process.
Let’s take a look at testing automation using iOS apps as an example. Nowadays, mobile apps have way more functionality than before, so testing takes more time, too. And don’t forget that there are many kinds of iOS devices out there, which increases the time spent on testing even further! To guarantee that an app works correctly on all devices, many tests need to be done, which makes the process longer and more expensive. Testing automation is out there to deal with it because testers won’t need to check some functions manually. It’s enough to write a script and edit it from time to time. Sounds good, doesn’t it? Nothing is perfect, though, so let’s turn to the pros and cons of this method:
Concurrent testing on multiple devices
Faster testing process
No human factor. Sometimes, bugs might appear that are difficult to catch. Even if a tester is able to catch those, they can not always understand what the cause was. Automated testing may help with the precision of understanding
Testing transparency. When the testers swap, old scripts stay, and the testing process will continue as intended. Regression testing stays the same, too. If you need to change something, or if a new tester wants to check the application logic, the script will work as documentation. This is one of the main advantages
When iOS updates, you have to wait for the automated testing tools to update, too
The tester needs to have special knowledge about automated testing scripts. The company needs to teach employees to do that or hire more expensive ones
The auto testing tools have pros and cons about them. It’s difficult to find a perfect tool, and oftentimes you need to sacrifice convenience in working with a tool or with its possibilities.
When you need automated testing
Do you even need it? The answer is “yes”, if:
Your app has too many functions and features, and you are going to support it while adding new things along the way. Why do you need auto testing then? New functionality can conflict with the old one. For example, you’ve introduced a chat and calls broke. To find out the problem, the tester has to test the whole app manually. It takes a lot of time, and the tester is at risk of missing something else! Auto testing helps avoid that problem, as the tester won’t have to test everything after introducing each feature. Whatever stayed the same will be checked automatically, as long as you launch them and then collect the data. It helps reduce the testing time and the development costs
You are going to adapt the app for each new iOS version and take advantage of new system possibilities. Every iOS update can break something within the app. Even if you never planned to update the app in the near future, it might be that you have to. In that case, automated testing will help with that. After that, you’ll understand what it was that broke and be able to solve the problem. Obviously, you wouldn’t add automated testing with this sole purpose, but they will help a great deal if they are already implemented
There are testers on your team that possess some knowledge of automated testing. They at least have to know some popular programming language if you go for, say, Appium. Or, they have to know Swift if your choice is XCTest / Earl Gray / KIF. Testers also need to know all the possible testing methods and needed tools. If your employees only know how to manually test apps and have no knowledge of programming languages whatsoever, you will either have to teach them or hire new ones
However, writing automated tests is programming, although you’re not writing new functions for your app but rather a program that goes through your product and checks it. It is expensive. It won’t be worth it to add automated tests if:
The app is small. It doesn’t have lots of functions and it is easy to test it manually. With that being said, you are not planning on adding new functions on a constant basis
The app is supposed to be developed and distributed within a short period of time, such as those for the World Cup-2018 or the Olympics-2014
The app changes frequently. The functionality is unstable. For instance, a startup that looks for its client and keeps changing the main features
Tools for automated testing in iOS
After finding out the main advantages and disadvantages of this approach, let’s take a look at the tools.
Apple developed a fully native tool that is out there only for testing iOS apps. Since it is native, external dependencies won’t be there. You develop tests in Swift or Objective-C, which helps developers and testers interact more effectively. However, developing in those languages isn’t that simple. It might be that testers will turn to developers to ask for help far too often, which will make work a bit chaotic.
There is a test recorder, too. It records real actions with an app and creates a test out of them, but using it is actually quite hard. It isn’t very accurate and it’s best to use it as an assisting tool while developing main tests in Swift or Objective-C. XCUITest/XCTest also works in a separate stream, doesn’t read the state of an app. Therefore, delays in updating the data may lead to an impossibility of seeing requested elements.
The Framework by Google. It requires tests in Objective-C or Swift. The framework synchronizes requests, UI, and streams – that’s the advantage of it. However, EarlGray isn’t very popular because you can only test iOS apps with it. It isn’t very different from XCUITest, yet it is not native, so testers would rather use XCUITest.
KIF is a framework that has to be added to the project to use it. Objective-C or Swift are the testing languages. Its realism is its main competitive edge. KIF can simulate interaction with a user, therefore it’s very good for UI testing.
You see the iOS-only tools above but when mobile development is in question, oftentimes the developers go for both iOS and Android apps. So no wonder there are cross-platform tools for automated testing.
Appium is the most popular tool nowadays. It allows testing apps regardless of the platform, type, and system version. Writing tests for each platform is possible using unified API, without transforming an app into a special, network-compatible kind. Appium doesn’t require adding to the app source code. It’s working as a separate tool. Let’s take a look at its advantages:
A big number of languages for tests: Java, C#, Python, Ruby. It means that Appium doesn’t only work with Objective-C or Swift, so all testers will be able to create tests
An app doesn’t need re-compiling or changing it for automation’s sake. It’s important because the test source code and the app source code aren’t in the same project, and they are developed separately. These two don’t depend on each other, so one can avoid many problems. For example, if somebody wrote the tests incorrectly and they don’t compile, it won’t affect the app in general
It is cross-platform. The testers can develop tests for iOS and Android in the same environment, in the same language. They can even re-use the code. It saves time and money
Wide functionality. You can launch and stop the app, check the visibility of elements on the screen, and use gestures. Simulator and real devices work with Appium
Appium has some disadvantages, too. It is essentially a superstructure over native iOS and Android drivers. The tests can break more often due to the mistakes in the superstructure code. It’s important to notice here that Appium is very popular, develops quickly, so arising problems will be likely solved in the future.
Automated tests gain popularity in mobile development. They have advantages and disadvantages. Introducing automated tests is worth it when the benefit outweighs the costs. It is not magic, it’s still development, but you’re not developing new functionality but the ways to test the old. If an app has many functions and you keep updating it, but the majority of functions stay the same with each version, take a look at automated testing. After spending money once, you will save more later on.
Testers won’t have to test everything manually with each update. You only changed the teacher’s profile, but all courses, login, payment, booking, admin dashboard have to work the way they did? The automated tests will have to work for it then. If they didn’t, it means that your small update broke something, now you have to figure out what. If the tests went through – be happy, because the tester will only manually check the teacher’s profile instead of the whole functionality.
We took a look at the tools that enable automated testing. It’s worth saying that we didn’t talk about all the tools out there. There are still paid, unpopular solutions or solutions that are not supported by the developer anymore. Whenever you choose a tool, consider the application’s peculiarities, check if there will be an Android version of the app. Also, consider your tester team! 🙂
We at Fora Soft also use automated testing for some of our projects and find success with it. Do you want to learn more about this topic? Message us using the Contact us form!
In this article, we will explain how Fora Soft hires people. What an iOS developer should know and what interview stages they complete. Besides, you will also find out about how we carry out the mentoring process and how programmers progress.
Minimal hiring requirements
A developer should know:
OOP. This is a programming methodology based on representing a program as a combination of objects
Swift, Obj-C (reading the code). Swift is a programming language developed by Apple, and they use it to write programs for all their products. Obj-C is a previous language that Apple used for the apps. Even now one still can create objects with it but people mostly use Swift. However, one needs to at least read Obj-C, as older projects are written in it, and they need support
iOS SDK. Knowledge of main frameworks, such as UIKit (work with graphic representation), Foundation (work with network and date), AVKit (work with media), MapKit (work with maps), CoreLocation (work with geolocation)
Apple Guideline. For an app to be approved for AppStore, it has to answer Apple’s requirements. Read Apple documentation to find out more
AutoLayout. This is a mechanism for page-making in the app, it is responsible for placing interface elements on the screen
Multithreading. It’s important for an app to complete many processes simultaneously. For example, to make a request into a network and show the data loader
SOA (REST API, Web Socket). To work with the network, one must understand its organization
Git. The version control system is out there to make the project work easier and make it possible to put a group effort into it. Besides, it allows keeping several versions of the same document. It’s also possible to return to earlier versions, determine who and when made a change, etc.
The selection and recruitment process
It consists of
A candidate sends their CV to an HR
HR looks at the CV and calls the candidate if the CV meets the requirements
HR speaks about the company and answers questions. Then an interview happens, where HR tests the candidate’s professional qualifications. The questions are related to the specific position.
If the candidate answers the questions successfully, he is invited to join the next stage – a technical interview with an HR and team lead. The lead does the talking here. He asks not only about the job itself, but about the IT world as well. It’s important to know how well-rounded the candidate is. The HR then conducts an office tour
We invite almost all candidates who passed Step 4 to complete a test assignment within a week
The candidate sends the assignment, which the team lead reviews and sends feedback to the HR. Here the decision whether we invite the candidate to the final interview arises
The CEO attends the final interview. The candidate receives some specific assignment, for example, developing a video call system. The candidate has to explain how they’d like to proceed with the task
We send an offer
When I find an employee who turns out to be wrong for the job, I feel it is my fault because I made the decision to hire him.
Akio Morita, Sony founder
As you can see, Fora Soft takes the hiring process very seriously. Let’s take a look at the statistics that the HR department has provided.
20% pass the phone interview – 100 people
40% pass the face-to-face interview – 40 people
30% complete the test assignment and the technical interview with the team lead – 12 people
90% pass the final interview with the CEO – 10 people
50% complete the phone interview – 25
20% complete the test assignment and the technical interview with the team lead – 5 people
20% complete the final interview with the CEO – 1 person
To sum it up:
We send an offer to 1 iOS developers out of 50, which is again 2%.
We just showed you the numbers. Go with any output you deem fit 🙂
The mentor is responsible for:
Code review. The new programmer creates a separate branch for it, according to Git Flow. Upon completing the task, the new programmer makes a merge request, and the mentor checks the result. The good mentor will pay attention to the logic behind completing the task, leave their feedback, and send it back for the refinement. If the mentor is satisfied with everything, the merge into the development branch happens. Thanks to this mechanism, it’s possible to see how the new programmer progresses. Over time, the number of comments goes down, and the code immediately ends up in Develop
Meetings about the developer’s weak and strong suits. After some time, the mentor will form a professional portrait of the new developer, based on the code, approach to tasks, and other teammates’ feedback. As soon as the portrait is ready, the mentor and the developer talk about everything. These meetings happen quite often, approximately once a month
Informational basis (Q&A). The new developer can always ask a mentor for help
Task distribution. The mentor determines what the new programmer can do now and what is too early for them. The difficulty of assignments grows as the developer grows
How constant development happens
Development plan. Every developer creates the plan of the aims. What is it? We take a period of time and create goals for each month. For example, read book X, learn technology Y, watch conference Z. Upon the completion of each milestone, we put a mark. That way it’s easy to see how the developer progresses
A gradual increase in task difficulty. The mentor gives tasks to the developer depending on their difficulty. The good mentor will never assign something the new programmer can’t complete. Over time, the difficulty grows
Lectures within the company. Anybody can host a lecture. Found an interesting technology? Learn it yourself and let others know!
Collective meeting attendances. We keep an eye on the IT world and meet-ups in other companies. We attend those events together, and then create a short review on them
From the statistics, one can understand that we have very high requirements for candidates, and there’s a reason.
The team guarantees the high quality of Fora Soft products. First, we make hiring decisions carefully. Second, this is a culture of constant development. We keep a close eye at new colleagues and their code, help them find themselves in the company, level up their skills.
Thanks to that, our products have such high quality.
You have to love your work. To do that well, you have to enjoy your work. We at Fora Soft are driven by that desire – do things awesomely. We realize what kind of a person is and whether we pursue the same goals during interviews. We never leave a new employee to be eaten by projects. We are always close to guide, give advice, and just look after.
With all that said, our clients are always happy, which makes us happy, too. We created a cool product and made the client happy? The end-user is also happy because of what we did? That’s the goal we pursue.
People frequently come to us with a request to create a text chat. Some of them want a messenger with a chat being the main or the only function. Others need to add chat into different projects, such as telemedicine. In this article, we’ll take a look at the most popular options for chat creation.
All solutions for chats can be split into two categories:
Ready-made chat platforms, such as Firechat, SendBird.
They have prepared functionality for main chat options. The developer needs to put a small effort and time to add a chat into an app or a website. But the behavior of functionality has strict borders by a platform creator, and possibilities for customization are limited.
Technologies for exchanging data between client and server, such as Firebase Cloud Messaging, Node.js + Socket.io.
They allow building a very flexible chat solution upon them. Those technologies take time to implement but offer unlimited possibilities for customization.
All the four solutions are cross-platform, they work on the web, iOS, Android.
Firebase Cloud Messaging
Firebase Cloud Messaging is a platform for information exchange between a mobile app and a server. It’s widely used for notification send-out, and it can be used to build a chat on its foundation.
Free for products with up to 100 simultaneous users.
As a Google product, one can expect stable work when used correctly
With comprehensive documentation and high popularity, developers can find any answers quickly, which saves time and money
No need to buy an additional server, you can do everything on the Firebase server
Thanks to the Firestore database, the servers will automatically come into existence or be eliminated when they are not needed, which will save you a ton of money. Node.js and socket.io will make you create scaling separately
Data is cached by default and is available for search in chat offline
Difficult search inquiries are difficult or impossible to realize
For example, inquiries like “find all messages with “Hello!” that a user received last year from all users whose nicknames start with an A”.
The thing is when using Firebase Cloud Messaging, you are limited in choosing a database. It’s either Firebase Realtime Database or Firestore.
Firebase Realtime Database is a NoSQL database, where data is stored as JSON. It has lots of advantages compared to traditional SQL databases. The possibilities for creating a new search inquiry are limited by a developer to keep productivity levels.
To deal with that problem, Google came up with the Firestore database. It’s a NoSQL database but its search and data structuring possibilities are vastly increased. However, difficult search inquiries still pose a bigger problem than those in SQL databases or NoSQL databases like MongoDB. Some of them are impossible, others will take much more time to develop.
Up to 200k simultaneous users in Firebase Realtime Database, up to a million in Firestore
Firebase Realtime Database is limited by 200k connections in the database. It’s roughly the same as 200k simultaneous users. Firebase developers think out of 10 million active app users there are 200k of those who would use the app at the same time.
Firestore offers up to a million users at the same moment.
When using Firestore, the cost is determined by read/write operations in the database. The more data is there, the more expensive it will be. For instance, by Firestore calculation, a small up (50k installations and 5k active users daily) the usage cost will be $12-14 a month. For a big app (10 mil installations with 1 mil active users daily), the cost will be $2951,52 monthly. There are borders within which Firestore is free to use.
With Firestore Realtime Database the cost is determined by the amount of data stored in a base and downloaded from there – approximately $5 a month for each stored gigabyte and $1 a month for each downloaded gigabyte.
Therefore an app that processes many read/write in the database operations, it will be cheaper to use Firebase Realtime Database.
The most profitable option would be to use Firebase Realtime Database for one type of data and Firestore for another.
For example, for a typical e-commerce app, operations that involve reading a list of goods will run every time a user opens the app, and the number of operations will grow as more people use it. The size of the list, however, won’t depend on the number of users. For an app like that, the most profitable option would be storing the list data in Firebase Realtime Database (to not pay for multiple read operations), and storing the user data in Firestore, as storing 1 gigabyte of data is cheaper there (source).
Using Firebase Cloud Messaging is free itself, which means that you only pay for using the database, hosting, and authentication.
Works slowly when searching offline
In Firestore, if there are hundreds of documents in the base, the offline search will be slower, which will worsen the UX. For instance, in a chat with a hundred channels, when you have to find one without internet access, the search will work noticeably slower.
The developer needs experience working with NoSQL to build a convenient and effective database structure
Firestore has a limit of 1 write operation in a second for 1 document. The document is a structural part of a Firestore database. The Firestore database consists of documents organized in a collection. The document is practically a set of “key-meaning” couples. It is actually a flexible limitation: if you go for 10 read operations at the same time once, Firestore will process them correctly. If, however, you keep sending thousands of requests into the base at a rate of more than 1 per second, Firestore will return errors for some requests.
Firechat is a framework for chat creation, and it was made by the Firebase team using Firebase as a foundation. Firechat uses Firebase for authorization, sync, storing data. Firechat provides API for a chat, that allows user authentication; forwarding messages, images, and files; group chats creation, sending out invitations. Here are the links to their official website and project code.
Saving time and money on developing
A ready-made API for the chat main functionality allows not to create a realization of those functions by yourself
Same advantages as with the Firebase Cloud Messaging
Not all functions are possible to realize
If you use a ready-made API for the chat functionality, you can only realize the functions in offers. For instance, it doesn’t support showing unread messages, deleting messages, and has a limitation of 100 users in the chat group. The full functionality list is difficult to find, but you can get an impression by their API methods here
Same disadvantages as with the Firebase Cloud Messaging
Firechat only uses Firebase Realtime Database from the box. There is no choosing a database, like in the Firebase Cloud Messaging, Firebase Realtime Database, or Firestore.
Sendbird is a ready-made chat platform. It offers a multitude of prepared features, including an indication of the number of unread messages, blocking users, and admin dashboard.
Lots of features are already realized and work right away: message or file exchange, invitations, users blocking, typing indication, editing messages, automatic translation, admin dashboard, group chats for up to 100 users
A ready-made UI with limited customization possibilities
Creating a UI and its design isn’t necessary. Sendbird offers standard UI options, which you can use as is. You can also apply your own design on top of the standard one, changing the color and form of chat components. So, we can simply add Sendbird with default settings into our product and get a char with a default design. Then, customize some components whenever the need arises.
You don’t need to worry about having too many users so your server doesn’t catch up to the number of requests, New servers will create themselves. Sendbird supports more than a million simultaneous users. It uses AWS.
You can’t realize all functions
Chat and functionality behaviors are strictly set. A user logs in and gets access to a list of channels. They can choose an existing channel or create their own. Channels are either public or private. Users can exchange messages in either one.
This is the standard structure for the majority of chats. If you need something more exotic for your product, it will be really problematic to realize that with SendBird. Some functions are outright impossible to implement, others can take much more time than if they were created from scratch, for example, with Node.js and socket.io. For example, you can’t create threads to answer a message, like in Slack.
Not all available functions can be realized the way you see it
SendBird provides more customization opportunities than it seems. There are serious limitations, too. For example, SendBirds allows storing additional information about any user, but not more than 5 parameters. Let’s say, those will be a name, last name, city, sex, weight, eye color. So, it is not nearly enough for dating chats
Not as popular as Firebase and Socket.io
Popularity is an important metric when choosing a framework. The more popular a framework is, the more developers using it are out there. It helps get important resources, support, answers. If other pros and cons are equal, this will help make the development faster (and cheaper if you pay for time)
Depends on the number of users. The base package costs $400 monthly for 5k active users. With 100k active monthly users, the price will go up to $5000. Or even $7600 if you also want automatic message translation and advanced moderation. For products with more than 100k users, the price is decided individually. There is a 30-day trial period
Node.js + Socket.io
Server platform Node.js, going with the real-time data exchange library Socket.io helps build a chat with unlimited customization possibilities.
Allows realization of any functionality
The developer has full control over all components: interface, logic, and server data and endpoint can be whatever is needed. For instance, it helps organize threads to answer chosen messages, which you can’t do in SendBird. You can implement message deleting, which is nowhere to be found in Firechat.
Provides an opportunity to realize automatic scalability that depends on the load. It’s possible to do on AWS and other ready-made solutions, such as Oracle. However, scalability isn’t provided right away, it has to be developed by a programmer.
You can choose the database type that suits your product best
For instance, if in the future product you are going to realize many difficult search inquiries, you can choose the SQL database, instead of using Firestore or Firebase Realtime Database that don’t support these functions
The chat works quickly
Client and server exchange messages directly, which results in fast work. When you use Firebase Cloud Messaging, the message goes from your server to Firebase server, and only from there will it travel further to the device. It’s important to mention that, though, that if there is a 0,5s delay, it’s not critical for a text chat.
Free to use
Open-source free solution – you don’t have to pay monthly for this technology. But please note that you have to pay for a server rent, where your product is based. However, this cost is usually way lower than that of Firebase Cloud Messaging or Firechat. We will discuss forecasting server costs in a different article.
Requires more time and money, as the developer creates all functions from scratch
Not everyone can develop the chat. You will need someone with the relevant experience
To sum it up
Ready-made platforms will give you quick results because the functionality is already there. But you are limited to those functions.
Node.js and socket.io allow creating any chat you need but each function will have to be developed from zero. It takes time and money.
What to choose?
The first thing to think about, when answering this question, is what kind of solution fits you and your company best.
If your chat requires a minimum base functionality, you don’t have high level of requirements to it, then Firechat or a Firebase Cloud Messaging-based solution is the way to go
When you expect a chat to be more advanced, take a look at SendBird. Compare monthly payments to SendBird against creating a chat from zero on Node.js and socket.io
If there are a lot of requirements for a chat or you need lots of customized options, Node.js and socket.io are your friends!
Why at Fora Soft we recommend Node.js + socket.io?
Developing the chat functionality on Node.js + socket.io takes about 40 hours. Embedding and customizing a prepared one requires around 24-32 hours.
Ready-made chats charge you every month. It is more expensive than paying just for servers in the case of Node.js + socket.io. A little increase in the development costs is usually recouped in a few months.
In exchange, they:
Are not bound to any limitations. They can implement any functionality in the future
Do not depend on third-party components that developers can just stop updating someday, and your chat will stop working.
To find out more about chat creation, do not hesitate to contact us!