Categories
Uncategorized

How to report on testing

testing-meme
QA testing meme

The article is based on How is the testing going by Michael Bolton.

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:

  1. 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
  2. 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
  3. 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
  4. 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 🙂

Categories
Uncategorized

How to estimate the server cost for a video platform

Are you planning on a creating video software, such as video conference, webinar, telemedicine or elearning platform? Let’s see how much you’ll have to pay monthly to maintain it.

In this article, we’ll explain how to estimate a video streaming platform’s infrastructure cost. We’ll start with an algorithm and finish with examples. If you don’t have technical background, you can calculate using the examples.

How much does a month of a video program cost: calculation algorithm

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.
  • Data storing – storing video conference recordings.
  • The server itself is the computer with the project. When one server isn’t enough because of too many users, people would use many servers instead.

Traffic costs

Let’s start with the cost of traffic: with video streaming it’s more expensive than data storage and the server.

Let’s calculate how much traffic will go through our server in a certain period of time.

We don’t count incoming traffic, only outgoing. This is because most providers either provide unlimited free incoming traffic, or their prices are so low that they can be neglected.

To calculate the amount of traffic that will be consumed when streaming a video, you need to understand the size of the video file to be streamed. Let’s assume that a file of 1 gigabyte will consume 1 gigabyte of traffic.

You can use the table below.

Select a resolution. The right column shows how many gigabytes will be consumed per hour when streaming video in the selected resolution. The numbers are obtained with the help of a calculator. If the table does not have the necessary values, take the data from there.

Now that we have an idea of how many gigabytes an hour of video is, we need to calculate how many times the video will be downloaded from the server.

Suppose this is a streaming service and users watch the video on the site. Then, if two people watch the video, the traffic will be spent twice: the video will be watched 1 time by each user.

For services with one streamer and 20 viewers traffic equal to the size of 20 files will be spent per hour: the video will be transferred from the server to each of the 20 viewers.

In the case of a video chat for 4 people, the video size must be multiplied by 12. 4 people in the chat and each receives 3 videos of the other interlocutors from the server.

The size of the video multiplied by the number of downloads of that video from the server. Now we have the amount of traffic that is consumed per 1 hour of time. Multiply it by price per gigabyte of traffic provided by our provider: AWS, DigitalOcean. If the servers are physically in our possession, it can even be our ISP.

Voila, we got an approximate price for traffic. But that’s not all: there are still costs for video storage and the cost of renting the server itself.

Price for storing data

If you don’t keep your stream recordings, feel free to skip this section.

Storage costs for data that doesn’t include recorded video are usually so low that they can be neglected in the approximate cost calculation. We rent a server to host the site. A disk space of a couple dozens of GB, that’s available on the server, should be enough in most cases.

But if the data exceeds a few tens of gigabytes, it’s stored in a separate storage unit. It is paid for in addition.

Examples:

  • An app with a huge audience, like Instagram. They need extra storage, although they don’t store video call recordings because users upload a lot of photos and videos, and there are a lot of users.
  • Video conferencing application for a local bank for 3 branches, they store video conferencing recordings. They do not need additional storage: the recordings are stored at the same time in such a size that the server memory capacity of their site is not exceeded.

First, let’s calculate the size of files to be stored on the server. The algorithm for calculating the size of one video file is similar to the calculations above, but it doesn’t matter how many people view the file. All that matters is how many such videos to store.

Examples:

  • If you store a video conference recording for 4 people, you will need space equal to 4 video files – one for each participant’s video.
    You can combine all the videos into one and store it in an optimized form. The size of the files on the server would be 2 or more times smaller. But this feature needs to be developed, so discuss it with your developer.
  • If we store videos like YouTube, one file will be stored for each video. If there is functionality to change video quality depending on the user’s internet speed, one file of each quality will be stored.

Now take the size of one video, multiply it by the number of videos to be stored.

This value is multiplied by the price of storing GB of data on your server.

If it is your own computer, you can directly calculate the cost of HDD/SSD you will need to install there.

All that remains is to calculate the cost of renting or maintaining the server itself.

The cost of server

The server is the place where the program itself is located and where user data is stored. For small projects, 1 server can be used, and where there are many users, several servers can be used.

The cost of servers strongly depends on the type of project and the number of users, but you can use the tips below as an example.

In the early stages of project development, you can get by with one server for $50 per month.

If there is video conferencing or video streaming, it is advisable to have a separate server for the media server.

If there are many conferences, you can automatically create new servers on the fly for the duration of the video conference and delete them when not needed. They have a price per hour of use. If you know that price for your server, use it. If not, you can charge about $0.3 per hour for each video conference. This is the average price for the first few Amazon EC2 c5 servers from Amazon’s September 2020 calculator.

Examples of video software monthly cost calculation

#1: Video conference for 9 people

Traffic

Let’s take the resolution 640×480 – the optimal format for video chat (4:3) – the picture is composed and the face is in the middle of the screen.

According to the table in the “Traffic Costs” section above, this is 0.11 GB per hour. This is what 1 hour of video takes one way. A total of 72 streams will be sent from the server – 8 videos for each of 9 users.

Multiply 72 by 0.11 GB, you get 7.92 GB.

Traffic on AWS costs differently depending on the amount of traffic and where clients are physically located. For our approximate calculations, an average cost of $0.09 per GB will do. Multiply 7.92 GB by $0.09 and you get $0.71 per hour.

Storing

Let’s say we want to store video conference recordings. One video will be stored on the server where all other videos will be merged.

Let’s assume the new video will have a resolution of 1280×720 (this is enough to see everything) and will take 0.88GB according to the table.

We take the General Purpose SSD from Amazon S2 from Amazon S2. It costs about $0.1 per gigabyte per month as of February 2022. Multiply the video size in GB by the cost to store one GB (0.88 * 0.1), we get ~$0.088 for each hour of video. This will have to be paid every month that our video is stored on the server.

Server

Here you can take $50 for the server for the platform itself and USD 0.30 for each hour of server rental for the video conference itself.

A server that costs $0.30 can host 5 or more conferences at the same time, but for pessimistic estimates we can assume we have only one video conference.

The total cost is

  • $0.71 per hour for traffic.
  • $0.088 per month for storage of one hour of recordings
  • $50 a month for the server for the site and $0.30 an hour for renting a server for the videoconference itself

$0.71 and $0.30 can be added: both prices are for each hour of an active video conference. You get $1.01 per hour of videoconferencing.

How to calculate how much a month it will cost to maintain such a chat? You need at least an approximate number of videoconferences per day/month.

Let’s say we have 4 hours of video conferences a day. Multiply 4 hours by $1.01, you get the cost per day: $4.04. Multiply the cost of daily service for 30 days, you get the cost per month: $121.20.

To store all the recordings, we would need to store 4 hours * 30 days = 120 hours of video. We will pay $0.088 * 120 = $10.56 a month.

Let’s add up all monthly costs: $121.20 + $10.56 + $50 = $181.76

#2: Webinar with 2 streamers and 50 viewers

Let’s take 720×480 resolution – a suitable option for streaming. A good balance between quality and economy.

According to the table from the section “Traffic costs” above, it’s 0.44 GB per hour. That’s what 1 hour of video takes one way. There will be 102 video streams sent from the server – 2 videos for each of 50 users and 1 video for each streamer.

Multiply 102 by 0.44 GB, you get 44.88 GB.

Traffic on AWS costs differently depending on the amount of traffic and where clients are physically located. For our approximate calculations, an average cost of $0.09 per GB will do. Multiply 44.88 GB by $0.09 and you get $4.04 per hour.

Storing

We have two streamers. The server will store one video with videos of both streamers merged.

Suppose the new video will have a resolution of 1280×720 (this is enough to see everything) and according to the table will take 0.88GB.

We take the General Purpose SSD from Amazon S2. It costs about $0.1 per gigabyte per month as of February 2022. 0.88 * 0.1, we’ll pay ~$0.088 for every hour of video each month it’s stored on our server.

Server

Here we can take $50 for the server under the platform itself and $0.30 for each hour of video streaming.

In fact, a server that costs $0.3 can host more than one streaming session at a time and there may be more than 50 viewers, but for pessimistic calculations, we assume that we only have one streaming session. We will still have to use such a server for that.

Total costs

  • $4.04 for each hour of streaming traffic.
  • $0.088 per month for storage of one hour of records
  • $50 a month for the server under the site and $0.30 per server for each hour of streaming

$4.04 and $0.30 can be added because both prices are per streaming hour. You get $4.34 for every hour of streaming.

How do we calculate how much it will cost per month? We need at least the approximate number of streaming sessions per day or month.

Suppose we have 4 hours of streaming a day. Multiply 4 by $4.34 and you get the cost per day: $17.36. Multiply by 30 and you get the cost per month: $520.8.

To store all the recordings we will need to store 4 hours * 30 days = 120 hours of video. We will pay $0.088 * 120 = $10.56 per month.

Let’s add up all monthly costs: $520.8 + $10.56 + $50 = $581.36.

#3: 1-on-1 video chats via p2p

Traffic

In the case of p2p calls, all video goes directly between users, bypassing the server. Therefore, you don’t have to pay for traffic.

This is true when a p2p connection is technically possible to establish. It is not possible only in about 10% of cases. In those cases the connection will go through the server and not directly. So 90% of the calls will be free and 10% will have to be paid for. Let’s calculate how much exactly.

Let’s take the resolution 640×480 – the optimal format for video chat (4:3) – the picture is composite, and the face in the middle of the screen. According to the table in “Traffic costs” above, this is 0.11 GB per hour. This is what 1 hour of video takes one way.

In total 2 streams will be sent from the server – 1 video for each of 2 users.

Multiply 2 by 0.11 GB, you get 0.22 GB.

Traffic on AWS costs differently depending on the amount of traffic and where clients are physically located. For our approximate calculations, an average cost of $0.09 per GB will do. Multiply 0.22 GB by $0.09 and you get $0.02 per hour.

You should pay only for 10% of calls so 1 hour of video chat will cost $0.002.

Storing

We have 2 people in the chat. There will be 1 video stored on the server where the videos of these two people are combined into one.

Let’s assume the new video will have a resolution of 1280×720 (this is enough to see everything) and will take 0.88GB according to the table.

We take the General Purpose SSD from Amazon S2. It costs about $0.1 per gigabyte per month as of February 2022. 0.88 * 0.1, we’ll pay ~$0.088 for every hour of video each month it’s stored on our server.

Server

You can take $50 for the server and not take an additional server for video streaming, as the server for $50 will be able to handle more than 1000 simultaneous p2p chats.

Total costs

  • $0.0002 per each hour of video chats
  • $0.088 per month for storage of one hour of recordings
  • $50 per month for a server under the site

How do I calculate how much it will cost per month? You need at least an approximate number of video chats per day/month.

Let’s suppose we have 100 chats per day.

Multiply 100 by $0.002 to get the cost per day: $0.2. Multiply by 30 to get the cost per month: $6.

To store all the recordings you would need to store 3000 hours of video. We will pay $0.088 * 3000 = $264 per month.

Add all costs per month and you get $56 without all records and $320 with all records on server.

Calculations are very rough. We give them to get at least a rough idea of the cost of running a video program: it costs about $10 or $1000 or $10,000. If, after the calculations, your business comes out to 0 – do not start it. The margin should be substantial.

Have any more questions? Contact us using the contact form and we’ll get back to you with a response ASAP!

Categories
Uncategorized

Testing automation in iOS

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:

Advantages

  • 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

Disadvantages:

  • 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.

XCUITest/XCTest

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.

EarlGray

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

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.

Detox

JavaScript is a language for tests with Detox. It can access the memory and control ongoing processes. The framework works with emulators and real devices and uses native methods right on the device. It also uses EarlGray and is considered to be really good at testing apps written in React Native, because React Native uses JavaScript, just like Detox. It allows for writing the same tests for Android and iOS.

Appium

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.

Conclusion

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!

Categories
Uncategorized

What iOS developer should know. The hiring process at Fora Soft

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

  1. A candidate sends their CV to an HR
  2.  HR looks at the CV and calls the candidate if the CV meets the requirements
  3. 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.
  4. 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
  5. We invite almost all candidates who passed Step 4 to complete a test assignment within a week
  6. 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
  7. 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
  8. 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.

JavaScript statistics (relevant for 1,5 months):

  1. 500 candidates
  2. 20% pass the phone interview – 100 people
  3. 40% pass the face-to-face interview – 40 people
  4. 30% complete the test assignment and the technical interview with the team lead – 12 people
  5. 90% pass the final interview with the CEO – 10 people

iOS:

  1. 50 candidates
  2. 50% complete the phone interview – 25
  3. 20% complete the test assignment and the technical interview with the team lead – 5 people 
  4. 20% complete the final interview with the CEO – 1 person

To sum it up:

We send an offer to 10 JavaScript developers out of 500, which means 2%

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 🙂

Mentoring process

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

Conclusion

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.

Categories
Uncategorized

What Chat Solutions to Choose? Firebase Vs SendBird Vs Node.js + Socket.io

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:

  1. 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.

  1. 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.

Advantages:

  • 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

Disadvantages:

  • 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.

  • Paid from 100 simultaneous users

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

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.

Advantages:

  • 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

Disadvantages:

  • 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

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.

Advantages:

  • Many functions

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.

  • Scales automatically

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.

Disadvantages:

  • 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)

  • Price

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.

Advantages:

  • 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.

  • Scales

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.

Disadvantages:

  • 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!