Bilyal Mestanov

Replacing Swift with React Native

Milush-photo

Clutch

grapnel

Project Structure

Deyan Denchev - new2

Sandbox Query

Accounting

CTO & Co-Founder

Milush Karadimov

Software Developer

Deyan Denchev

CEO & Co-Founder

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.


Explore how mathematical methods and numerical analysis help solve programming problems, using payroll calculations as a practical example.

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.

How Meet.Direct moved from Swift to React Native: a look at mobile development for a social platform connecting businesses and customers.

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 recognized Lexis Solutions as a top Bulgarian B2B company in 2020. Read about the award and the client relationships behind it.

From the front lines

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