Lexis Solutions was founded with the sole intent of providing companies with a product that meets their business needs. Having entrepreneurs experience ourselves, we provide ideas, new viewpoints, and useful tricks which ultimately save the client time and money. We replenish our creativeness by actively engaging with the latest technologies, which occasionally bring about a new app.

Our team is excited to announce that Clutch has named Lexis Solutions a top B2B company in Bulgaria in the development category! We are honored to be listed among the top app developers in Bulgaria on Clutch!

Based in Washington, DC, Clutch is a B2B rating and review platform. Their team conducts independent research into the past clients of companies listed on their site. These verified reviews form the basis of their rankings and awards.

> The team is more than happy to be recognized as one of the best in the region by Clutch. We strive to provide our partners with unparalleled engagement and transparency in the work process. Getting the recognition from Clutch only strengthens our belief that this is the right path.
> CEO

We are thankful for all of our wonderful clients, especially those that left us reviews on Clutch.co! Check out what they had to say about their experience working with us:

> They're very flexible, and they always provide real quality. So far, Lexis Solutions hasn't provided us any bad work. They test everything before delivering it, which is outstanding."
> CIO, Technology Startup

Both this award and our perfect 5-star rating were made possible by your support over the years!

Deyan

Clutch's team article about Lexis Solutions


Clutch

Lexis Solutions Named a Top Bulgarian B2B Company

Bilyal Mestanov

Replacing Swift with React Native

Office

Milush-photo

Radoslav

Bug illustration

grapnel

Emil Kirilov

Project Structure

Deyan Denchev

Sandbox Query

Accounting

regular expressions 101

Mira

Programming

Lexis Solutions-Team

Web Developer

Milush Karadimov

Software Developer

Radoslav Kosev

QA Engineer

CEO & Partner

Mira Ereeva

Growth Manager

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 Bar to celebrate the company's 5th birthday.  Unfortunately, Ivan missed the party, but was definitely missed.

![Lexis Solutions-Team](//images.ctfassets.net/5gydaotbo8jm/aMrIwpPzTpyncG2aV1X0X/e59b829f9121970e4e4aad71150e5a42/Lexis_Solutions-183.JPG)
![Lexis Solutions-Team 2](//images.ctfassets.net/5gydaotbo8jm/7yJGZ6nMf843pFngmgp2rs/e2dd85e0495273c8eb4c58054aeb4a95/Lexis_Solutions-191.JPG)

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

![Deyan giving a speech](//images.ctfassets.net/5gydaotbo8jm/5i6fAFCyBqWQW5XGsGjZFi/4e810a425ff9750cd6e4eb183dc222f6/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/47ae7cd66cfbfffa1f9ad9e78012469a/Lexis_Solutions-275.JPG)
![Guests1](//images.ctfassets.net/5gydaotbo8jm/4ksbawPJUFZFTLINiCskVz/eca194393984fa03880917830b39e3f3/Lexis_Solutions-290.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/40e1583e47307513986de5015a1a1ed9/Lexis_Solutions-47.JPG)
![TOP DJ](//images.ctfassets.net/5gydaotbo8jm/1JcWCbpUrqzhLOHykWVIvB/7263248f1f58dce74e2005e45123c684/Lexis_Solutions-94.JPG)
![Cupcakes](//images.ctfassets.net/5gydaotbo8jm/1k0Qqa42TtGNFamnPTPYjR/09304e02c511977f50d7f0cacbb4f1fe/Lexis_Solutions-241.JPG)
![Cupcakes3](//images.ctfassets.net/5gydaotbo8jm/6lgMgKoFmBYpnsqzjxZkXo/d2c78205d38c2df97e095996331e8327/Lexis_Solutions-255.JPG)

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

![Ballons](//images.ctfassets.net/5gydaotbo8jm/4uioa4X7b0YXtVx2fMvFsq/f6927329e6549262a6fd120d71cb4177/Lexis_Solutions-1.JPG)
![Ballons2](//images.ctfassets.net/5gydaotbo8jm/1UFsKJG9cLiUsswsJBAvLP/a47dbfd10464b970be9701d2e9bd6458/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/891ee97e8532909f8309627f9153d051/Lexis_Solutions-97.JPG)
![Instagram2](//images.ctfassets.net/5gydaotbo8jm/3M965LvBNE9drDHH1e4qbf/91f2948839b34477efb54663be84043e/Lexis_Solutions-139.JPG)
![Instagram3](//images.ctfassets.net/5gydaotbo8jm/5M7XVE1cnv9JjsL6AfhbpZ/669838d307a37daa5b2db132c7ac374e/Lexis_Solutions-107.JPG)
![Instagram4](//images.ctfassets.net/5gydaotbo8jm/5qFlR9TzN7cuK3VXhyTFOo/154204fe927d307a14f71cde9872b03b/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/c6108509db5b8b08e6eb020027524189/Lexis_Solutions-55.JPG)
![Guest2](//images.ctfassets.net/5gydaotbo8jm/22HAcdBPupXQyc0OhFLeR1/8f30554dccc9e061b814794e955f19ad/Lexis_Solutions-134.JPG)
![Guest3](//images.ctfassets.net/5gydaotbo8jm/6IxOHnU5SLWiq0ZOi5VHRr/eb987912b617e67004b3c91782217050/Lexis_Solutions-124__1_.JPG)
![Guest3](//images.ctfassets.net/5gydaotbo8jm/7qLVbLGQj2SPa7bMX4V1DL/49b2bd1d90bfdb0a9206991e0b65bab3/Lexis_Solutions-92.JPG)
![Guest5](//images.ctfassets.net/5gydaotbo8jm/4igi8z1eTlLZfmNdIacLDu/62a0f12d51371229050164b572d9c48f/Lexis_Solutions-122.JPG)
![Guest6](//images.ctfassets.net/5gydaotbo8jm/MKCoa8pb91qc3VCeYhOuM/10ecb583dab5c54abf39ca5f43bd74c6/Lexis_Solutions-164.JPG)


Lexis Solutions celebrating its 5th anniversary.

5 Years Lexis Solutions: A Rooftop Party

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

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! 

Over the years, software programming has changed, and as a result, testing, which is an important 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 as well as ensure the software's proper operation. In the 1980s, testing was also used as a means of determining 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. During the requirement analysis phase, testers were not highly involved 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 with the use of comprehensive test cases and test plans.

Exploratory testing provided people the flexibility to test and break software in their unique ways 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 important at every stage.

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 a myriad of automated testing frameworks. Automation aided in the rapid and accurate execution of regression and sanity testing.

Scaling up the testing process was also necessary during this period. Crowdsourcing and Cloud testing let the company manage product testing at a faster pace with less infrastructure and manpower 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 intermediate 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 prominent concepts. Continuous testing has also become more important 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 management of such risks by identifying and resolving issues prior to 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 exactly what the next decade will bring, undoubtedly, as the IT sector continuously evolves, a new variety of challenges will appear, providing a whole 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 larger 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

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

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.

Refreshing news for developers and designers

Lexis Solutions Named a Top Bulgarian B2B Company

Latest articles

5 Years Lexis Solutions: A Rooftop Party

10 Lessons I Learned in 6 Years of Software Engineering

Who runs the world? Programmers!

Evolution and Different Approaches to Software Testing

Regular Expressions 101

Applying Numerical Analysis to Automate Payroll

Deploying a Federated Apollo Microservice App to Digital Ocean

Replacing Swift with React Native

Lexis Solutions Named a Top Bulgarian B2B Company