Bilyal Mestanov

Replacing Swift with React Native

Office

Milush-photo

Google

Radoslav

Bug illustration

grapnel

Emil Kirilov

Project Structure

Deyan Denchev

Sandbox Query

Accounting

regular expressions 101

Mira

Programming

Lexis Solutions-Team

CTO & Co-Founder

Milush Karadimov

Software Developer

Radoslav Kosev

QA Engineer

CEO & Co-Founder

Web Developer

Mira Ereeva

Growth Manager

I wrote my first line of code that went to production six years ago. It was the summer after my Computer Science bachelor's began, and I was eager to put all of the [knowledge](https://www.lexis.solutions/blog/why-does-knowledge-matter) I got up to that moment to good use. I developed an app, published it to the Play Store, and quickly reached users who still use it today.

![Screenshot](//images.ctfassets.net/5gydaotbo8jm/4EpPtEMNRbVEt0thNwH9NU/c00d2d9e246f99ffdadbcc164199805a/image_2_.png)

Over the years, with many projects and the privilege of working with gifted engineers, some realizations occurred to me that helped me become a better professional. To celebrate the occasion, I compiled a non-exhaustive list of a-ha moments I had, to depict the path and learnings of a (WIP) software engineer.

## Standardize code

It came to me as a revelation when I realized the best way to write code is to try to do it as a machine would. Define a set of rules and stick to them. Use style guides and tools that enforce them as much as possible. ESLint & Prettier have been an absolute must in the projects I have started. While those are great for syntactic "dumb" conventions, higher-level conventions can be extracted to the README - followed and exercised with every PR by the team members. Use the same "tropes," "patterns," or ways of doing things in similar contexts. And while one might think this is only good for teams, a single-person project can quickly deteriorate and become a mess. As there is nobody to stop you from writing however you like, developers are not consistent in their style and prone to mixing and matching styles and ideas. The advantages of *trying* to write code like a machine are manifold.

First, this drastically reduces the number of tiny decisions you have to make, e.g.

-   Do I name this const object `Colors` or `COLORS`?

-   Do I define my `useCallback`s first or my `useMemo`s?

-   Do I name this endpoint `allUsers` or `users`?

-   Do I write `if (foo) return;` or `if (foo) { return; }`

-   Do I use a named function or an arrow function?

These tiny decisions eat away from your energy to focus on what's genuinely human about programming - the creative part.

Second, this makes refactoring easier. Find and replace works best if the codebase has a consistent style.

Third, this reduces the friction of switching projects in an organization if the projects use the same (or similar) conventions.

Fourth, there are fewer merge conflicts - saving you time otherwise spent on solving those. In the last years, my teams have used tools to order the imports in files deterministically and order the props of a React component. Not a single merge conflict regarding those has risen since then.

## Know your tools

Whatever development tools you use, take some time and learn the ins and outs. At the top of the list is your IDE or editor and the terminal, where you spend most of your coding time. There are many tips and tricks videos on Youtube, and 10 minutes of your time now can save you years of doing simple tasks sub-optimally. Not only will this make you more productive, but there are many occasions when you share your screen and work with a peer or manager. People certainly notice if you are fast with your tools, making a great impression.

## Chase simplicity despite complexity

I notice, especially at the beginning of their careers, developers solve problems bottom-up, solving parts of the big problem and then trying to piece everything together. Doing so often results in bloated and complex code, which is prone to becoming spaghetti and is hard to maintain. In my first project, I certainly remember how proud I was when I wrote a Java file with 1.2K lines! What I discovered as a better method of going from spec to implementation is top-down, not worrying too much about detail, and trying to get the bigger picture right. In this feature which are the main components? How do they interact? Are there dependencies? Of course, things will not be apparent right away. What works for me is a cyclic process:

1.  come up with a big picture

2.  go into detail about a component

3.  inevitably things come up that require changes to the big picture

4.  update your existing big picture; in most cases, this will bring complexity

5.  can it be simplified and still do the same thing?

6.  repeat 2-5 until ready for implementation

Requirements push the code towards complexity. As developers, we must do our best to counteract that force by trying to solve those complex problems with the (possibly) most straightforward solutions. After all, the best code is less code.

## Don't overdo abstraction

Talking about less code, taking that idea to the extreme can also be counterproductive. By all means, I am guilty of building abstractions over classes that are vaguely connected only to extract a 3-line class method. I have also written some shared packages that became more of a headache to maintain, only to follow the famously evangelized DRY principle in countless programming books. The bottom line is that sometimes abstraction is not worth it. Before building an abstraction, weigh the pros and cons of maintaining another software artifact versus having multiple instances of it in existing artifacts. Ask the question, how similar are what you are trying to abstract away in essence, in pure words, as an entity, not code? This lesson was a revelation from no other than Dan Abramov (not the creator of React) from a 2019 talk, "[The Wet Codebase](https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebase)," which I highly recommend.

## Read the documentation (no, for real)

An inspiration for countless memes, the documentation is often ignored when you hop on the hottest new dev tool/technology. Not only does it provide a structured way to comprehend the technology, but it also outlines edge cases that you might not even be aware you are getting into. A while back, my team employed Prisma for an ORM to large-scale project. It was using GraphQL in conjunction, and we had missed reading [this](https://www.prisma.io/docs/guides/performance-and-optimization/query-optimization-performance#debugging-performance-issues) little guide on query optimization and the n+1 problem, which is precisely the problem we shipped to production unknowingly. After some performance issues, a team member finally spotted the post, which fixed our problem.

The bottom line is that the documentation provides not only what a tool can do but also its limitations, what to watch out for, what's the roadmap, how well maintained it is, and who the people behind it are. Avoid treating it as a flashy advertisement but as a receipt that describes how to use it, its side effects, and what can go wrong.

## Use and build tools to consolidate the development process complexity

As a project evolves, it gets more complex to deal with during development. Maybe you have microservices and need to start all the services one by one, or perhaps you extract translation keys before starting your front-end. To minimize the learning curve, any task or process newly onboarded developers have to learn is better consolidated in shell scripts. These scripts rarely change; keeping them in the git repository will make your workflow faster and shorten the time for new hires to start being productive. If you see an opportunity to create tooling that doesn't exist, go for it. It could be a simple shell alias as `alias ys=yarn start`, a VSCode plugin, a dev dependency, an integration, you name it; even saving a few keystrokes counts. Chances are, your team or even external communities of developers could also benefit from it.

## Notice when you are stuck

There is nothing heroic about trying to solve a problem on your own at any cost. Give your best attempt, maybe twice, but learn to recognize the moment when you should seek to speak to someone. And notice I don't say seek help. I have seen some of the most significant breakthroughs happen while simply explaining where someone is at with a problem. It doesn't have to be your engineering lead or CTO; it could be your peer or even someone with less experience than you. A simple "hey, does anyone have some time to check out this problem with me" on Slack can go a long way. Is nobody online? Come back to the task after a walk, run, or a good night's sleep. Almost any senior developer I know does this. Pushing hours and days alone with no progress on a task is selfish, as it detracts from your team's goals and burns money for no justifiable reason for the stakeholders.

## Present your work as early as possible

I have spent all my professional career in startups or startup-like environments - fast-paced and flat organizations where the top priority is to deliver value in very short cycles. One of the more recent rituals we stumbled upon is what we call "local demos." It is essentially a screen share session between two or more developers where the feature's author presents the work on their local development environment before opening a PR request. This ritual has proven to be a great way of catching code and requirement issues even before they are in the form of a PR request. Viewing the code and the result alongside the author gives the future PR reviewer a better idea of what to look at when the PR is ready to be merged. We even do these sessions with clients and QAs, allowing them to peek at the progress. Instead of a bug going through a PR, QA testing, or potentially a staging environment, it's detected right there and then. So far, many bugs have been eliminated in the earliest stage possible, enabling us to produce a better product in shorter cycles.

## Don't write code for the sake of writing code; it's always about the client

The internet somewhat idolizes this hardcore hacker dev persona - always writing the cleanest code, solving problems with possibly the most efficient algorithms, sunglasses in a dark room, Vim? As romantic as it sounds, the expectation of being this brilliant engineer working on exciting and challenging problems all the time is unrealistic. In a commercial setup, what matters is building a product that people want and use, given deadline and budget limitations. It is a cherishable trait to put yourself in the stakeholders' shoes and have their concerns in mind when doing the actual engineering instead of solely focusing on solving problems in the most elegant way possible. More often than not, a working solution now is better than the best solution tomorrow. Of course, this is no excuse to put in the minimal amount of work and produce the "minimum non-sucking product." The best engineers create robust, sustainable, and scalable solutions given all the constraints.

## Production is nothing like development

It took three months for me to publish my first app. I had put so much energy and thought into every detail; it looked great and worked perfectly on my emulator and phone. I was so excited to share it with the world. Then I onboarded the first users. A few days in, complaints were raining - "It's too slow!", "It's crashing," "It sucks!" My phone was ringing every day with users and their bug reports. This period gets to you when you have never published anything to production, and it is easy to feel inadequate as a developer. The truth is, nothing prepares a developer early in their career for the utter chaos of an actual mass of people using your product. It's an entirely different set of problems than the programming itself. Deployment, availability, backups, scaling, and performance are problems that reveal themselves only when you hit production usage. In big companies, those roles are separate, so not all programmers are concerned with deployment & reliability. But I would argue that working on software from inception to end user has given me good insights I still use daily. Plus, it's always fun to watch your baby fly (or flop!).

The good thing is that these lessons never end; they change, they become obsolete, or plain wrong. The field of software engineering is a gift that keeps on giving. Every day, millions of people are hard at work imagining the world's future using code, and I sure am looking forward to what we will build in the next six years and the lessons that come along with it.

A compilation of thoughts and insights from my experience as a software developer over the past six years.

10 Lessons I Learned in 6 Years of Software Engineering

Good old (and new) friends. A lot of blue outfits. Some cupcake challenges. And one fantastic rooftop. That's how we would describe the 4th of August when Lexis Solutions marked its 5th birthday. 

Lexis Solutions started with four enthusiastic developers - its founders - Bilyal, Deyan, Emil, and Milush, who met at a university competition and embarked on a new adventure - Lexis Solutions. Five years later, 14 people are involved in the life of Lexis' family. It recently expanded with our manager of growth - Mira, and intern - Oleksandr.

All of the mentioned and the rest of the Lexis team - Antoniya, Dilyan, Radoslav, Stefan, Nikola, Martin, and Victor gathered together with some good old friends from the Bulgarian IT world at the Barter Community Hub to celebrate the company's 5th birthday.  Unfortunately, Ivan missed the party, but was definitely missed.

![Lexis Solutions-Team 2](//images.ctfassets.net/5gydaotbo8jm/7yJGZ6nMf843pFngmgp2rs/74eaa56020fa71b7e820e7d6c5c28ad3/Lexis_Solutions-185.JPG)

Our CEO Deyan gave a speech and presented the company and its development. 

![Deyan giving a speech](//images.ctfassets.net/5gydaotbo8jm/5i6fAFCyBqWQW5XGsGjZFi/d43d2460d3db8354a78e1476df941aa3/Lexis_Solutions-209.JPG)

To honor our celebration, the guests followed a special dress code - to wear the Lexis Solutions' color - blue. 

![Milush and a blue guest](//images.ctfassets.net/5gydaotbo8jm/6qgjCncHtKgIfBYoKLjBIY/8821a4c9a3b117da9e8d5732009625bf/Lexis_Solutions-275.JPG)
![Guests1](//images.ctfassets.net/5gydaotbo8jm/4ksbawPJUFZFTLINiCskVz/147a43bb0ee0594d17504aa2f15de4aa/Lexis_Solutions-289-min.JPG)

There was a lot of delicious food, an open bar, excellent music from DJ Michael Veili, and some specially made Lexis Solutions cupcakes.

![Food](//images.ctfassets.net/5gydaotbo8jm/1lYyN4V6m6R7MeTYzHBQon/9739b1e7b9731de1f4c5c53afcb95f78/Lexis_Solutions-47.JPG)
![TOP DJ](//images.ctfassets.net/5gydaotbo8jm/1JcWCbpUrqzhLOHykWVIvB/fef8b3c029e9a475105293054524b883/Lexis_Solutions-94.JPG)
![Cupcakes](//images.ctfassets.net/5gydaotbo8jm/1k0Qqa42TtGNFamnPTPYjR/59c7d802e73c74daf945b1e529df688c/Lexis_Solutions-242-min.JPG)
![Cupcakes3](//images.ctfassets.net/5gydaotbo8jm/6lgMgKoFmBYpnsqzjxZkXo/18696aeb43be2d94c29a275c51eede3f/Lexis_Solutions-255.JPG)

The team's effort is crucial… especially when blowing up balloons.

![Ballons](//images.ctfassets.net/5gydaotbo8jm/4uioa4X7b0YXtVx2fMvFsq/af8af086ebd3b7951cd7892522efc992/Lexis_Solutions-1.JPG)
![Ballons2](//images.ctfassets.net/5gydaotbo8jm/1UFsKJG9cLiUsswsJBAvLP/d135f650f9a48e91575193d7e20f5d0f/Lexis_Solutions-5.JPG)

[Stoyan](https://www.facebook.com/St.Nedev), our skilled photographer, was always around the corner and captured all the important moments. He also made sure everyone had an Instagram-worth picture.

![Instagram1](//images.ctfassets.net/5gydaotbo8jm/73xRXcZzQxSQ9Quw0Uld26/c14c1c31ad4286aa2e2c6fed74eb0e9a/Lexis_Solutions-97.JPG)
![Instagram2](//images.ctfassets.net/5gydaotbo8jm/3M965LvBNE9drDHH1e4qbf/4c521094e164fb4dde2903fa5cd28c61/Lexis_Solutions-139.JPG)
![Instagram3](//images.ctfassets.net/5gydaotbo8jm/5M7XVE1cnv9JjsL6AfhbpZ/0305b2250ca25ad7b2657a2cdeebc86e/Lexis_Solutions-107.JPG)
![Instagram4](//images.ctfassets.net/5gydaotbo8jm/5qFlR9TzN7cuK3VXhyTFOo/973ca5244cddf48eb8885e67b3fca746/Lexis_Solutions-121.JPG)

Of course, Lexis Solutions' rooftop party wouldn't have been the same without its guests. We thank them for their smiles, good appetite, and sense of humor. 

![Guest](//images.ctfassets.net/5gydaotbo8jm/3V9kBh1t06TnbvxaexEQAA/ada2a87a56f813d58db99fa4fbe65919/Lexis_Solutions-55.JPG)
![Guest2](//images.ctfassets.net/5gydaotbo8jm/22HAcdBPupXQyc0OhFLeR1/ea2e7240a1a1e90a1e2a839bed3ff469/Lexis_Solutions-82.JPG)
![Guest3](//images.ctfassets.net/5gydaotbo8jm/6IxOHnU5SLWiq0ZOi5VHRr/03c624b9eba29873d86bab63d2549d31/Lexis_Solutions-124__1_.JPG)
![Guest5](//images.ctfassets.net/5gydaotbo8jm/4igi8z1eTlLZfmNdIacLDu/d0dfc345a2342ada53d77926177a43c0/Lexis_Solutions-122.JPG)
![Guest6](//images.ctfassets.net/5gydaotbo8jm/MKCoa8pb91qc3VCeYhOuM/9bd5bffa2e8558c5c5730461a89a4882/Lexis_Solutions-164.JPG)


Lexis Solutions is celebrating its 5th anniversary.

5 Years Lexis Solutions: A Rooftop Party

Over the years, software programming has changed, and as a result, testing, which is an essential aspect of software development, has changed as well.

It all began during the programming and debugging phases when detecting faults while debugging was regarded as testing. Testing was given its own identity in 1957 and was viewed as a distinct activity from the debugging process. Until the late 1970s, testing was regarded as a means of ensuring that software met the defined criteria. It was then expanded to discover the flaws and provide the software’s proper operation. In the 1980s, testing was also used to determine quality. It grew in prominence as a result and was handled as a well-defined and managed process inside the software development life cycle

For a better understanding of the software testing evolution, let us take a look at some of the crucial and defining periods separately. 

**1\. Early stages of programming and testing**

During this time, development and testing were viewed as separate tasks. When the software was finished, it was handed over to the testing team for review. Testers were not highly involved during the requirement analysis phase and had minimal interactions with business stakeholders. They were significantly dependent on knowledge passed down to them through documentation created during design and development or expertise gathered from code developers. The testing team’s testing methodologies were constrained due to a lack of understanding of the customers’ objectives and expectations. The testers would create a test plan based on their knowledge of the documentation and test the program on-the-fly. There were some limits, and the testing was not exhaustive.

**2\. Evolving to manual tеsting**

Various approaches, such as agile testing, exploratory testing, and others, emerged in the late 1990s. Manual testing was carried out using comprehensive test cases and test plans.

Exploratory testing allows people to test and break software uniquely by investigating it within the scope of testing charters.

The rapid and extensive expansion of the software development process necessitated increasingly comprehensive testing methods. Agile testing’s incremental and iterative methodology assisted in accomplishing this goal. The iterative testing method made it possible to automate repetitive tests.

**3\. The era of automatic testing**

With the turn of the millennium, a slew of new methodologies emerged, completely overhauling software testing. These methods completely changed the way people approached testing. At every stage of the SDLC, testing was now considered essential. Quality assurance and control have become more critical at every step.

Automation aided in the rapid and accurate execution of regression and sanity testing. Testing was elevated to a new level thanks to automation. The testers were further empowered to carry out their responsibilities with increased efficiency thanks to various automated testing frameworks.

Scaling up the testing process was also necessary during this period. Crowdsourcing and Cloud testing let the company manage product testing faster with less infrastructure and workforce investment.

**4\. Continuous testing era**

Customers wanted to see an intermediate functioning model of the eventual product when the business dynamics began to shift. As a result, there was an increase in demand for regular and medium software releases.

High connection and faster deployment and testing across different platforms were made possible by upgraded network infrastructure. This allowed for more frequent delivery, which resulted in more testing effort.
Continuous Integration and Continuous Deployment have become central concepts. Ongoing testing has also become more critical as a result of these developments.

Shorter delivery cycles have resulted from the rise of DevOps and CI/CD. Risk assessment in real-time has become increasingly important. At every level of the software development life cycle, risk assessment and management were required. Continuous testing aids in the direction of such risks by identifying and resolving issues before each software release.
The business stakeholders expected an interim release with short deadlines and no sacrifices on the eventual product’s quality. Continuous testing needs to improve its efficiency to keep up with these demands. That’s where artificial intelligence comes into play in the testing process.

**5\. The Age of Artificial Intelligence**

Simply put, Artificial Intelligence is a machine’s capacity to see, analyze, and learn to imitate human behavior.

AI algorithms are based on data analysis that predicts the future. This implies that AI testing is primarily reliant on data.

Many AI-powered testing solutions are now available to assist with unit testing, API testing, UI testing, and other tasks. Visual testing is a famous illustration of how AI may be used in testing.

**6\. Summary**

Within the last few years, the software sector has evolved dramatically. While it is difficult to forecast precisely what the next decade will bring, as the IT sector continuously evolves, a new variety of challenges will appear, providing a new set of issues for quality assurance professionals to solve.

While QA professionals are sometimes overlooked, their contributions to DevOps are becoming more widely recognized. Simultaneously, testing will become endemic throughout other aspects of the software lifecycle process, with rapidly emerging technologies bringing tests within reach of a more significant number of team members.

A look at how software testing has become an integral part of the software programming process, its development stages, and an estimation of what the future holds for the QAs.

Evolution and Different Approaches to Software Testing


Back in 1998: When the online world as we know it marked a new era - BackRub, as it was initially planned to be named, launched its first homepage just a year after registering its domain name "google.com."

*But what happens next?*

## The beggining

The Internet giant was founded by Larry Page and Sergey Brin, both colleagues and Ph.D. students at Stanford University. Their first headquarters was actually in the garage of their friend Susan Wojcicki, who later became the CEO of YouTube.

Firstly, $100,000 was invested by Andy Bechtolsheim, owner of Sun Microsystems. By the end of the year, three more big investors contributed about 100 thousand dollars to the development of Google (one of them is Jeff Bezos, the founder of Amazon).

The idea of Larry Page and Sergey Brin was to create a good algorithm for searching Internet pages by a given keyword, so they created the PageRank algorithm, changing the development of the World Wide Web forever. The company's first so-called real office opened a year later in Palo Alto, and a few months after, it was moved to Mountain View.

The initially developed search engine worked in 10 different languages; in 2001, the first image gallery appeared, consisting of 250 additional photos in the search engine. And so, to this day, Google has not stopped developing new products and is constantly growing, entering into valuable partnerships with other companies, and acquiring new ones.

## But why Google?

At least once, you must have wondered where the name Google comes from and what it means. The name of the Internet search engine is a play on words and originates from the word googol, a mathematical term for a number represented by one and one hundred zeros. Over time, the search engine has become so popular that the word is actively used in English.

Did you know that, at the very beginning, when it was created in 1996, the search engine was called BackRub? In 1998, Larry Page and Sergey Brin renamed it Google and their entire business. The word has even been added to the Oxford English Dictionary.

## Logo

The official Google logo has been used since September 1, 2015. The company changed its logo a month later following a significant restructuring. The new logo is the company's product mark, but the font is sans-serif, has slightly softer colors, and looks more contemporary. The logo is executed in a typical style with the logo of Alphabet Inc., the company that "swallowed" Google in early August 2015.

On March 22, 2011, Google was granted a patent for the "Google Doodle." On holidays, famous people's birthdays, and important events, such as the Olympic Games, Google replaces its logo with so-called doodles (English doodle - a simple drawing, scribble), representing illustrations, animations, or even small games related to the given event.

On May 24, 2011, Google replaced the logo with a doodle dedicated to the Day of Bulgarian alphabet and Bulgarian education and culture.

## Older than Google

But Google is not the first internet search engine. There had already been AltaVista, Yahoo!, and others when it was created, but Google stands out with its better search quality and sample ad-free homepage.

In 1998, the company surpassed its competition, AltaVista, created three years earlier. On the day of the first Google tests, the name of the president of Stanford University, Gerhard Casper, was entered. The competing search engine failed to gather information about him and found news about the movie Casper the Friendly Ghost instead. At the same time, Google found an article about Gerhard Casper, thus attracting the attention of many professors at the university. John Hennessey, the man running the tests, known as the "Father of Silicon Valley," hoped that the search engine would find those results exactly.

## The jealous Yahoo!? 

Before Google, Yahoo! was the premier internet search engine. 

Having started to gain popularity, it became Yahoo's search engine provider in 2000. By the summer of 2002, Yahoo! had tried to acquire Google for $3 billion, but Google turned down the deal as it felt it must have been worth more.

Today, Google's net worth in April was estimated at $1853 Billion. On the other hand, Yahoo was sold to Verizon in 2017 for under $5 billion.

## More steps to the more significant success

The company launched Google News in 2002, a content aggregation [service ](https://www.lexis.solutions/services/react-development)that would change the way digital media was published and distributed on the web, Gmail in 2004, Google Maps in 2005, Google Chrome in 2008, and the social network known as Google+ in 2011, in addition to many other products. In 2015, Google became the primary subsidiary of the holding company Alphabet Inc.

In 2004, Google first floated its shares on the stock exchange and gradually began to expand its sphere of activity. The very same year, the company opened the mail service Gmail for invitation-only access. The following year, the mapping service Google Maps was launched, the electronic translator Google Translate began, and the video publishing site YouTube, which appears to be among the most visited worldwide, was bought.

In 2008, the company released the first version of its own Google Chrome Internet browser and Android smartphone operating system. Since 2010, in partnership with various major manufacturers, Google has successfully launched smartphones and tablets under the GoogleNexus brand, and since 2016 - Pixel. (According to the consulting company IDC, devices running Android in the first quarter of 2017 occupied 85% of the global smartphone market).

However, not all Google projects prove to be successful. For example, the social network Google+, launched in 2011, never managed to be equal to Facebook (Meta). The microblogging system Jaik, bought in 2007, was closed in 2012 because it failed to compete successfully in the market against Twitter.

__Resources:__

1. From the garage to the Googleplex. - In: About Google Available from: [https://about.google/our-story/](https://about.google/our-story/) [11.08.222]
2. GOOGLE TURNS 20: HOW AN INTERNET SEARCH ENGINE RESHAPED THE WORLD. - In: Verge. Available from: [https://www.theverge.com/2018/9/5/17823490/google-20th-birthday-anniversary-history-milestones](https://www.theverge.com/2018/9/5/17823490/google-20th-birthday-anniversary-history-milestones) [11.08.222]
3. Google Net Worth 2022: Top 5 Google (Alphabet) Shareholders. - In: Knowledge.com. Available from: [https://caknowledge.com/google-net-worth/ ](https://caknowledge.com/google-net-worth/)[11.08.222]
4. History of Google. - In: Wikipedia. Available from: [https://en.wikipedia.org/wiki/History_of_Google](https://en.wikipedia.org/wiki/History_of_Google) [11.08.222]
5. Price, Dan. 8 Search Engines That Rocked Before Google Even Existed. - In: Make Use of. Available from: [https://www.makeuseof.com/tag/7-search-engines-that-rocked-before-google-even-existed/](https://www.makeuseof.com/tag/7-search-engines-that-rocked-before-google-even-existed/) [11.08.222]


The history of the biggest Internet search engine.

Are you older than Google?

Once you wake up, what do you do? Check your email and social on your phone? But is there somebody on the other side of it?

Let me tell you; there is always somebody - writing, rewriting, debugging,  troubleshooting, updating. And who that might be, you ask, of course, the programmers. 

Frankly, without them, you wouldn't be able to use your phone.

## A programmer without a computer is like French cuisine without butter

It is obvious - the world we currently live in can't function without programmers, but let's first see why programming is crucial.

Software is all around us - it manages our everyday activities, whether work or fun. It plays a role in how companies make decisions, execute tasks, gather data, and more.

Programming has caused a revolution in the industrial and social parts of our everyday lives.

## Coders - the problem solvers

Programming is a process taking three key phases: 

1.  Problem Identification

2.  Implementation  

3.  Maintenance 

Those 3 steps lay on the programmers' backs for them to successfully solve the appearing problems. And making sure that the trouble won't come back.

## IT gurus - the modern creators

Another purpose of programming is to create. Create to make a difference. The languages, machines, compilers, and interpreters are only tools; brushes to painters. Software creation could be seen as an art where the programmers express themselves through functionality and design. Or programming could be simply whatever one intends it to be.

## 26,9 million life changers

Did you know that currently, there are 26,9 million developers in the world? 

### Let's see a few examples of how some of them and their predecessors did.

Computer codes played a pivotal role in ending World War II. An English computer scientist, Alan Turing, was successful in deciphering the Nazis' code machine ENIGMA with his cryptologic and mathematical skills.

During this COVID-19 pandemic, Avi Schiffmann, a teenager, developed one of the world's most popular COVID-19 monitoring websites. He coded ncov2019.live, the admired COVID virus tracker that is one of the most visited corona trackers across the globe. Kautilya Katariya from the UK is the youngest to take up programming at 6. He developed AI applications after completing an array of study materials from IBM. He became a Guinness World Record holder.

## Computer specialists - the new rulers

As the technology, which nowadays shapes our lives, changes rapidly, the programmers' role is only getting more critical. 

People are so used to relying on all the websites - from the social ones to the news - different gadgets and tools - simply because they all make life easier. But the ones guilty of having this ease are the programmers. So next time you scroll through Instagram, check your bank balance online, order food from that particular app, ask yourself who runs the world.

The answer is easy. The programmers!

Did you know that currently, there are 26.9 million developers in the world? 

Who runs the world? Programmers! 

## Introduction

Regular expressions seem complicated, confusing, even ciphered. They easily become hard to read and can lead to performance issues. Their reputation precedes them as a quirky mix between chaos and maths.

I ask you to put your prejudices aside and let me introduce you to the friendly and powerful regex I know. Let's start with the basics.

## What is a regex?

A regex is a string that matches a pattern of text. In most programming languages you surround the string with forward slashes so it is recognized and treated as a regex. `/foo/`, `/[0-9]+\.[0-9]+/` and `/(0[1-9]|1[0-2])/(0[1-9]|[12][0-9]|3[01])/\d{4}/` are valid regular expressions. The first matches the sequence of characters 'foo', the second matches decimal numbers, and the third - dates.

## When to use a regex?

Regular expressions are used when you need to find, replace, split or validate strings. These tasks are so essential that all the major programming languages have a built-in regex engine.

## How to use a regex?

The capabilities of regular expressions are vast and we only go through the basics in this article. You can find more sophisticated use-cases and examples {{here}}.

Most characters, like letters and numbers, match themselves. Creating a regex composed of only alphanumerical characters will be no different than looking for a substring - a function present in the standard library of modern languages. In order to unlock the full potential of regular expressions, we add a little bit of special syntax in the form of quantifiers, tokens, anchors, and groups.

### Quantifiers

Quantifiers are symbols that indicate how many times a given character should be matched.

> Examples: ?, *, +, ...

#### Cheatsheet

a? - matches one or zero of a a* - matches zero or more of a a+ - matches one or more of a a{1} - matches exactly one of a a{1,3} - matches one, two, or three of a a{1,} - matches at least one of a

#### Examples

Lets's have a test sentence: `Son, it's too soon for you to drink alcohol`,and the goal to match both `son` and `soon`.

We can write the following regular expressions that will do the trick

- `/so{1,2}n/` - there are either 1 or 2 "o"s - `/soo?n/` - the second "o" is optional - `/soo{0,1}n/` - the second "o" is an optional alternative

### Tokens

Tokens generally start with a backslash `\` and represent a single or a group of characters. They also provide a way for matching the special characters that are part of the regex syntax.

> Examples: \?, \+, \s, \d, \D, \n, \t, ...

#### Cheatsheet

\? - matches the character *?* \+ - matches the character *+* \s - matches the whitespace character \d - matches any digit \D - matches  any non-digit; the opposite of \d \n - matches the newline character \t - matches the tab character . - matches any character [abc] - matches a single character: *a*, *b* or *c* [a-z] - matches a single character in the range from *a* to *z* [0-9] - matches any digit

#### Examples

- `/\?{3}/` - matches 3 consecutive question marks   - `/\s+/` - matches one or many spaces ⠀◦ useful for splitting user input - like names - `/\d{4}/` - matches 4 consecutive digits ⠀◦ think of years, ZIP codes - `/fi.e/` - matches *fire*, *file*, *five*, because the 3rd character can be anything - `/[A-Z][a-z]+/` - matches words that begin with an uppercase letter and have at least 2 letters  - `/[0-5][0-9]/` - matches all numbers that represent seconds ⠀◦ Imagine a digital clock that goes from 00 to 59

### Anchors

Anchors indicate the start and the end of strings and boundaries.

> Examples: ^, $, \b, \B

#### Cheatsheet

^ - start of string & - end of string \b - word boundary; a position between alphanumerical characters and non-alphanumerical characters \B - non-word boundary; a position between two alphanumerical characters or two non-alphanumerical characters 

#### Examples

- `/^Regex/` - matches strings that begin with *Regex*- `/regex.&/` - matches strings that end with *regex. *- `/^Some\b/` - matches strings that begin with the word *Some*

### Groups

Groups, or capturing groups, are a way to treat multiple characters as the same unit. This way you can isolate regex logic inside a group, or name a group so you can inspect what text it has matched. 

#### Cheatsheet

({regex}) - a group is indicated with brackets around your custom {regex}  (?<{name}>{regex}) - you name a group by writing a question mark right after the opening bracket and surrounding the {name} with less than and more than signs

#### Examples

- `/(\d+)/` - captures all numbers  - `/(?<long_spaces>\s{2,})/` - captures occurrences of two, or more, consecutive spaces

### Extras

There are logical operators in regex too! You can negate and use or, just like in your favorite programming language.

#### Cheatsheet

^ - negation | - or

#### Examples

- `/[^a-z]/` - matches any character which is not a lowercase letter from the English alphabet - `/al|eal/` - matches either the 2 characters *al*, or the word *eel *- `/(al|ea)l/` - matches either the word *all*, or the word *eel *⠀◦ note that using a group isolates the or logic inside of it

## Bringing the pieces together

Regular expressions need some time to sink in. Piling up more syntax will only confuse you so let us practice instead.

### Email validation

#### Basic

`/[^@]+@[^.]+\.[a-z]{2,}/`

This should be one of the simplest regular expressions that validate emails. It can be broken down into 5 parts:

- `[^@]+` - matches one or more characters that are not the character @ - `@` - matches the character @ - `[^\.]+` - matches one or more characters that are not the character . ⠀◦ we escape the dot character as it can also mean any character! - `\.` - matches the character . - `[a-z]{2,}` - matches two or more letters

#### With groups

`/(?<username>[^@]+)@(?<mail_server>[^\.]+)\.(?<domain>[a-z]{2,})/`

Adding groups allows us to match test string and see what we capture in each of them.

> **john.doe@test.com**

Groups: - username: john.doe - mail_server: test - domain: com

> **emil.kirilov@lexis.solutions**

Groups: - username: emil.kirilov - mail_server: lexis - domain: solutions

### Date validation

We will use the `dd.mm.yyyy` format in this example.

#### Naive with groups

`/(?<day>\d{2})\.(?<month>\d{2})\.(?<year>\d{4})/`

> **27.12.2021**

Groups: - Day: 12 - Month: 12 - Year: 2021

> **33.13.2021**

Groups: - Day: 33 - Month: 13 - Year: 2021

This regex is naive because it matches too optimistically. We could provide laughable input and it would find it acceptable. Let's fix it!

#### A perfect enough with groups

`/(?<day>0[1-9]|[12][0-9]|30|31)\.(?<month>0[1-9]|11|12)\.(?<year>[12][0-9]{3})/`

**Breakdown**

Group `day`: - the minimum date is 01, so dates starting with 0, can't end with 0 - all 10s and 20s are OK - 30 and 31 are both possible

Group `month`: - same logic as with day

Group `year`: - only accepts 1xxx and 2xxx years

**Examples**

> **27.12.2021**

Groups: - Day: 12 - Month: 12 - Year: 2021

> **33.13.2021 - no match**

**Considerations**

I labeled this regex as 'perfect enough' because not all months have 31 days, or 30 days, or 29 days for that matter. We could, of course, write a monster regex and account for each month's possible day count, but we won't. It will become unreadable and still for short on leap years.

Be careful not to misuse regular expressions. Our date regex will be exceptional if you need to extract dates in a long text. Perhaps your task is to find the min/max date? Do that with a library or a built-in date parser. Don't compare the year named groups, the month named, and the day named groups of each month.

## End thoughts

Regular expressions are indispensable. They are a specific tool that you won't need every day but can save you days when you correctly recognize a use case. 

I hope that by the end of this article you have a basic understanding and appreciation for the regex power and would, perhaps, revisit it whenever you find yourself in need of a cheat sheet in building regular expressions.

Learn the basics of regular expressions, when to use them and how to use them.

Regular Expressions 101

The Project
Part of Balans.bg (a platform containing specialized resources tailored to accountants and lawyers) was developing custom accounting and financial calculators. The need for these arises from the daily work of professionals - their clients often call them with repetitive requests. The most notable of them are on topics like employee or self-employed remuneration, sick leave, dynamic bonuses, work experience and so on, which take a sizable amount of time to do manually 
Our task was to find a way to automate the solution to many of these requests and in the end, we managed to develop 30+ custom calculators for the platform. In this article, I am going to share one of the more inventive cases we handled - calculating the remuneration for an employment contract.
The Problem
For simplification, I am going to note a few details first: 
There are 4 types of remunerations when signing an employment contract in Bulgaria:
Base remuneration - the base amount, from which all calculations follow, called for short BR
Gross remuneration - calculated as BR + Work experience bonus as a percent of BR + any additional gross bonus (short GR)
Net remuneration - the amount an employee receives, calculated as GR - Insurances - Income tax, referenced later as NR
Budget for remuneration - the total amount an employer must spend for the contract, calculated as GR + Insurances (B for reference)

There are 3 types of bonuses an employer can give out to his employees:
Gross bonus - an amount, which is added to the gross remuneration in the contract
Net bonus - an amount, which is added to the net remuneration
Bonus for the total budget - an amount, which is added to the total budget

Bonuses can be taken into consideration in the calculations as:
An addition to the amount of their type (example - GR of 2000 leva with additional 200 leva gross bonus)
As part of the total amount they are a type of (example - GR of 2000 leva of which 200 leva is gross bonus)
Once a contract is signed, the BR can’t change - any bonus calculation that is given out at some point must increase the other 3 types of remunerations without changing the BR

With these remarks covered, we can move to the purpose of this article.

FAQ
Specialists in Bulgaria often get asked the following kind of questions by their clients: 
How much would it cost me to give out X amount of net salary?
I have an additional budget of X amount this year - how much net bonus would this provide for my employees?
The base salary of my employees is X amount - how much net would they receive if I give out an additional Y amount of gross bonus per employee?
The net remuneration of an employee is X amount - how much gross bonus should I give out to reach Y amount of net remuneration?

We can see that the main question clients ask is in the form “how to reach a remuneration of some type by providing remuneration and/or bonus of some different type”. Or, to put it in a more mathematical phrase, how to find the input of a function by knowing the desired output. 
The Solution
In mathematics, there is a collection of methods called root-finding algorithms that can provide solutions to such problems in some cases. 
To keep it simple, the general approach is iterative and with each iteration, the algorithm tries to approximate a root value that solves the functional equation within a set error margin. If the root value is within the desired error margin - we accept the solution, if not - we iterate further. 
In cases where the desired error margins are too small and/or functions too complex, it is possible that a solution can’t be reached by these methods. In our case though, it was perfect since we are working with money, and error rates smaller than 0.01 don’t make a difference for our final approximation. 
The root-finding method that was chosen for our implementation is called Steffensen's method. The main benefits are:
1. The method doesn’t use derivatives
This means we can use our initial function as an argument for calculating each iteration. The general formula looks like this: 
The downside is that we need to compute the function twice for each iteration, but this is negligible because of our large error margin and because of the next benefit.
2. The method has quadratic convergence
We can think of convergence as “how quickly are we moving towards our desired root approximation with each iteration”, and since this method has quadratic convergence - the number of correct digits in the answer doubles with each step. In our case, it usually takes up to 3 iterations until we approximate a correct solution. 
Important to note is that the initial X value we choose plays a role in how quickly we arrive at a solution. In this case, the most effective approach is to start with the initial result we get from our function for the desired remuneration since adjusting for any payment, regardless of type (unless unrealistically large), shouldn’t throw us off by much. 
Example
We can take for granted that an example function:
takes the desired net salary as an argument
takes the desired bonus of any remuneration type
returns a list of all remunerations

Let’s say a client wants to sign an employee with a net salary of 2000 leva. This means our function yields the following with this input parameter:
BR - 2546,82 leva (base remuneration)
GR - 2577,38 leva (gross remuneration)
B - 3065,02 leva (total budget cost for the employer)

NR - 2000 leva (net salary that the employee receives)
Let’s say that after some months, the employer decides to give his employee a bonus. The budget that the employer can afford is 300 leva, so our parameters now become:
2000 leva net salary and 300 leva as budget bonus
The final result is as follows:
BR - 2546,82 leva (the same base remuneration, which is important)
GR - 2829,65 leva (gross remuneration has increased by 252,27 leva)
B - 3365,02 leva (the total budget has risen exactly by 300 leva)

NR - 2195,75 leva (net salary is now 195,75 leva higher)
Conclusion
The way we managed to get the exact net equivalent with a 300 leva budget bonus is by using our root-finding method with a start iteration value of 2000 to approximate for which net remuneration does our budget equal 3065,02 leva + 300 leva bonus. In this scenario, after a single iteration, we get a correct answer of 2195,75 leva.
This core principle can be used to mix and match any desired remuneration type with any desired bonus type. Our final implementation has in total 16 input parameters and can be accessed on balans.bg.


An article that shares how mathematical approaches can help us in programming.

Applying Numerical Analysis to Automate Payroll

## Introduction
------------

The popularity of GraphQL among development tools is not a coincidence. Even though it requires a bit of a learning curve, the positives of using this protocol are many - strong typing, self-documenting, elimination of over & under-fetching, to name a few examples. Another pattern for building web-based applications that has been on the rise for a while now is microservices. Popularized by Martin Fowler and James Lewis, this architectural style advocates building many small interconnected pieces of independently deployable and scalable pieces of code, bound by business domain, rather than a single (monolithic) application to meet all business needs.

One of the core GraphQL principles is having a single graph for an application. This approach is not very suitable for applying the microservice ideology as it expects every piece of code to be maintained and deployed as a single unit.

Enter Apollo Gateway. The Apollo team maintains the most popular open-source GraphQL framework - apollo-server. Apollo Federation adds further capabilities to an Apollo GraphQL server by allowing it to be a part of a super-schema, with which clients communicate. Each instance of a federated schema provides a sub-schema that implements new types or extends types from other sub-schemas. All sub-schemas are combined into a single gateway by Apollo Gateway, which manages query planning and enforces the integrity of the super-schema. There are many great resources on this topic - the [Apollo Federation docs](https://www.apollographql.com/docs/federation/) are very detailed. I also recommend watching James Baxley III's talk "[Apollo Federation - A revolutionary architecture for building a distributed graph](https://www.youtube.com/watch?v=lRI0HfXBAm8)." This post will not be focusing much on the implementation part but more on the deployment on DigitalOcean's App Platform.

## The Application
---------------

The full codebase of this tutorial can be found on this [GitHub repository](https://github.com/Lexis-Solutions/apollo-federation-demo).

Let's assume we will be building and deploying a skeletal crypto exchange app. Our bare-bones application is composed of two domains - users and orders. All of the code will be in a single repository, but each app is its Node.js project and we have no shared code. The mono-repo approach works great for small teams, and the developer experience is significantly better. 

An important note here is that we will not be using *Yarn Workspaces *in this mono-repo. Even though the idea behind it is neat, it makes the CI/CD process way messier. The culprit here is that we only have a single yarn.lock file, which all services need to use. This means:

1.  The build cache in our CI will always bust for every subproject, even though we have a change in only one.

2.  The build context needs to be the root of the mono-repo, which means needlessly copying the source of the other subprojects.

3.  Harder to split subprojects into separate repositories.

Not using workspaces also has its downsides:

1.  We lose **hoisting**, meaning there will be node modules that are installed multiple times in the different subprojects. I believe that this is a reasonable price to pay, as storage in development environments is usually not a big concern. If you're starting a new project you can swap yarn with [pnpm](https://pnpm.io/), which also implements the workspace idea without the problems outlined above.

2.  Code duplication will emerge. Some files and folders are 100% identical on multiple subprojects. If we follow the DRY principle, this is a no-no. However, by having some code duplication, we retain the flexibility to tweak stuff down the road for each component. The DRY principle is that - a principle, not a rule. Trying to realize it religiously can cause more harm than benefits. Check out this excellent [talk](https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebase) on the topic by Dan Abramov.

## Implementation
--------------

The general outline of our mono-repo looks the following:

![Project Structure](//images.ctfassets.net/5gydaotbo8jm/616JmWVF0jClQZJqKGQ3DO/043413f9d2be2bb6625ea3a56c5251f3/image.png)

The users and orders subprojects have identical project structures that create and expose a simple schema. The "users" schema contains the type "User" and a GraphQL query "me" which returns the authenticated user. By using [type-graphql,](https://typegraphql.com/) we can construct this with just a few lines of code:

```ts
// packages/users/src/resolvers/user-resolver.ts

const users = [{ id: "749ada2c-d348-45c5-ac21-64a018b24b82" }];

@ObjectType()
@Directive('@key(fields: "id")')
export class User {
  @Field() id: string;
}

@Resolver()
export class UserResolver {
  @Query(() => User) me() {
    return users[0];
  }
}
```

It's a very expressive library to use if you are going the Typescript route, saving tons of lines code and potential bugs. Recommend it! Back to our code. The "orders" subproject defines the "Order" type and extends the "User" type by adding a field to it called "orders":

```ts
// packages/orders/src/resolver/order-resolver.ts
const orders = [
  {
    id: "062e5a2d-6fb4-45ea-b928-f069a5a38240",
    cost: 100,
    ownerId: "749ada2c-d348-45c5-ac21-64a018b24b82",
  },
];

@ObjectType()
@Directive("@extends")
@Directive('@key(fields: "id")')
export class User {
  @Field()
  @Directive("@external")
  id: string;

  @Field(() => [Order])
  orders: Order[];
}

@ObjectType()
export class Order {
  @Field()
  id: string;

  @Field()
  cost: number;

  @Field()
  owner: User;
}

@Resolver(() => User)
export class UserResolver {
  @FieldResolver(() => [Order])
  orders(@Root() { id }: User) {
    return orders.filter((row) => row.ownerId === id);
  }
}
```

Both the "orders" and "users" Apollo servers need to be "federated" for the gateway to be able to work with them. You can't just pass the schema to the ApolloServer constructor, but you need to pass the result of buildFederatedSchema (from the @apollo/federation package) as the schema:

```ts
// packages/orders/src/index.ts
async function buildApp() {
  const schema = await buildSchema({
    resolvers: [path.resolve(__dirname, "resolvers/**/*-resolver.ts")],
  });

  const federatedSchema = buildFederatedSchema({
    typeDefs: gql(printSchema(schema)),
    resolvers: createResolversMap(schema) as any,
  });

  return new ApolloServer({
    schema: federatedSchema,
  });
}

const port = process.env.PORT || 4002;

buildApp()
  .then((server) => server.listen(port))
  .then(({ url }) => console.info(`Orders server listening on ${url}.`));
```

To bring those two together, we need the gateway. For it to work, two items need to be fulfilled:

1.  All of your services need to be up. If any of the services is not reachable, the gateway will not be built and the whole app will crash.

2.  The supergraph needs to be a valid GraphQL schema. Meaning it's subject to all of the checks a regular schema needs to pass - no mismatches or ambiguities on the defined types are allowed. The package outputs very useful info when something is not right, outlining the specific service that is problematic, so this is great for avoiding any miscommunication between teams that might have different assumptions over the parts of the graph that don't belong to them.

In order to fulfill 1. we use the `wait-on` npm package, which constructs a promise that resolves when all of the given URLs have started a TCP connection:

```ts
// packages/gateway/src/index.ts
waitOn({
  resources: serviceList.map((service) => service.url),
  validateStatus: () => true,
  timeout: 60 * 1000,
});
```

One important trick is to start the gateway server before adding the GraphQL middleware to it because DigitalOcean follows no particular order when starting your backend services. So in case, the gateway is not attempted to be started last, the `waitOn` promise will timeout, and the whole deployment will fail. This is why we bind to the 4000 port even though we have nothing yet, and when the services are ready we add the GraphQL layer to the express server.

Once every component is running, we can start our gateway and inspect the explorer:

![Sandbox Query](//images.ctfassets.net/5gydaotbo8jm/6NnbIn3EuYY0qkxHSFAlNi/d0eacb41e7d332958c592501535877d6/image.png)

We can see that we can query "orders" on the "User" object in the "me" query. Neat! We are ready to deploy.

## Deployment
----------

DigitalOcean provides a very handy and programmatic way to deal with the specification of an application and its subcomponents by using a YAML file called the App Specification. This [reference](https://docs.digitalocean.com/products/app-platform/references/app-specification-reference/) is a must-have bookmark.

We define 3 web services - users, orders, and gateway. Only the gateway exposes a public path, while it communicates with the other services using their private URL.

Some noteworthy points in the [app-spec.yml](https://github.com/Lexis-Solutions/apollo-federation-demo/blob/6cbbebf74624289907c19cb0d1bc088de0d3cca2/app-spec.yml) file:

-   DigitalOcean offers images for programming languages that are equipped with the tools needed to run a service. In our case that will be the Node.js image. We mark this by using the `environment_slug: node-js` option for each of the services.

-   For minimal DevOps efforts, we can automate deploys by using the `deploy_on_push: true` option and a new deploy will be triggered each time there is a new push on the branch you select, in our case it's master.

-   Notice how only the gateway has a public route (/). The other services are exposed through port 80 in an internal network, which the gateway reference simply as `${users.PRIVATE_URL}` and `${orders.PRIVATE_URL}`.

The easiest way to create an app using an app-spec file is by using [doctl](https://github.com/digitalocean/doctl). After you have successfully installed and authenticated with the CLI tool, simply run

```sh
doctl apps create --spec app-spec.yml
```

And that's it! When you go to the DigitalOcean dashboard, under Apps you will see that your application is created and your first deployment is running. After completion, you can access the gateway using a generated public URL, which you can further override with your custom domain.

## Sum-Up
------

We just created an app with a microservice architecture and applied the [gateway pattern](https://microservices.io/patterns/apigateway.html), all contained in a mono-repo. We then deployed an environment for the app on DigitalOcean with 0-downtime updates on every GitHub push. Having separated the components, we can monitor their performance under the **Insights** tab and if necessary, scale each component individually - both vertically and horizontally!

Of course, there are some drawbacks and limitations with this approach that need to be mentioned:

-   Currently **Apollo Federation does not support GraphQL subscription operations**. If you rely on subscriptions in your app, some extra steps need to be taken to make it work. You can check out [this article](https://www.apollographql.com/blog/backend/federation/using-subscriptions-with-your-federated-data-graph/) that goes through a decoupled architecture with a federated schema alongside a subscription service, to which your client connects. Other alternatives might be using SaaS solutions like [Pusher](https://pusher.com/) or Firebase to push real-time data to clients.

-   The federation query planner might not always make the best decisions on how to fetch and combine data, so if you are running into **performance** issues with queries that span multiple services, make sure to check out the Query Plan in the GraphQL playground to get a better sense of what happens when a client sends a query. There are some directives designed to hint to the query planner on how to do things best (e.g. [@provides](https://www.apollographql.com/docs/federation/federation-spec/#provides), [@requires](https://www.apollographql.com/docs/federation/federation-spec/#requires)).

-   As of October 2021, there is **no autoscaling** on the App Platform, it's still WIP and expected to arrive by the end of the year. Once introduced, the platform will cover the automation of both the deployment and reliability, a welcome feature for dev teams.

The [repository](https://github.com/Lexis-Solutions/apollo-federation-demo) for this tutorial can be found on [Lexis Solutions' GitHub profile](https://github.com/Lexis-Solutions/).

Learn how to build a microservice-architectured Node.js app with the gateway pattern and deploy it to DigitalOcean's App Platform.

Deploying a Federated Apollo Microservice App to Digital Ocean

## Our work

[Meet.direct](https://lexis-solutions.com/index.php/portfolio/meet-direct/) started with a Web app and a native iOS app written on Swift. The iOS app validated both the business case and the business model and the platform was getting traction as the number of users rose every day. At this point, our team took responsibility for the [Web app](https://lexis-solutions.com/index.php/2020/07/26/meet-direct-web/).

Not long afterward there came a demand from the Android users -- they also wanted a native app. The team decided on re-writing everything on React Native. This was the only reasonable approach as otherwise, the client would have to hire yet another dev team.

React Native makes it easy to simultaneously develop for both Android and iOS, and we effortlessly replaced the Swift app with minimal cost. The benefits for the client were tangible:

-   two mobile applications that looked and felt truly "native"

-   the programming language among the web & mobile apps became just one

-   the development team was one

-   the codebase was being shared

React Native allowed for a straightforward deployment on Google Play & Apple Store.

## Results

As a result, every new feature and hotfix would be implemented in a single place, reducing time to market and expenses more than twice.

Meet.Direct is a social platform that connects businesses and people. It provides businesses more exposure and statistics about customers and discounts to private users.

From the front lines