Forem: Brocoders

Types of QA Testing: A Comprehensive Guide

yulyabrocoders — Wed, 02 Aug 2023 10:54:05 +0000

In the dynamic world of software development, ensuring the quality and reliability of software products is paramount. This is where Quality Assurance (QA) testing plays a pivotal role. QA testing encompasses a range of methodologies, techniques, and tools aimed at uncovering defects, verifying functionality, and validating the overall performance of software systems.

The global software testing market reached $45 billion in 2022, and keeps growing, being driven by the increasing demand for high-quality software, the rapid adoption of agile and DevOps methodologies, and the growing importance of ensuring security and compliance in software applications. Also, due to the increasing demand for mobile apps, many companies worldwide are expanding their focus on mobile testing, which is likely to supplement the software testing market growth.

This QA guide provides a detailed analysis of the various types of testing, exploring their significance in optimizing the sales funnel and maximizing customer satisfaction throughout the software development lifecycle. Understanding QA types will allow you to effectively identify and address defects, improve software quality, and deliver reliable products that meet customer expectations.

At Brocoders, we have extensive experience and a proven track record in the field of QA, enabling us to provide exceptional software testing services that enhance your QA strategy and deliver reliable products that exceed your customers' expectations. Keep reading to discover how we can help propel your business forward.

Understanding QA Testing

QA testing, short for Quality Assurance testing, refers to the systematic process of evaluating software products to ensure they meet the required quality, functionality, and performance standards. It involves conducting various tests, identifying defects or issues, and verifying that the software functions as intended. The primary purpose of QA testing is to improve the overall quality of software products and enhance user experience. It aims to identify and correct defects, bugs, and vulnerabilities, ensuring that the software meets customer expectations, performs reliably, and delivers a seamless experience to users.

QA testing also helps optimize software performance, mitigate risks, and contribute to the overall success of software development products. It is also crucial for maintaining compliance with industry standards and regulations, enhancing the software’s security and maximizing customer satisfaction.

QA, QC, and Testing. What’s the Difference?

Along with Quality Control or QC and testing, QA is essential to ensuring software quality. While the three terms are sometimes used interchangeably, they use different approaches to deliver a product of the best possible quality.

Quality Assurance

Quality Assurance is a broad term that focuses on preventing defects and ensuring that the development process adheres to established standards. It involves process definition, process monitoring, and process improvement. The goal of QA is to ensure the software development process is efficient, effective and meets quality objectives.

Quality Control

Quality Control involves activities that are performed to detect and correct defects in the software. It includes product inspections, testing, and the overall monitoring of the software development process. QC is applied to the finished product and performed before the product release. It is reactive and aims to identify and rectify defects after they occur.

Testing

Testing is a crucial part of both QA and QC. It involves the systematic evaluation of software to ensure it meets specified requirements and quality standards. Testing includes activities such as test planning, design, execution, and defect management. Its purpose is to uncover defects, validate functionality, and verify the software's performance and reliability.

All these three components work together to ensure that software products are high quality, meet customer expectations, and perform reliably.

Role of QA Testing in SDLC

QA testing plays a crucial role in SDLC by ensuring a software application's quality, reliability, and overall success. It acts as a quality gatekeeper throughout the development process, working closely with other stakeholders to identify and address defects, ensure compliance with requirements, and enhance the user experience.

In the early stages of SDLC, QA testers collaborate with business analysts and stakeholders to define testable requirements, ensuring they are clear, specific, and measurable. During the design phase, testers review design documents and provide input to ensure testability and identify potential risks. They also participate in peer reviews to validate the design's alignment with quality standards and industry best practices.

As development progresses, QA testers conduct various testing activities such as:

Unit testing;
Integration testing;
System testing;
Acceptance testing.

They run various test cases, identify and report defects, and collaborate with developers to ensure timely bug fixes. QA testing involves functional and non-functional testing, including performance, security, usability, compatibility, and accessibility testing, depending on the project requirements. Testers also play a crucial role in maintaining test environments, test data, and test automation frameworks. They continuously monitor and analyze test results, track metrics, and provide feedback to the development team and project stakeholders.

Incorporating different QA testing types in the sales funnel brings the benefits of improved product quality, enhanced customer satisfaction, and increased sales conversion rates. It also helps identify and fix potential issues early, reducing the risk of costly post-release defects and improving overall product reliability.

Types of QA Testing
QA testing can be classified into different types based on whether the testing is performed manually or automatically. Based on these categories, testing can be divided into the following types:

Let's take a closer look at some of the more common testing types:

Functional Testing
This is a fundamental type of testing that verifies if the software functions as expected and meets the specified requirements. It is widely used in both manual and automated testing approaches. Functional testing checks an app, website, or system to ensure that each function of a software application works as intended.

Performance Testing
Performance testing allows testers to check the system’s behavior under various workload conditions. This type of testing can be automated to simulate heavy loads and measure a software application's speed, response times, scalability, and resource usage. Performance tests help confirm the product’s stability and reliability and verify if the extra load will degrade system performance.

Security Testing
This type of testing assesses the resilience of a system against potential security threats and vulnerabilities. Security testing often combines manual and automated approaches. It aims at finding any potential flaws and weaknesses in a software system that could lead to the loss of data, revenue, or reputation of the company.

Usability Testing
Usability testing evaluates how user-friendly and intuitive an application is for end-users. During this testing, testers evaluate the learnability, efficiency, navigation, error handling, consistency, feedback, and accessibility of the application to identify any usability issues and improve the overall user experience.

Compatibility Testing
This testing type ensures an application functions correctly across different platforms, browsers, and devices. Compatibility testing aims to identify compatibility issues and provide a seamless user experience across different environments.

Regression Testing
Software regression testing verifies that changes or fixes in an application haven't introduced new defects or disrupted existing functionality. This testing type ensures that previously developed and tested software works as expected by performing functional and non-functional tests. Regression testing is an essential testing type in software development and maintenance.

Localization and Internationalization Testing
This testing validates that an application is adapted to different languages, cultures, and locales, enabling it to effectively cater to a global audience and meet specific regional requirements.

Accessibility Testing
Accessibility testing assesses the usability of an application for individuals with disabilities, ensuring compliance with accessibility standards. During this testing, testers check for compliance with accessibility standards and guidelines, assess keyboard navigation, screen reader compatibility, color contrast, alternative text for images, and other accessibility features to identify potential barriers and ensure that individuals with diverse abilities can use the application.

The table below outlines the advantages, disadvantages, and best scenarios for each testing type mentioned.

Final Thoughts

Incorporating various types of QA testing throughout SDLC is paramount to building high-quality software products. Each testing type serves a specific purpose, whether it is functional testing to ensure core functionalities work as intended, security testing to safeguard against potential breaches, usability testing to enhance the user experience, or compatibility testing to provide broad platform support. By integrating different testing types, organizations can identify and address defects, optimize performance, ensure accessibility, and enhance customer satisfaction. This approach not only minimizes the risk of post-release issues but also leads to improved product quality, increased sales conversion rates, and, ultimately, a stronger competitive advantage.

React vs. Vue.js. An in-depth overview of their main differences.

Oleg Goncharenko — Fri, 25 Jun 2021 09:09:31 +0000

Vue.js and React have lots of similar features. Although React is a library, it suits building the view of the single-page application the same efficiently as Vue.js.

Common features in Vue.js and React:

They enable writing front-end with JavaScript and utilize the virtual DOM for fast data rendering.
Components have the same single file structure and support JSX.
Both systems allow uni- and bidirectional data flow for the components.

Let's study the component build principles in detail. At the end of our journey, we will uncover the key difference between React and Vue.js.

Table of content

Component build principles in React and Vue.js
How do components impact browser DOM?
Data binding of the components
Brief industry comparison of React and Vue.js
Useful resources

Component build principles in React and Vue.js

JSX and single-file component structure in React

The reason why JavaScript is used for front-end development could be explained so: Google Chrome and Safari have inbuilt JavaScript engines in their core. Hence, developing the code that directly talks to the browser methods makes sense.

Since the UI is represented with components that need to pass the HTML data, React and Vue.js come up with their syntax extensions to JavaScript.

React is using JSX, the JavaScript syntax extension, which allows either to return HTML in JavaScript, or it could be executed in HTML. Also, JavaScript variables can be assigned with HTML tags, like this:

const message =

React is cool!

Dynamic variables could be put into bracket syntax ( { ... } ) in the middle of JSX.

An example of React component, written with JSX

However, web browsers can not execute JavaScript, which includes HTML tags. To make the code readable, React uses Babel to transpile it to regular JS code.

According to Stackshare statistics, the most favorite features of React are components (747) and simplicity (484). JSX, though, takes less user appreciation (31).

I think the biggest concern about JSX is that it doesn't require a specific code structure. The logic and UI of components are in one file so that it could lead to messy code.

The idea of the single-file component is opposed to Angular, which proposed keeping HTML, JavaScript and CSS in separate files. Completing components in a single file didn't get enough popularity unless Airbnb and Netflix joined the React community and began using React for their MVP construction.

When searched for materials related to our topic, I found the 'Do Better Dev Show podcast'. In one of their episodes, Nathan Calvank and his co-host Gyanesh Mishra discussed the main difference between Vue and React. In the middle of the podcast show, Nathan shared his technique of code adjustment in React:

JSX combines logic and presentation. You have got your HTML alongside your JavaScript in the same component. The way it is separated now: you have all your logic at the top, and you just return all your JSX below that.

If you have a sufficiently complex application, you can pull out all of that logic to a container. The container holds all that logic and loads components, including this logic".

You will get the benefit of JSX, getting the separation of concerns from the development side.

So, dealing with the potential frustration of those things combined, this is a reasonable way of keeping these things separated.

Vue.js follows HTML templates for the component design

The same as React, Vue.js proposes keeping the UI and logic in the same file. The component code in Vue.js is contained within a specific HTML template.

The templating brings a clear image of the component code. It helps programmers keep an eye on the methods, view the properties and observe the render functions.

Vue.js has a specific syntax. It uses double braces as place-holders for data. HTML attributes are the directives in Vue.js and contain the prefix v-.

The framework's system involves objects, classes and behavior categories. It matches with the experience of programmers who had worked with object-oriented programming.

In the meanwhile, Vue.js enables writing with JSX, which extends the programmatic power of the framework.

Summary of the requirements:

React requires solid JavaScript skills, while Vue.js is more oriented to novice developers. Similar to React, Vue.js enables writing with JSX, but the components are written with HTML templates.

How do components impact browser DOM?

React renders data through the virtual copy of browser DOM

When a user opens the web page, the Internet browser parses it to a tree-like structure and reads it up to down. This tree-structured file is called the Document Object Model (DOM).

If the user did some action on the page, the browser needs to recreate and re-read the DOM. It takes more loads and decreases the resources of the browser.

React avoided the traditional DOM rendering and leveraged the capacity of data rendering in the browser.

Pete Hunt, a core member of React team, described the idea for the InfoWorld magazine:

The browser itself is retain mode. You click an HTML element on the screen, and then you change it over time. The programming model we wanted for React was basically to throw out and redraw everything. We think that's easier to understand. However, the browser is not designed to work like that. What we did is we built something that we're calling the virtual DOM to abstract that. And so we have a way of basically rendering to a virtual DOM, throwing out the whole virtual DOM and re-creating it every time the data changes, and then React under the hood will convert that, will get the old virtual DOM with the new virtual DOM and then convert that to manipulations of the real browser DOM.

Thank you, Pete. Based on your explanation, we could figure out how does the Virtual DOM operates:

Before the web page is loaded in the web browser, React makes a copy of the DOM and places all the objects in a new component.
When a user opens the web page, React doesn't access a real DOM but renders the copy of DOM. It is called the Virtual DOM.
While the user walks through the page, React is computing the changes. If the user clicked a button or performed any other action, React creates a new snapshot of the DOM and compares it with the previous version.
If one more node element has changed, React updates the page rendering the real DOM.
Amazingly, that React team kept in mind an idea of the game engine when developed the virtual DOM:

The difference with React is the way that your program is much more like a game engine, as opposed to these alternative approaches, with data-binding.

Further, he explains: "With a game engine effectively what happens is the screen is cleared at the beginning of every frame, and then you redraw the scene.

Vue.js is tracking only the dynamic parts in virtual DOM

Vue.js has followed the idea of React's virtual DOM, but it is processing differently.

Evan You, a founder of Vue.js, made a critical review of React virtual DOM. He shared his insights during the presentation in Toronto:

Some of you might know that virtual DOM allows us to compare two snapshots of your view structure and figure out what actual changes you should apply to the DOM. In most cases, it is relatively cheap and fast. However, there is still a cost because you are recreating lots of JavaScript objects. You have to walk through the whole tree on each update to figure out what has actually changed. And it counts pounds as your application gets larger. But the worst part about the virtual DOM is no matter how little dynamic content you have in your template, you always have to walk through the whole tree to find out what has exactly changed.

Vue.js is now tracking the dependencies within each object of the DOM tree.

The virtual DOM in Vue 3.0.11 is tracking the dynamic elements only, which contain

Summary on comparison of the virtual DOM processing:

Templating in Vue.js helps to represent a mini-DOM of a component. Instead of tracking each object, Vue.js goes over the dynamic parts in templates. So, it sufficiently optimized the operation of virtual DOM and leveraged the client-side rendering in Vue.js projects.

Virtual DOM in React needs to track all the nodes in the tree, whether they are static or dynamic.

Data binding of the components

While looking through the articles comparing React vs. Vue.js, you could find different views regarding the data binding. You could often read that React follows just a one-way data flow. Meanwhile, Vue.js provides just the two-way binding like Angular. That is not true.

Both React and Vue.js support the one- and two-way data flow simultaneously. Moreover, they suggest the one-way data flow as most preferred.

Let's get a look at the piece of documentation on Vue 3.0.11 that emphasizes the benefits of one-way data-binding:

All props form a one-way-down binding between the child property and the parent one: when the parent property updates, it will flow down to the child, but not the other way around. This prevents child components from accidentally mutating the parent state, which can make your app's data flow harder to understand.

In addition, every time the parent component is updated, all props in the child component will be refreshed with the latest value. This means you should not attempt to mutate a prop inside a child component. If you do, Vue will warn you in the console.

Even though React components are designed for one-way flow, they could work with the two-way direction.

React supports callback functions so that the children components could fetch the props to their parents. For example, if a user is typing the text in the input field of the child component, these changes will reflect the parent and update its content.

With that said, the React community is provided with react-hook libraries, which enable two-way data binding.

We leverage the full potential of React.js to build highly competitive and scalable web and mobile solutions

Summary:

Vue.js and React support one-way as well as two-way data binding for components. In general, one-way data flow helps establish better control of the project functionality. Both frameworks recommend it as the best option.

Brief industry comparison of React and Vue.js

React

React.js is flexible and open to a variety of choices. It doesn't imply any opinionated direction or mentality for development. However, this approach has some cost because the developers need to have a strong knowledge of JavaScript and be experienced with Single page applications (SPA) design.

Pros of React:

Fast client-side rendering.
Good control of the data flow.
Light-weight architecture.
Extensibility and scalability.
Large community support.

Cons of React:

Steep learning curve.
Does not operate without other libraries and services, like Redux, routing, etc.
Structure-free code may get to spaghetti and boilerplate.

What companies should choose React:

Early-stage startups that need fast feature development and validation campaigns on the market.
Companies that are looking to outsource their development. It is much easier to find a React developer compared to the one with Vue.js expertise.
Product-based companies will also require cross-platforming app development (React Native based on React technology, that it will be a good fit).

Vue.js

Vue.js combined the top-level features of React and Angular, but its main feature is the perfect user experience. Also, it leveraged the capacity of the virtual DOM and optimized the code structure.

Pros of Vue.js:

Developer-friendly framework.
Outstanding performance.
Well-structured code.
Elegant language syntax.
Fine user documentation.

Cons of Vue.js:

Lack of experienced developers.
Small community.
A big part of the documentation is written solely in Chinese.

What companies should choose Vue.js:

Companies that approach the market of web-based products.
Companies that are looking to implement a single flow in their development process.
Companies with no previous experience of using frameworks in their build process or those looking to leverage their proficiency with JavaScript.

Top 10 companies that built their projects with React:

Atlassian (Jira, Trello)
Codecademy
Dropbox
Netflix
Airbnb
Facebook
Instagram
Twitter
Reddit
WhatsApp

Top 10 companies that constructed their projects with Vue.js:

Behance
Dribbble
Adobe
GitLab
Alibaba
Grammarly
Nintendo
Zoom
Louis Vuitton
Google Careers

Useful resources

You may find these materials helpful

How To Hire React Native Developer - A Guide For The Founder

Oleg Goncharenko — Wed, 23 Jun 2021 09:12:02 +0000

The hiring process of React Native developers involves different parts, each of them requiring essential time and effort. To make the process less stressful, we suggest you follow these five steps:

Prepare the specifications.
Outline the job requirements.
Create a shortlist of candidates.
Arrange the job interviews.
Qualify the candidates.

In this post, we will uncover the first three parts of the hiring process:

How to create the specification for a React Native project.
How to complete the job overview.
How to shortlist the candidates.

By the end of the reading, you will get prepared to reach out to potential candidates. In the second part of the article, we will observe the job interview process and qualifying the candidates.

How to create the specification for a React Native project

Finding the best candidate requires good preparation. Your first goal will be to outline the project requirements.

Be as specific as you can. Detailed documentation draws the attention of professional developers and encourages them to apply.

What is needed to complete the project specifications:

Explain the user flows.
Create graphic layouts.
Outline technical requirements.
Explain the user flows

User flows help to convey the core idea of the app. Based on that, the potential developer will evaluate the scope and define the biggest challenges in upcoming work.

After finishing this part, you will get the confidence to explain your product specifics to potential contractors. Except for that, you will check if your product app is ready for the market. These questions will help you to revise your current progress:

Is your application flow simple and easy to use?
Does your app help users achieve their primary goals?
What are the most priority features in your app?
How do you encourage users to purchase the extra services?
What advantages do you offer to your users?
Writing the user flows is a crucial part of the product build. Here is the list of suggested questions that will help you develop the user flow overview:
What are user types (customers, suppliers, supervisors) presented in my application?
What abilities does each user category have?
What information will users request after their registration?
Do I need users to confirm their registration via email or SMS?
How could users view the other user profile?
How can users communicate with other users?
What kind of third-party applications would I like to integrate with my app?
How will the users complete the purchase process in my app?
How do I want to track the information about new and returned users?
Do I want to view the billing information (invoices, payments)?
What types of notifications do I want to display to users?
sample-of-user-flows

Example of the user flows overview

Create graphic layouts

Now that you have the end-to-end descriptions of the user flows, your next turn will be to translate them to the graphic UI design.

Benefits of the graphic UI design:

It helps reflect the graphic animations and business logic.
It makes it possible to find out the challenges and risks.
It enables making a realistic timeline and cost evaluation.

Most popular tools for the graphic UI design:

Figma;
Sketch;
Adobe XD.

In general, mobile applications contain a different number of screens. There could be 20+ screens if it comes to developing a small social media app or 200+ screens if we talk about business-class mobile applications.

So, depending on your case and engagement, you could choose your way: master any of the UI design tools, create the screens by yourself or outsource this work to the UI/UX designer.

Outline technical requirements

React Native developers are creating the mobile UI. Their responsibility is to wire it up with the back-end. To handle this integration, developers need to obtain the documentation on the API first.

It should involve the following parts:

Resource descriptions.
Endpoints and methods.
Parameters.
Request samples.
Response examples.

If you are a non-technical specialist, you could ask for the help of a consultant specializing in developing the API specification.

There are a few ways to find an eligible consultant:

Ask a question on Quora or Stack Overflow.
Invite an expert via Upwork or Toptal.
Book a call with a consultant at Clarity.fm.
Find a consultancy through Clutch, Upwork, YouTeam and book a call with them.

Consultants usually possess any of these positions:

Business analysts at a software development agency (most of the agencies produce the end-to-end documentation for the new projects).
Software engineers with the back-end background (there could be either the back-end or full-stack engineers).
Technical writers who specialize in back-end documentation.

The specification on the back-end will help your team keep organized and deliver the project without unexpected distractions.

How to complete the job overview

We have reached the middle point of our road. From now, every new step will be easier to take.

Your current task is to create the job overview. Generally, it includes the technical requirements along with preferences regarding the skills of the candidate.

You could use the following template of the job overview for React Native developers.

Job requirements template

Project overview:

Tell about your company and the core idea of the project.
Provide a brief summary of the user roles.

Main technical requirements:

Mention the technological stack of your project.
Preferences on UI design (graphic rendering, specific features).
Third-party integrations, like map and geo-location services, mail and SMS integrations, payment gateways.
Location.
Language.

Expectations:

Project duration.
Work engagement (full-time or part-time).
Time zone preference.
Working environment (management system and approaches). *Budget expectations.

Skills requirements:

Development experience.
Special technical skills.
Projects on GitHub.
Portfolio works.
Education.

References to the materials:

User flows overview.
Graphic UI design.
Back-end specification.
Sample of the job overview

Job post example

Let's bring more practice to our process. At present, many companies are moving forward with creating ride-sharing services. Imagine for a moment that you represent the management of the transportation company.

Our current task is to hire a React Native developer who will accomplish the front-end for the upcoming mobile service app. The first step will be to write down the announcement for a job post.

Project overview:

The logistics company Rideshare Services Int. is looking to extend its customer service and hopes to create a cross-platforming mobile application. The app is aimed to help car drivers to make an additional income to minimize their transportation expenses.

User roles:

There are three main user categories within the app: driver, passenger, admin.

Drivers indicate their daily route on the map and set a schedule. Based on that, the mobile app should find the passenger looking to request the ride at a specified time.
Passengers can offer an individual price for the desired service. Drivers could take on the opportunity if they agree on the proposed cost.
The admin user should be able to view the general statistics and moderate users.

Technological stack:

The mobile UI code needs to be created with React Native. The app developer is free of choice regarding the state management service - Redux or Mobx will work fine.

The specification is ready and could be shared with the eligible candidate. The back-end is built with Node.js (Nest.js). The database is based on Postgresql. Preferred cloud service: Amazon Web Services.

Preferences on UI design:

The screen designs are already completed with Figma. There are 90 screens ready for implementation. The requirements for the graphic animation are minimal since the project is at the early MVP stage.

Skills requirements:

previous experience of utilizing React-hook-forms in the project is much preferred;
experience of work with Swift and Android Studio (to be able to work with native modules on iOS and Android platforms);
knowledge of TypeScript is must have;
experience of work with Google Map API;
experience with Twilio and Stripe will be a big advantage.

Location and language:

Our project will be based only in the UK for the initial stage, so that we would require only one language there. In the future, we are hoping to extend it with Norwegian and Dutch versions.

We are working in the UK time zone, but we are flexible as for your time preferences. We hope to have 3-4 hours overlap within our time zones, preferably in the morning hours.

Duration of the project:

Based on our preliminary estimation, the project would take 3,5 - 4 months to finish. Since the deadline is tight, you need to work full-time (40 hours per week).

Working environment:

We use GitHub for the code repository.
All communications are run through Slack and Zoom.
We manage the tasks with Jira.

Budget expectations:

Our budget capacity varies within USD 30-35K (based on our assumptions regarding the timeline).

Required skills:

Master's or bachelor's degree in computer sciences.
3+ years of experience with React Native, both iOS and Android.
You have a good understanding of Agile and Scrum principles.
Project materials:

Besides the graphic UI layouts and specifications on the back-end, we are willing to share the user flows overview. We will send you the documentation after reviewing your application form.

Notes:

Please, send us your resume once you are interested in taking this job position. In your answer, describe your skills regarding the project requirements.
Share the links to the mobile apps you have done before and specify your team's role while working on the project.

Now we are ready to publish the job overview. You will receive a significant number of replies after placing the job announcement on those social platforms:

Hub Staff Talent;
Topdevelopers.co;
LinkedIn;
Youteam;
Upwork;
Toptal.

Except for the mentioned, there are some global social websites, which provide job search opportunities to their community.
So, you could also use their service to hire the React Native developers:

Stack Overflow;
AngelList;
GitHub;
Dev.to

Each platform will make a difference in your outreach process. For example, Upwork ensures you will get over 100 proposals on the first day. To prove our expectations, we simulated the hiring process on that platform.

We published the same job overview and requirements as we mentioned in our sample. Now you could check the outcomes of this experiment. The activity was so high that we obtained over 40 proposals in the first two hours.

Break down your job requirements so that the applicants will grasp your project idea and respond fast

So, it makes sense to iterate your publications and post your requirements on the web resources one by one.

How to shortlist the candidates

You will get dozens of applications straight after publishing your post. Now you need to pre-qualify the candidates based on the following criteria:

Did the applicant specify the works related to your industry area?
Did the applicant describe their skills and experience based on your mentioned requirements?
Could the applicant work full-time on your project?
Did the candidate describe their role in the previous projects?
Did the applicant provide the link to their profile at GitHub?
Do they have some recommendations from past clients or employers?

Create a list of the first 20 candidates matching your expectations. Respond to them via email or the job search platform, appreciating their time and interest. Propose them to book a meeting with you, sending them a link over Calendly or any other booking service that you normally use. Along with that, share your specifications with the candidates, so they could prepare for a job interview.

In our next post, we will provide you with further details on the hiring process of the React Native engineer. The essential part of it will be devoted to the questions you could ask your candidate during the job interview.

Thanks for reading, and good luck with your preparation!

React vs Angular, who wins the competition?

Oleg Goncharenko — Mon, 22 Mar 2021 15:47:31 +0000

Choosing the best option for front-end development

React.js vs Angular. They are equally good at building web-based applications. Some of the world projects are built with React.js, others of the same size, with Angular.

These examples emphasizing both React.js and Angular are suited for making large and scalable platforms, handling massive requests per moment.

React.js gets on the top position and overruns Angular with the number of Node Package Manager (NMP) downloads on GitHub. The difference is huge.

Last year's survey among Stackoverflow's users demonstrates that React.js is 10% more popular than Angular.

Does it mean that something goes wrong with Angular? Or, does it imply React.js offered better solutions than Angular?

Main principles of Angular

Let's figure it out by overviewing both systems in a nutshell. Angular originates from the startup products of Google, where the key of product development was to manage multiple processes in one place. Any unreasonable decision could lead to a problem and affect billions of user operations run in a moment.

Angular became a monolithic framework that predefined programming steps. Even though it enriches the development process with the services, controllers and modules, it dictates its own way of thinking and working. That places a distance between programmer and framework.

Along with that, there are a few other factors that make Angular less accessible:

Angular uses object-oriented programming (OOP), so its knowledge is hard-skill.
Developers should have a good command of TypeScript.
Knowledge of RxJS is a must-have too.
Apparently, the learning curve is very high. Unlike React.js, Angular demands more OOP-related experience from developers. That worked for Google, considering their team's high expertise. Angular was envisioned as an end-to-end solution and was compatible with their advanced programming culture.

Despite the complexity of the architecture, Angular has its indisputable benefits:

Two-way data binding automates synchronization between the Model and the View. Say, if the data was changed in the Model, it would be changed automatically in the View (DOM). Such a function takes off the need to write more additional code. Just imagine Google Drive's document, as a user types text in the document, it is viewed by another one in real-time. Such function is possible due to the Two-way data binding.
Dependency injection (DI), makes it possible to deliver the dependency from one to another class. Due to DI, server-side services could be delegated to a client-side. So, it is a serious advantage of OOP usage in Angular.
Directives aimed to enrich the HTML by providing a new syntax to it. The most common directive is the component. Using it, programmers could create any attribute for an existing element and change its behavior. This is a helpful feature, which makes working with the DOM very flexible. Angular is enriched with many other valuable features, like UI Material, making it possible to reuse the code of components in other parts of the project, but this is similar to what React offers too.

Who chooses Angular today?

Experienced front-end developers share that Angular fits well with enterprise solutions and the corporate sector when React.js is a better choice for early-stage startups and smaller companies. This could be explained that big business does not change their priorities very often and the strategic goals are known to their CTOs far earlier.

The main point you could take from our overview is to remember that Angular is a better option for long-term projects requiring reliability above anything else. Besides others mentioned in the list, a few more companies are using Angular: Microsoft Office, Deutsche Bank and Samsung.

React.js even doesn't call itself a framework but a JS library. Unlike Angular, React.js makes it a developer's responsibility to set a project structure, find relevant services for HTTP routing, and so on. At this point, React's ideology is to be agile and provide developers with absolute freedom. As a result, it leads to minimizing the project's size from start, as they could involve those libraries that they need by a certain time.

Let's imagine that you are the only front-end developer on the project, or there are just a few. The main goals are set for the shortest perspective here. You should be both fast and productive, be able to adjust to startup goals. The straight rules and architecture demands of Angular will slow down the process of development.

So, following single policies is not a major priority for the React.js community. In fact, this is straight opposite to Angular.

It is worth mentioning, React.js couldn't work alone, as it is only the View (V) and needs an engine for data processing. A developer needs to figure out its implementation, manage with Redux and Saga, and arrange that individually.

What makes React.js different?

The learning curve is low. A developer with HTML and JavaScript experience could take on web development and show their first outcomes soon.
The architecture is simple and doesn't take much time to study all its structure.
Virtual DOM made server-side rendering less time-consuming.
Huge community support that regularly contributes to React.js collection.
Intuitive environment, pleasant interface to work with.

What problem does virtual DOM solve?

The current situation is next: if anything has been changed in a user browser while clicking on a page, these changes will be automatically recorded to the DOM. To show the changes on the web-page, the browser should reload the entire DOM structure. It brings more loads to the browser and slows down the performance of the application.

React.js innovations in performance

React.js creates a snapshot of the DOM, which is named the virtual DOM (VDOM).
Every new change in the UI component is to be recorded to the new virtual DOM first, not the regular one.
React.js compares the new version of the VDOM and determines if those changes were essential to update the browser's DOM.
If the changes were essential, React.js updates the DOM with the latest portion of changes.
React.js has such computing algorithms that allow it to decide when to update the DOM in the browser. That makes front-end applications very performative. Unlucky, Angular doesn't have anything similar to this feature.

With that said, React.js helps to write clean JavaScript code for the projects when Angular complements the HTML with many extensions. This becomes messy in a while and hard to deal with such an enlarged code.

It is time to say: React.js dominates in the front-end development area today.

Advanced features, ease of use, extensive collection of javascript libraries placed React.js in a higher position than Angular. That proves an idea that the user-centered approach is a king. React.js has become an intuitive and powerful resource for making front-end applications.

The discussions like 'Angular vs. React' are obviously coming to an end because of the React.js win. Nowadays, the community is much interested in other frameworks like Vue.js and comparison of that kind will be more actual today.

Progressive Web Apps vs Native Apps: Which One Is the Best for Your Business

Oleg Goncharenko — Tue, 23 Feb 2021 15:45:34 +0000

Previously, we shared our thoughts on Progressive Web Apps driven by our hands-on expertise in PWA development. This time around, we decided to dive deeper and explain the major difference between PWA and Native App.

However, it should be noted that there is no winner here since the choice depends on your particular needs and business requirements in the first place.

For instance, people open web pages and consume twice as much content on their smartphones as they do on desktop devices, according to SmartInsights. And the number of users who opt for mobile devices will only keep skyrocketing. So it’s no wonder why most efficiently-run companies use both PWAs and Native Apps in order to stay ahead of the mobile domain curve.

Now, before we can share our insights on which solution can best serve your users or fit your business goals, let’s start by refreshing our memory of what Progressive Web App is.

Simply put, Progressive Web Apps are web-related solutions that combine features of a website and a Native App. In other words, these are websites that mimic a Native App behavior, thus creating an app-like experience.

Here are the major PWA benefits:

It can run on any device or OS
You don’t need a large budget to develop a PWA
You can save your money and resources since it is developed only once
All new features are available automatically once you issued an update
You can rely on SEO practices since a PWA is a website
It feels and looks like a Native App
It’s memory-friendly and takes only a small portion of the device’s storage
It can work offline
It has rock-solid security since it based on HTTPS, which allows browser-to-server encryption

On the other hand, there are a few drawbacks as well:

It has limited functionality on some OS
Fast battery consumption since a PWA requires more CPU
PWAs may not have full access to as many device’s features as Native Apps

That said, any business can develop a PWA solution to expand its digital footprint and ensure a delightful user experience. However, some companies may consider developing a Native App as of the features that a PWA still can’t provide. But again, it’s only for you to decide which option to adopt for your business goals.

If you want to learn more about PWAs and our case studies, please read the previous article. Now, let’s get to Native Apps.

Native Apps: pros and cons

Benefits of IOS and Android App Development

Native Apps are written to run on mobile devices, providing enhanced performance and a broader scope of features compared to PWAs. These apps types are developed for specific OS platforms (usually built separately for Android or iOS) or even for particular smartphones. In fact, almost any app you download from Google’s Play Market or Apple’s App Store is a native solution by its very nature.

Generally, there are four most widely-accepted programming languages that developers use to create Native Apps:

Swift or Objective-C for iOS
Java or Kotlin for Android

However, there is an alternative — you can utilize cross-platform frameworks like React Native. We at Brocoders have been using this product development approach for over 9 years now. It allows building hybrid apps in JavaScript-like code and submitting the final solutions to both Android and iOS platforms in one go. React Native apps demonstrate outstanding efficiency and feel almost like native ones.

Benefits of Coding Apps with React Native

Now let’s move on to the key Native Apps pros over PWAs.

Enhanced performance and UI/UX

Since code is written for a specific device or a particular OS, a Native App integrates seamlessly with its ecosystem and gets access to all APIs. It’s faster and provides greater capabilities in terms of UI/UX experience. Besides, Native Apps can smoothly interact with other native apps offered by Google or Apple.

Monetization privilege

Unlike a PWA that requires a custom payment processing solution, Native Apps can be monetized using in-built App Stores’ payment systems. Users can then make purchases and buy subscriptions with ease.

App Store Support

While PWAs are SEO-friendly, Native Apps got App Store Optimization (ASO) and Apple Search Ads (ASA) alternatives instead. These are cost-efficient approaches (keyword research, eye-catching titles, meta descriptions and so on) that allow you to acquire new users by increasing your rank in App Store’s search results. Besides, users can rate your app, which by itself is an additional traffic source (if your rating is positive).

Security

PWAs have decent security since they run under HTTPS. However, Native Apps have primary access to all the device’s hardware and software features. That said, it’s much easier for a developer to implement the best security algorithms such as two-factor authentication. Besides, a Native App must meet the requirements of multiple standards set by app stores before it can be approved.

On the flip side of the coin, Native Apps have a few weak spots.

Costly development

You need at least two development teams to build a project from scratch for each platform. Thus, you can ensure that both Android and iOS users will utilize your mobile app. Moreover, the final product requires constant updates and maintenance on two different OS. But again, you can save your budget and significantly reduce development time by hiring React Native experts.

Need time to launch

As mentioned above, Native Apps should be approved by Google’s Play Market or Apple’s App Store first before users can download them. The process can take up to a week or more. In some cases, apps can be rejected for several reasons, such as plagiarism or copyright infringement. If you have a tight time-to-market deadline, it’ll be way faster to create a PWA instead of time-consuming native platforms.

Hard to promote

Native Apps are not indexed or listed in the search engine, so you’ll probably have to reach out to third-party advertising services or buy promotional campaigns on popular websites in order to promote your app.

Installation routine

Users don’t like it when they are forced to go through the searching, downloading and installation processes. Especially when they just need to make a purchase or take a quick glance at a catalog, for example. That’s why they would rather use a website or a PWA instead.

Native Apps vs. Progressive Web App Comparison

Now let’s make a comparison table to enable a clearer insight.

Native and Progressive Web App Comparison

Wrapping up

With a bunch of advantages of both Native Apps and PWAs, it’s crucial for you to ponder over every detail and choose the right course based on your business strategy and resources that you have at the moment. As you can see, PWAs and Native Apps are equally vital for any business type and size, whether that be startups, fast-growing companies or enterprises.

In some cases, you may need a fast and cost-efficient solution, so it’s better to opt for a PWA. On the other hand, a PWA may not provide a required performance level or cover all the device’s features. In such a way, you may want to consider developing a Native App. Otherwise, you can create both to enhance the customer experience and reach a wider audience.

When to build PWA/Native App

With almost 100 successful projects under our belt, our in-house software engineers have substantial experience in creating future-proof PWAs and React Native Apps. We are excited to help you reach your business goals and build new innovative projects together. Please don’t hesitate to drop us a line if you want to learn more about the latest PWA vs Native 2020 trends.

Low-Code Development: Why It Is Important and Why It Can't Replace Traditional Approach

Oleg Goncharenko — Tue, 23 Feb 2021 10:53:12 +0000

In today's dynamic and fast-paced business ecosystem, a traditional development approach is often time-consuming and requires a lot of investment. Besides, you need highly-skilled and seasoned professionals to carry out the coding.

On the flip side of the coin, many digital trends have boomed recently as of COVID-19, including the simplified interfaces that can help users quickly build and launch custom apps with minimal hand-coding. These factors, along with the fact that every company strives to streamline and automate its processes, allowed low code and no-code platforms to flourish.

The popularity of low-code application development has gained decent traction these days — according to Gartner, low-code is forecast to comprise over 65% of application development by 2024.

Nevertheless, low code solutions aren't as great as you might think. In this short guide, we want to highlight the key features and pitfalls of this methodology.

What is Low Code?

As the name implies, low-code is a software development methodology where you can create apps with little coding. That said, low code automation tools are visual-driven Integrated Development Environments (IDEs) designed for rapid application development. This inclusive approach was created in response to ever-augmenting business requirements and the shortage of skilled experts.

Unlike traditional development that requires highly-skilled experts to handle all the code, low-code methodologies allow users to create apps with less manual coding through a graphical user interface (GUI) and its built-in drag-and-drop tooling. Thanks to the drag&drop technology, you can seamlessly add and move various elements, such as buttons, images, icons, text, maps, video, etc.

At the same time, low-code is different from no-code — while low-code still requires knowledge of technologies and frameworks, no-code enables users to build apps with almost no hand-coding. But let’s keep the no-code approach for later.

Usually (even based on modern agile techniques), it takes a while before you can end up with a fully-functioning product. On the other hand, low-code allows users to skip a few development cycles and get right to an MVP that can be tested with real users. That said, low-code platforms help businesses to acquire early adopters, validate an idea, and ensure faster development and delivery.

There are several leading low-code application platforms (LCAP) on the market, like Mendix low code software, OutSystems or Appian.

Why is Low-Code popular?

The future of coding is no coding at all.

Chris Wanstrath, CEO of GitHub

Citizen developers and non-tech-savvy users can utilize low-code/no-code platforms to build custom-designed products while avoiding some hand-coding tasks. On top of that, seasoned experts and software providers can also use low-code solutions as a supplementary tool in addition to their traditional toolset.

Low code can enhance the entire workflow and propel your IT teams' productivity by equipping them with the powerful tools for quick and smooth app creation. Now, let's look at the major benefits this development technique can offer.

Improved speed

You can create solutions for several platforms in one go and demonstrate investors or stakeholders a fully-functioning MVP within the shortest time possible.

Resources saving

If you are about to start a new big project, you don’t have to wait for your experts to finish their projects. With low-code, you can save your time and the company’s resources by getting things done more quickly and at a lower cost compared to a traditional approach.

Low risk and high ROI

Low-code platforms are backed by the best industry standards and security practices: cross-platform support, data integration and up-to-date security algorithms are built-in features. Hence, you can focus on more important business tasks while ensuring your entire workflow is highly protected and customized.

Easy deployment

Most often than not, the launch day is all about unexpected problems and new emergency bugs. With low code, you can roll all changes back to a stable version with just a single click and fix the issues early on.

Lifecycle support and seamless integration

Low code platforms support the entire application development lifecycle from idea to exit, including DevOps and CI/CD. Besides, the low code platform APIs allow for external integration with tools to support project management, DevOps, testing and CICD pipelines.

What are the cons of Low-Code?

Low-code isn't the future of code. It certainly has a place in the future and will be leveraged to make many applications. It will not replace other ways of creating software because low-code breaks down when the solution's complexity increases. We saw the same thing with Visual Basic in the '90s. VB was valuable, and a lot of software was written in VB. In the end, it was complexity required by some applications that caused VB to break down and no longer be a good solution. Low code will be the same.

Thomas Stiehm, CTO of Coveros

At first glance, low code software is a perfect solution for app development, but there are multiple drawbacks as well.

Business logic complication

Low code tools like Mendix are an excellent option for the automation of simple processes or prototyping. However, once the prototyping stage is passed, the business logic becomes more complex eventually. To develop a project any further, you'll need an expert team. Today's low code platforms are not perfect yet, so it's not good to rely on them in the long run. Otherwise, you risk jeopardizing your business.

Limited functionality

In a low code development tool, the number of functions that you can implement is limited. It is a quick way to build applications, but you do not have many options if you want to try out something different.

For sure, drag & drop functionality features can be useful under certain circumstances. But when you need a unique feature that's not available, you will need some custom code. Sometimes integrating this custom code can also cost a lot more than a completely customized solution built from scratch.

No technical background myth

Despite the name, you still need a robust technical background to use low-code tools. Furthermore, you first need to examine basic low-code development requirements and technologies, which by itself take time to learn and adapt to.

Security limitations

Low-code solutions indeed have in-build security protocols, but they still can't provide the same security level as standalone development technologies. With an application based on low-code, you have neither full control over data security or access to source code. Hence, you can’t define all the possible vulnerabilities out there.

Summary

Now that we know the major pros and cons of low-code methodology, we can understand that it is not meant to replace traditional development or professional software providers.

Instead, it’s essential for companies to utilize low-code practices to strengthen a traditional approach and fill its gaps. When combined, low-code and traditional techniques can ensure faster and more productive application development.

With this in mind, low code significantly enhances speed-to-market and improves the overall business efficiency when used in tandem with traditional methods. All in all, there is no silver bullet that can turbo-boost your business, so it’s vital to consider multiple options and get professional advice. We at Brocoders are always eager to share our best expertise with you. Please, feel free to drop us a line any time you see fit.

What We Have Learned While Using AWS Lambda in Our Production Cycles for More than One Year

Maxim Vynohradov — Tue, 15 Sep 2020 21:38:52 +0000

Over the last few years, serverless approaches have gained decent traction in the web app designing, developing and implementing sectors. In the early days, many engineers treated serverless just like another hype. Still, almost all of those who tried to use it had to admit that the technology turned out to be as good as traditional and standalone virtual machines for hosting web-applications.

To date, we can see that startups tend to utilize serverless technology stack as a part of their systems or even as their primary solution for building products in different domains.

First things first

Our team decided to test out the technology while working on the product during the last year — an on-demand bike taxi app that uses a serverless approach for one of its components. In fact, it is much similar to an Uber app.

Technically, it was mostly a REST API and cron-tasks, anchored by the following technologies (all of these are provided by the Amazon Web Services):

API Gateway as a platform for API management.
CloudWatch Rules for scheduling cron-tasks.
Lambdas as computing units.
S3 buckets to store static files.
CloudWatch Logs with Logs Insights for log management.
Tools for continuous integration and deployment of our application: AWS CodeBuild, AWS CodePipeline and AWS CodeDeploy.

Initially, we used Node.js version 10 to write the code (a few months ago it was upgraded to version 12 without any issues). And all the infrastructure part (I mean all the AWS objects descriptions) is created and managed by an open-source Serverless Framework.

*This guide is not about AWS, FaaS (Function as a Service) or Serverless framework, since there is a lot of such content on the Internet. Here you will only find the things that our team faced during the development and after-launch stages. This info might be helpful if you come up with doubts about which technology to adopt for your next project. *

The Serverless world — the remarkable benefits of using AWS Lambdas

Let's start with the good parts! No matter what any hater says, the Serverless world provides a bunch of excellent features that you cannot achieve in any other way under equal conditions.

When we started this project mostly from scratch, it didn't require any severe capacity in measurements of Memory, CPU or network, to name a few. The same statement can be made not only about the development phase but also about the Staging, QA and Pre-Prod environments.

Traditionally, we need four servers, whether that be virtual machines, docker containers or any other platforms where we can host servers. For sure, it might be quite expensive to keep and maintain servers, even small and low-power ones. Even switching them off at nights and weekends is no way an option.

However, the Serverless world has an alternative solution – the so-called "Pay as you go" payment approach. It means that you pay only for the computing resources and network load that you use, even though the entire infrastructure is deployed and accessible at any moment.

In practice, it means that we were not burdened with any cost savings during the project's development. Moreover, while we remained within the AWS Free Tier limits, the actual cloud usage was charge-free until we reached the production stage.

So here are some advantages of AWS Lambdas worth mentioning here.

Outstanding scalability

The app was designed for the city with more than 13 million people. So it’s no wonder that the number of users started snowballing right after the first release. By "snowballing", I mean thousands of new users per hour in the first few weeks, hence a bunch of rides and ride requests as well.

That's where we felt all the benefits of the AWS Lambdas' incredible scalability and zero management of the scaling process. You know, this feeling when you see a rapidly growing number of requests on the chart (that was automatically provided by AWS). And the greatest part is that you shouldn't even worry about this, since the AWS Lambdas are scaled automatically. All you have to do is set a threshold for the concurrent invocation.

A standard set of monitoring and logging tools

Aside from the automatic scalability feature, AWS provides a basic set of tools for Lambdas. So, you don't have to waste your precious time dealing with the annoying configuration of basic monitoring metrics, such as Memory Usage, Execution time or Errors Count.

Moreover, you can customize your own dashboards in the CloudWatch service that would help you track performance issues and execution errors throughout the entire serverless application.

For sure, you won't come up with as many customizable graphics options, as Grafana or Kibana can provide, but at the same time, the AWS CloudWatch metrics, alarms and dashboards are way cheaper. Besides, you can attune these without much preparation, and last but not least — the cloud provider takes responsibility for the efficiency of the monitoring tools described above.

Isolated environment

Well, let's say you managed to customize a dashboard without any problems. But then you realized that the Lambdas execution process took more time than it should have, and it looked like Lambdas performed some sophisticated calculation. Luckily, it's not a problem for AWS Lambda, since every function-handler runs in an isolated environment, with its own configuration system of Memory or CPU.

In-fact, each instance of Lambda is a separate AWS Firecracker Container that spawns on a trigger (in case of a REST API, the trigger is an HTTP request). That said, all you have to do is just increase CPU units Count or Memory for the specific Lambda, with no need for global updates, as if it were done in a classic server.

Flexible errors management

Another outstanding benefit that you can enjoy while using AWS Lambda is decent error handling.

As said above, each Lambda has an isolated environment, so even if one of your Lambda instances fails for any reason, all other Lambdas will continue to operate normally. It's fantastic when you have just one or two errors from a few hundred possible AWS Lambda invocations, isn't it?

Automated retry attempts

Furthermore, retry attempts is another out-of-the-box feature that AWS provides. Should a Lambda fail for any reason, it would be automatically re-invoked with the same event payload during the pre-configured period. I must say, it’s a quite useful feature if your Lambda is invoked by schedule and is trying to send a request to a third party resource that can be unavailable.

Finally, AWS Lambda supports the Dead letter queue concept that means you can acquire relevant notifications and tracking information about failed Lambdas.

The AWS Lambda disadvantages — a few pain points to learn from

On the flip side of the coin, AWS Lambda and the serverless concept are not entirely perfect yet and have enough unresolved problems and pitfalls that make the development and support processes a little bit harder.

Duration limits

For our project, it was all about limits. For example, we ended up with an execution duration limit — a Lambda can be performed within 15 minutes maximum. Moreover, if a trigger is requested from an API Gateway, the duration must be no more than 30 seconds.

Perhaps, we could accept such limits for the API, but a 15-minutes limit for the cron-tasks was way too tight to execute the particular scope of tasks on time. That said, since the computed intensive tasks couldn't be invoked with Lambdas, we had to create a separate server specifically for long-running tasks.

CloudFormation deployment limitations

Another significant issue we faced was the Lambda deployment via CloudFormation (the AWS service for infrastructure and deployment). At the very beginning of the project, everything was fine. Still, when the number of Lambdas mushroomed into more than 30 CloudFormations, the stack started failing with different errors like "Number of resources exceeded", "Number of outputs exceeded".

Thankfully, the serverless framework and its plugins helped us to tackle this issue early on. There are also a few other ways to solve such kinds of problems, but that'll be a topic for another article.

Failure to expand monitoring and debugging toolset

Even though AWS provides some basic level of monitoring and debugging, it's still impossible to extend this part and make some custom metrics that could be useful for particular cases and projects. This time around, we had to use third-party services that you usually need to integrate as libraries into your code to be able to monitor some specific stuff.

Cold start-related delays

As mentioned above, each Lambda instance is in-fact a tiny Firecracker Container with some basic runtime environment, libraries and your code. It's created temporarily to process any event evoked by the triggers. It's a well-known fact that creating a container or running an executable environment and code takes some operational time called a cold start.

It can take random time between 100 milliseconds to a few minutes. Moreover, if you keep your Lambdas under VPC (Virtual Private Cloud), cold starts will take more time because the system will have to create additional resources for each Lambda, called Elastic Network Interfaces.

This, in turn, results in annoying delays, so the end-users have to wait for the app to respond, which is definitely not good at all, isn't it? The workaround here is to ping your Lambda every 5 minutes to keep containers "warm". The AWS system is smart enough and doesn't kill Lambdas containers immediately, since it is based on the concept that triggers would keep spawning new events.

Database connection pitfalls

In view of the above, it's problematic to manage a database connection for such a system. You cannot just open a connection pool to your MongoDB or MySQL servers at the application startup phase and reuse it during the entire lifecycle.

So there are at least two ways to manage connections:

You should open a connection for each Lambda invocation and close it after your code with logic would be completed; You can try to reuse a connection and keep it in the Lambda memory as a reference in code or field in context — it allows you to keep a connection within the same Lambda containers till closing.

However, both have their own limitations. In the first case, we end up with additional delays since we have to open a connection for each Lambda call. In the second case, we can't be sure for how long Lambda would keep a connection, and consequently — we can't handle a connection shut-down properly.

Local test limitations

Besides, the serverless apps are hard to test locally, because usually there are a lot of integrations between AWS services, like Lambdas, S3 buckets, DynamoDB, etc. For any type of local testing, developers must mock all this stuff, which usually is a formidable and time-consuming task.

Inability to adopt caching in a traditional way

On top of everything else, you can't implement a traditional caching for classic-like servers. Usually, you have to use other services like S3, DynamoDB or ElasticCache (de-facto Redis hosted on AWS) to keep Lambda's state or cache some data between AWS Lambda invocations.

In most cases, it results in extra costs of the entire infrastructure. Not to mention additional operational overhead — you'll have to put and fetch cached data from remote storage, which, in turn, can slow down the performance of your cache.

Complex payment model

The last one worth mentioning is a sophisticated price calculation. Even though AWS Lambda is quite cheap, various supplementary elements can significantly increase the total costs. People tend to think that the pricing for using the AWS Lambda's API is based on its computing resources and duration of code execution. In fact, you should keep in mind that you'll have to pay for additional services, such as:

Network traffic,
API Gateway,
Logs stored in the CloudWatch.

Wrapping up

Summarizing the above, I want to say that the AWS serverless approach is a great way to strengthen your development practices. Nevertheless, you have to keep in mind that it's quite different from traditional servers.

To leverage the life-changing benefits of this technology, you have to get acquainted with all the subtleties and pitfalls in the first place. Besides, you also have to think through the architecture and its specifics for your particular solution.

Otherwise, the serverless approach can bring you rather problems than beneficial features as of insufficient educational background.

Crime and Punishment: Hype Driven Development

Maxim Vynohradov — Sun, 12 Jul 2020 22:28:55 +0000

Disclaimer : long read. About the painful stuff, what I want to share for more than a month. Also does not claim to be complete, it is more about how I try to deal with it.

Introduction: what is Hype Driven Development
HDD definition as a crime
Objective side and consequences of the HDD crime
How to prevent HDD in project
Conclusion and afterword

Introduction: what is Hype Driven Development?

Here I want to share a few thoughts on how to convince the team / manager / product owner to not use the "hype" technology or make proof that this technology fits good in your project.

It is well known that representatives of different professions often invent ways to solve a particular problem. For instance, which approach and constituent materials to use and positions, the choice of a specialist often determines the success of achieving the goals. For example, would the cafe be profitable, and would the bridge withstand the load successfully, would the operated heart beat for many years. And, unfortunately, one wrong decision can lead to fatal consequences and suffer great losses, and even worse – harm the health and life of people.

Engineers, software developers, web developers, and other technical guys are no exception. Moreover, the final software products are extremely dependent on real business, with real people and finances. And the harm that can be caused by badly designed and implemented software can potentially be huge and irreparable damage to the entire business.

Let's look at one of the most common crimes committed by various teams that somehow participate in the design and development of various types of IT projects, named Hype Driven Development (hereinafter referred to as HDD).

This concept is not new, but it does not go back to the past century, and means a decision about a technological stack or software architecture that is taken without technical justification, research, based only on loud and popular words from the Internet or other sources, "buzzwords ", unverified rumors. It's a development based on fashion and trends, without explanation of your choice from a technical point of view and not confirming by checking or evaluating the proposed solution.

What I have most often seen: blockchain, data science, machine / deep / any other learning, MongoDB, GraphQL, Serverless, Clouds, Kubernetes, and more. These "hype" technologies and much more I've seen in different proposals of various technical requirements, in RFPs (Request for proposal), spreadsheets with estimates, and so on. Don't get me wrong, I have a deep respect for the above-listed technologies, and, as an example, I often use MongoDB and Serverless. The problem is that these technologies were proposed to be used and added in the post-production phase, and their connection with business logic seemed as far-fetched as possible.

HDD definition as a crime

Why I started with such a long prelude at the beginning - you can imagine when a builder chooses from what material to build a skyscraper "because it is so fashionable". Or maybe a doctor who prescribes pills according to the principle "well, those people take similar pills abroad, and this may help you too." Personally, I have not, I have never seen this, I wish the same to you. For me, such an approach and attitude to work looks like a crime. Therefore, I propose to consider HDD a crime, at least in the article.

To begin with, I think it's worth remembering what constituent elements of a crime are. Without the presence of corpus delicti, an act cannot be considered criminal.

It's a quite extensive and complex definition, but let's summarize and simplify it a little, coz after all, this is not a jurisprudence article, especially since the laws of countries and states are different enough. We are interested in the following components of constituent elements of a crime:

the object - is the part to which the damage was caused;
the objective side- is the external manifestations of the crime, action or inaction, the consequences of the crime, as well as the connection between them or, for example, the time, method, means of committing;
subject - the one who committed the crime;
the subjective side - is a person's attitude to a crime that he has committed. Was it intent (direct or indirect) or it was negligence (frivolity or negligence), there is a motive and what is the purpose of the crime.

Let's start with the subject. In our case, this is one of the members of the development team in the broad sense of the word: engineers, managers, product owners. That is all those people who in one way or another influence the development process. But they can be divided into two categories. Some of them work on business logic, tasks, and functional requirements - usually the manager, business analyst, and product owner. On the other hand, we have technical specialists - test engineers, developers, architects, team leads. Of course, they can work at the junctions of the technical and non-technical parts of the project, but now it is important that both the former and the latter can offer, perhaps even insist on using the hype technology.

And here we smoothly move on to the subjective side of the HDD crime - did anyone want to harm when choosing an HDD technology? I think nobody would choose technology or design architecture to the detriment of their project or product. Then why?

Based on personal experience, I can say, that typically, customers (meaning people or companies which order development of product, not product users ), product owners choose one of these technologies to attract the attention of investors and potential users as sources of funds and income. The reason is more than clear and transparent - often investors are not technical specialists, so, many of them are being led by beautiful marketing slogans, that promise many profitable things for the product. But at the same time, they usually don't understand the real essence of things. As a result, we get a technical solution based on marketing. There are also cases when a customer already comes with technical requirements for a future product. When asked "why does he want such a stack of technologies?", we usually get one of the options: "one of my projects uses such a stack and everything is fine", "my partner's project uses such a stack - and he is happy with everything". People who say this usually do not think about the fact that if functional and non-functional requirements are different, then the technologies used do not have to be the same.

Sometimes it happens that someone from the technical part of the team initiates the use of "hype" technology. Usually, this is less experienced teammates (juniors), which still cannot always assess the risks and make appropriate time estimations. For them, it all comes down to the fact that they want to try a new technology, which is given in a beautiful wrapper. And also usually they do not look at the license of the solution (let's say it is a library or a framework), or at its maturity.

Objective side and consequences of the HDD crime

The objects of the HDD crime can also be different. It depends on what side of the project we are considering - technical or business. If we are talking about the technical side, there are codebases in general, its architecture, the infrastructure of deployments. On the other side, the business operated by other concepts, like include cash flows, investments, profits, and other business processes.

So, let's say a "hype" technology penetrates the project, seeps into the code base, a lot of logic, additional code and configurations begin to rise around the technology. In this case, what and who will suffer from the introduction of "hype" technology, and how (we are talking about the objective side) will the HDD affect the project and the business as a whole (the object of the crime)?

There are a lot of things, consider that you are playing dice - it all depends on how hype and not properly researched technology is deeply integrated into the business logic of your application, code and development processes in general. The list below presents the most obvious consequences.

🚫 Building a business model around technology, not adopting technology to business.

This happens relatively rarely, but extremely unfortunate. It happens when a "hype" technology is at the very core of the business logic and, accordingly, the code base, when the very idea of the application is to build something over the technology. Accordingly, if the technology breaks down in one way or another (for example, an unobvious bug pops up) - with a high probability, the product that is based on it breaks too.

🚫 Low conversion from "hype" technologies - that is, the discrepancy between the expected profit from the technology and the real one, as they often do not take into account that needs to pay for additional infrastructure along with the support of such a solution, as well as the work of specialists who will configure this solution.

🚫 The black box problem. Usually, the external dependency is perceived as something atomic, as an integral component within our system, with its public API (interfaces, methods, endpoints). But in fact, this is the same program code as the one in which we integrated this component, with its dependencies and bugs, performance, and security problems. You probably say: "But often the code of such components is open source!". Now think, how often do you have enough time, desire, and immediate need to look into the program code of one of your libraries or database (which is also a software product with its source code)? I think not often (but usually it tends to never). For us, a bug (this is how it can harm your project) in any external dependency is a kind of analog of "Schrodinger's cat in a box", which is both there and not. We often find out about the presence of bugs only when this external bug affects the state of our system.

🚫 Lack of professionalism and experience in the introduced technology. It's simple - the devil is in the details. Even if you have over-qualified specialists in your team who love work and are ready to delve into everything new on their way, hardly anyone can comprehend the depth of this or that technology in a short time.

🚫 Increasing the entropy of the program code and the system as a whole. Hmm, okay, but what is entropy? It is a very broad concept, rooted in natural sciences, thermodynamics, and later mechanics and software. The initial idea is that in an isolated system the degree of chaos and uncertainty will not decrease over time but will remain the same or increase. On the other hand, entropy is a measure of the unknown about the system as a whole. The concept first appeared in the context of software in the book Object-Oriented Software Engineering (by Ivar Jacobson, Patrik Jonsson, ACM Press Staff, Magnus Christerson, Gunnar Overgaard). In general, think of entropy as a measure of the dishonesty of the system. The more disorder, uncertainty, the higher the probability of breakage. Compare a hammer and a car, which is a hundred times more complex in its structure - which one is broken down more often and faster? A car has many more constituent components with its level of entropy, and therefore the total entropy is higher. Returning to HDD, the more complex and more unknown technology we involve in the process, the higher the likelihood that the project entropy will increase, and hence the number of bugs and Mean time between failures (MTBF).

🚫 Life cycle and aging of software. Are you sure that the hype framework, the server, will exist, developed, and be supported for a long time, at least as long as the life of your project / product? And that in the next version the public API will not change completely - you need to either translate the API to a new one or live with the deprecated API. Have you assessed these risks correctly? Let's discuss this further.

🚫 Increased risks. New technologies usually mean new risks:

Going out of bounds by time estimation.
Risk of unsuccessful completion of the project.
The additional overhead for infrastructure, development, and support.
Additional vulnerabilities of the system crash.
Nobody guarantees that critical security updates will be issued and fixed on time.

How to prevent HDD in project

Ok, it seems that we have considered all the components of this crime. But how to prevent and avoid the use of HDD on a project without realizing full awareness of what technology the team will live with on the project? Or you can prove the validity of the implementation and evaluate all the pros and cons. Once again, just in case, if the technology is hype, this does not mean at all that it is full of bugs, has not matured, or does not apply to your project. It's just that there should be common sense in everything, namely in the analysis of technology from a technical and business point of view, a sound assessment of risks and additional costs.

Here are some ideas and approaches, the use of which can influence the views and awareness of the team regarding the choice of hype technology.

💡 The opinion of experts, both in the technical part and in the subject area of business - "do we need it?" Before getting into Data Science, Serverless, and the like, consult a specialist with experience with this technology. Probably, you will not give up the technology, but completely rethink its use in the project. Moreover, it has a positive effect on grades.

💡 Proof of Concept creation is as old as the world - before doing a full-scale implementation and implementation, you should make the simplest demo version tied to any technology. Most likely, you will not notice any deep and hidden problems, but you can throw away the technology at the start if you see that it does not suit you in any way.

💡 A collective brainstorm "for" and "against" - decisions should never be made alone or in a narrow circle of employees. It is worth discussing and listening to all opinions, perhaps a sensible thought will come from an unexpected side. Also, interesting is the Three amigos approach, which is rooted in BDD and Agile, and means that there are three parties involved in the process: Business, Development, Testing. Thus, you can try to identify the largest number of problems and corner cases associated with the introduced technology. More details here.

💡 "5 Whys" - and again about how not to drag unnecessary things to your project. Try to apply this technique to the next technology adoption issue. Ask yourself and your colleagues - "why are we doing this," and so on, 5 times according to the list (see the article). It may well be that simpler steps are sufficient to solve the original problem.

Also, consider whether you can achieve the desired results without using this technology. How much more difficult and costly it will be.

💡 KISS (keep it simple stupid) And YAGNI (you ain't gonna need it). A huge number of articles have been written about these principles, and I see no need to retell them. Just make sure you don't break them when you introduce the next technology to your project.

Conclusion and afterword

We're finally here, and I'll try to make the ending shorter! There is a huge difference between "adding and usage of new technology" and "deliberately adding and usage of new technology". It would seem that the phrases differ by one word, but there is a huge gap between them. Hype technologies are often interesting, progressive, the main thing is to choose and apply them deliberately, without risking the project and business, not forgetting about your technical debt.

Forem: Brocoders

Types of QA Testing: A Comprehensive Guide

React vs. Vue.js. An in-depth overview of their main differences.

Common features in Vue.js and React:

Table of content

Component build principles in React and Vue.js

JSX and single-file component structure in React

React is cool!

Vue.js follows HTML templates for the component design

Summary of the requirements:

How do components impact browser DOM?

React renders data through the virtual copy of browser DOM

Vue.js is tracking only the dynamic parts in virtual DOM

Summary on comparison of the virtual DOM processing:

Data binding of the components

Summary:

Brief industry comparison of React and Vue.js

React

Pros of React:

Cons of React:

What companies should choose React:

Vue.js

Pros of Vue.js:

Cons of Vue.js:

What companies should choose Vue.js:

Top 10 companies that built their projects with React:

Top 10 companies that constructed their projects with Vue.js:

Useful resources

Articles and tutorials

Podcast shows

Videos on YouTube:

How To Hire React Native Developer - A Guide For The Founder

How to create the specification for a React Native project

Create graphic layouts

Outline technical requirements

How to complete the job overview

Job requirements template

Job post example

React vs Angular, who wins the competition?

Main principles of Angular

Who chooses Angular today?

What makes React.js different?

React.js innovations in performance

Progressive Web Apps vs Native Apps: Which One Is the Best for Your Business

Here are the major PWA benefits:

Native Apps: pros and cons

Enhanced performance and UI/UX

Monetization privilege

App Store Support

Security

Costly development

Need time to launch

Hard to promote

Installation routine

Native Apps vs. Progressive Web App Comparison

Native and Progressive Web App Comparison

Wrapping up

Low-Code Development: Why It Is Important and Why It Can't Replace Traditional Approach

What is Low Code?

Why is Low-Code popular?

Improved speed

Resources saving

Low risk and high ROI

Easy deployment

Lifecycle support and seamless integration

What are the cons of Low-Code?

Business logic complication

Limited functionality

No technical background myth

Security limitations

Summary

What We Have Learned While Using AWS Lambda in Our Production Cycles for More than One Year

First things first

The Serverless world — the remarkable benefits of using AWS Lambdas

Outstanding scalability

A standard set of monitoring and logging tools

Isolated environment

Flexible errors management

Automated retry attempts

The AWS Lambda disadvantages — a few pain points to learn from