In simpler words, code refactoring means **restructuring** but keeping the functionality at the same time. Refactoring is needed when
software engineers need more **abstraction** or when the **business logic has changed** and the code which worked well in the past won't fit or won't be optimal/effective anymore.
#
Project managers, project owners, and non-technical people often ask developers: "Why do we need to spend time and money to refactor the existing code which perfectly works if we get the same functionality at the end?". Well, actually, **developers spend every day at least 20% of their coding time refactoring** the existing codebase! Whenever developers implement a new feature or fix bugs, they need to touch those part of the code that does not directly belong to the original domain. Saying this, doing refactoring is part of the everyday work for a developer. 

#### The Payment API Project

One of our clients entrusted us with moving forward with their existing application. The application is an API, a _payment gateway_ between many-many payment providers like PayPal, Sofort, Apple Pay, etc. The scope of the project was to add new functionalities for fixing bugs and maintaining the infrastructure.
#
The **technology scope** is PHP 7.1 backend with Symfony 3.4, MySQL database, and Redis, in AWS EC2 cluster with 4 instances and a load balancer. The application had to serve a **couple of thousands transactions per day**.

#### The challenges and the solutions

When our development team took ownership of the application, they realized there are some gaps in the logic:
- it used event bubbling which was not the best for the performance; 
- missing indexes in the database;
- bad code structure with lots of unused/deprecated code fragments. 

The **first idea** was to do the refactoring in small pieces. Meanwhile, the number of incoming requests has started to grow because of the new clients and merchants lots of payment data that has been migrated into the database from the other systems. All these happenings with the bad structure of the database and code caused more and more issues. They made harder not just the feature development but the stability of the application as well. We couldn’t get reports from the database in a proper amount of time because of the slow queries. 

#
Whenever we had **issues**, it was **hard to identify** them because of the bad logging. Long response time with third party services and bad design caused transaction failing and when we started to fix an issue and dig deeper into the domain, we found more and more bad logic and implementation into the codebase.
#
First, we tried to **scale up the infrastructure** just to save some time, but we achieve a point soon when it could not work anymore. So we started to talk about these issues with the client to help them understand what the problem is and how it can evolve.  We created a **time and effort estimation** to show how much time it could take to update the PHP/Symfony version, refactor the data model, etc. We also compared it to the time and effort of creating the same application from scratch. We collected all the pros and cons and calculated a lot of stuff, e.g. how much time it takes to add a new provider to the old app compared to the new one, how long it takes to find a bug in the code in the new structure, etc. While the management was discussing the financial side of the work and was trying to choose the best option for the long term, we created the architectural plan for the new application.
#
The plan was not just to rewrite the application as it is, but we had to be able to scale it up vertically and horizontally as well. We decided to **separate the application from the services**.  Every service has its task, the gateway had to process the incoming requests, communicate the database, do all the authentication/authorization work, call the 3rd party fraud service to check whether the payment can happen or not, collect the merchant data for the provider authentication, and then only pass the necessary information to the provider service. This service transforms the given data to the specified format for the payment provider, calls it, and then transforms the response to a common format and returns it back to the gateway for further work. The scheduled tasks service for report generation and all the background tasks and non-time-sensitive processes have their own separated service. Like the front end with the dashboard for the managers and the user manager part as well.

#
One of the **largest changes** was the **database** and **data model.** In the old system, we stored the data in bad normalization way. Sometimes we had the same data twice or more in different tables. So, we created a normalized database structure, eliminated the non-used attributes/duplications, and added the proper indexes, foreign keys into the tables. As a result, we got back the power. The queries are now fast, the access of the data is also fast, and the load of the database has been deceased. The other important change was that we i**ncreased the usage of the Redis** to store as much data as we can in the cache to avoid unnecessary database queries.
#

#### Refactoring - Is It Worth It or Not?

In our case yes, definitely, but it's not always this easy. Most of the time deciding whether a project needs full refactoring or rewriting rather than moving forward with fixing a ton of smaller pieces to achieve better performance is hard because it **depends on a lot of parameters**. Measuring the refactoring of a huge project like this is not always accurate.
#
Sometimes it may seem easier to write everything from scratch, but it has a lot of side effects. 
When the database changes, old data has to be migrated. When the API endpoints change it causes extra effort from the client-side to implement the new version. However, there are cases when this is the only solution.
#
So, **our advice is the following**: before saying that you need to start again from scratch, step back and start investing all possible options. What if you take out a critical part from the code and put it into a separated service? Does scaling up the infrastructure help? What about buying an application from the market and personalizing it? 
#
These are just a few topics that are worth thinking of before rewriting an application as well as before creating a totally new one. 


Refactoring.png

Refactoring or starting everything from scratch - which is the best decision?

Every project development consists of different stages. In software development, the business practices of building applications are referred to as a life cycle. The **software development life cycle (SDLC)** consists of different stages, usually, 6 to 8, like planning, setting up requirements, creating a design, building, documenting, testing, deploying, and maintaining. 
#


However,  every project in its lifecycle gets to the point when **refactoring** is needed. But what is refactoring and what are the pros and cons of it?

Refactoring - Is It Worth It or Not?

### Business problem

Our client has multiple business opportunities to run interactive content in various locations. They already had a few of them running in environments where internet access was limited.
#
As the number of opportunities has raised, our client asked us to help build a platform that is capable to speed up their content creation and distribution process and implement a reusable solution.
#
Based on the initial discussions, the constraints of the possible locations and the desire of handling content were clarified, but the actual content modeling was a grey area for everybody.

### Goals

We have aimed to provide a specialized content management platform with a built-in preview, separated web-based preview, and content distribution sub-systems.
#
We have formulated our constraints toward technical solutions:

-  the solution needs to be flexible to support sharp changes in the content management domain without major development effort
-  the interactive content needs to be usable offline
-  the business logic needs to be shared between multiple components
-  the content management and preview components need to be available online for our client only

### Solution

It was obvious that the content editor and display were web frontend heavy, where the developers would spend their time the most.
By adding a heavyweight backend for sharing the business logic we would have slowed down the team by introducing unnecessary dependency between frontend and backend work.
#
This was the main motivator to let the frontend development flow without blockers, we just need to find the correct tool for supporting it from the backend side.
#
This tool was [Hasura's GraphQL Engine](https://hasura.io/), which allowed us to just model our database, and it was exposing it as a GraphQL API.
#
We took advantage of the GraphQL Engine features like
#
- Role-Based Authorization using OAuth 2 JWT tokens
- Custom REST actions to control Digital Asset Management integrations
- Schema Migrations to do database refactoring
- GraphQL Subscriptions to provide a better content management user experience by displaying real-time changes from the database
- The Admin console where every developer could change the database or other settings

As the GraphQL Engine provided a solution for all data access needs of the web applications, our __backend efforts have been freed up__ to cope with the tasks from the problem domain.

## Drawbacks

Having close relationship between GraphQL schema and the database schema, every change in the database can possibly introduce updates to multiple web applications. In more traditional systems a backend hides the data storage complexities from the clients by having a separate interface. Without this interface, the _risk of overcomplicating frontend code_ in the web application rose, and possibly destroying the sustainable pace of development.
#
The business logic has been also pushed into the web applications, thus additional effort was needed to _keep logic in multiple applications in-sync_ with each other.
#
Unfortunately, we had to create and roll out our _own content management user interface_, because GraphQL Engine is not a CMS system. In the end, this was the only drawback that we had to solve by coding ourselves.

### Win against the drawbacks

We have placed _shared logic into libraries_, which multiple web applications could use later. These libraries helped to reduce the maintenance cost of keeping logic in sync across multiple web applications. This is a simple, but effective software design trick.
#
Using a _monorepo_ for storing all components code allowed us to _validate the GraphQL queries against the actual database_ and GraphQL Schema in a build pipeline. This prevented lots of bugs and investigation time.

### Advantages

The GraphQL Engine has _boosted our development_, frontend developers could easily modify database structure and progress with their tasks without relying on somebody.
#
This shows that this tool is excellent for rapid validation of experiments. Basically, this is what we were searching for as our first goal.
#
To support offline available interactive content, we used _Jamstack_ and implemented with _Next.js as the site generator and GraphQL Engine as "Headless CMS"_. This duo is working nicely together, also using Typescript, the build time validation of GraphQL queries was extremely easy.
#
I also would like to emphasize the _Hasura's documentation_, which helped a lot in integration with Auth0 and setting up the production deployment. The GraphQL Engine is lightweight, it needs _minimal resources_ under the load we have and scales well when needed, and it has free and open-source variants.

### Conclusion

Overall we had allocated 3 frontend developers and 0.5 backend developers to this project. 
To show the time gained using Hasura, let me share that the backend developer also prepared the cloud infrastructure and implemented the majority of the content delivery solution while working only half-time on the project. Without the GraphQL Engine, there would have been several weeks of development just for getting the data from the database to the frontends.
#
I am glad that we found and used this tool, and I also suggest for everybody who has a similar situation as we had, give it a try.


IOP.png

Developing a flexible and interactive content-management platform without a heavyweight backend logic is not myth, it's reality!

Content management is not always easy. Limited internet access, slow distribution processes, and restricted offline usage are influencing interactive content creation and running. Our software engineers had to develop a platform that not only eliminates these but also works fast and efficiently without a complicated backend logic. The solution for this was Hasura's GraphQL Engine.

Saving Backend Development Time in a Complex Project - Hasura GraphQL Engine

Atlassian has hosted its annual **Atlassian Summit of 2022** (called Team 22) at the beginning of April.
#
![MicrosoftTeams-image (10).png](https://tis-tis-io-asset-prd.s3.eu-central-1.amazonaws.com/Microsoft_Teams_image_10_9f9b59a11d.png)
#
The Atlassian toolchain has been defining the "software development / CI/CD / service management support" market for years now. It's a well-built foundation that has a lot of the bases covered if you plan on being in the "software development for hire" business. Right up to the point where, if you are running a small team for yourself (or for an external company), chances are, you can get up and running with their toolchain with very little effort.

### Why is it good to attend conferences like this...?

...You might ask. Well, there are many good reasons, but here are just a couple. I'd say if you want to keep up with industry trends, you might want to take a look at what the big players are doing. And in this regard, the **Keynotes** are the best source of information.
For example, in 2019, they promised to focus more on the Cloud version of their infrastructure. In 2020, they announced they will not be selling standalone server licenses for their products anymore and will be focusing on the Data-Center editions, (recommending also to run them in a multi-node configuration, also making it possible to run them in containers).
In 2022 the software development best practices start with running your application in a container and run in the cloud.
I'm not saying they are the one and only vision to be followed, but it **gives a pretty good sense of where trends are going**.
#
When I started working with JIRA around 10 years ago, we were using the application a bit differently than it was intended. Not for software development, but for work management, and work intake automation.
At that time, the Atlassian Marketplace was crawling with new apps, vendors, and with new ideas and functionalities. There was a need for developing custom plugins to make sure they do everything that you want in the exact way you want it.
#
One of the key changes in this year's Conference was that **the number of plugin developers**, who were strictly in the business of plugin development was far less, and the number of "Solution Providers" have risen.
When discussing this finding with one other attendee, he said: "All the good software has already been written. We now need to teach people to use it."
#

### Why was this event special?

They usually host an event like this every year. Then... COVID happened. For everyone.
#
But the past 2,5 years have changed a lot of things. Hybrid work schedules and working from home have become the **new standard for employment**, as companies who wanted to stay afloat adjusted to the needs of their employees and the needs of the market.
#
This has also influenced the way people work together, and the way people interact with their productivity software as well. Everybody is available online.
Daily stand-ups, quick catch-up meetings, end-of-day statuses, virtual coffee times, and online team buildings have become a new standard of "hanging out" with colleagues.
And companies have started to invest in software to make these happen. But doing so, there was **a new phenomenon** that the companies had to deal with: **an average software team uses 25 apps to support collaboration.**
#
 ![Géza Kép 1.png](https://tis-tis-io-asset-prd.s3.eu-central-1.amazonaws.com/Geza_Kep_1_629b728a52.png)
#
So this year's biggest focus was **INTEGRATION**.
#
Atlassian has published **over 50 integrations** with third-party apps. Integration, because everybody has their own expertise. Every tool has its own way of working. And the platforms have to adapt to that to make sure that these applications have the ability to communicate with one another.
#
This is actually a pretty important and valuable trend to follow. We're gone from a vendor providing their own solution in every single space you want to making sure the software you already use collaborates perfectly. Because **why not use the best tools for the job you have, rather than always reinventing the wheel.**
#
And the biggest takeaway that should apply to every software developer in 2022...
**Today's software is not written, it's assembled...**
#
Having that in mind, **stay tuned for next week's post** about how we used a standard GraphQL engine instead of developing a custom backend for our customers.

Atlassian.png

Is today's software only assembled, not written? Is it still worth attending conferences?

Conferences, workshops, and networking events have all been part of our lives. However, since COVID happened, it has changed the way we live and collaborate irreversibly. Is it still worth attending these or have they been replaced by online events?

Atlassian Team '22

### About the project

We started the collaboration on this project in the **early phase** of the actual development, even though some of the **base logic** like authentication, roles, some placeholder API endpoints were **already implemented**. 

The team at that time consisted of 3 people working on the client’s side, and 3 people joined gradually from our side. 

The **technical background** of the application is a PHP backend with Symfony framework, MySQL database, Redis cluster, a RabbitMQ for the messaging and some other small services running in a Kubernetes environment. It’s always fun to start working on a project like this, because on one hand we can use a lot of different types of technologies, and on the other hand it is a huge challenge to keep it fast, secure, and well-designed until the end of the development.
 
### Challenges – the good ones
 
The scope of this project and the **technology stack is exciting** for a developer, especially handling different types of data sources, processing huge data files in the required time frame. These challenges need non-standard or out of the box complex solutions.
 
 
### Challenges – the not so good ones
 
The **first challenge** is not a huge one, but it can be a pain sometimes: when the team started to grow, we had to design and agree on **branching strategy** to be able to manage the source code properly. It was needed to avoid a lot of merge conflicts and “cherry picking” features during the development to save time. When a smaller team was working on this project with 1 or 2 developers, it was not a problem, but after we joined the team and the number of the merge requests started to increase, the tech lead had no time to review these on time. As a result, it started to cause a lot of extra work because of the **dependency between the requests.**

The **solution** is to **delegate** some of the responsibilities, so that no one would be too busy. We had the trust of the client, so now we are reviewing each other’s changes, so the development can go faster, and the tech lead could work on what is most important: **understanding the requirements**.

The **second challenge** is much bigger, and it has a lot of side effects, that cause other challenges. As I mentioned, this project is now in the **prototyping phase**. It means that a lot of requirements are not done, missing, or constantly changing.

We can say that it is totally fine, because as software developers, we are used to it, and this is the core of the Agile method, but changing the data model takes too much time, because it affects the entire application.
Unfortunately, we have no time to step back and finalize the whole data-model/architecture, so we always need to refactor a bunch of business logic.

The other side effect of this type of development is that many times when a requirement has changed, for the small issues we said, “we will fix it later” and the list of these “fix it later” issues are getting larger and larger. Unfortunately, we faced such problems in the past: everyone thought that a feature has already been implemented, and when we wanted to use that feature, we realized it wasn’t.
We do not currently have a silver bullet solution for this issue. Dedicating more time to understand the requirements and working with the end clients much more closely to clarify that constant functional changes affect not just the deadline, but the software stability as well.
 
 
### Summary
 
The velocity of the development could improve, but we are steadily making progress and we definitely see, that the team members are doing their best to complete the project successfully and avoid as much pain as possible. But in the end the most important thing is to bring some golden value to the clients.
 
So the conclusion is: **Software development is hard but we enjoy it.**


Project.png

Prototyping a project is both challenging and exciting at the same time. Would you agree with this? 

Prototyping a project is both challenging and exciting at the same time. Would you agree with this? And what if there is already a team that has laid the base and you have to pick up the work from there? 

Well, this is what we had to do for one of our clients recently while developing an application for a telecommunication company. The goal of the application is to be able to manage the administration, data integration, data merge from different types of sources, and user data management.

Prototyping a New Project: Challenges and Solutions

While Strapi's own [documentation](https://docs.strapi.io/developer-docs/latest/plugins/graphql.html) is good for adding GraphQL support, it also confusing **what customizations are available** when somebody wants to use GraphQL. As our project is using Strapi v4, we had to learn how to create such queries, compared to v3.
#
The first example under the official GraphQL documentation's [Customization section](https://docs.strapi.io/developer-docs/latest/plugins/graphql.html#customization) is a showcase of the capabilities without providing much context. That example - next to some ShadowCRUD settings - creates two object types (Book and Article), a custom [Nexus](https://nexusjs.org/) plugin, overrides a query resolver for an existing content type (address) and disables authentication for the same content type (Query.address).
#
For me, it was hard to see **how to set up a new query,** **define new types** and **how to re-use already existing types** from other content-types. As our project is using Strapi v4, we had to learn how to create such queries, compared to v3.
#
Eventually, we could explore the documentation, the Strapi codebase and the examples of official plugins (like users and permissions plugin) and conclude a way to **effectively add GraphQL customizations**.
#
**This post is showing the results of our findings and aims to help the developers who need to achieve similar goals with Strapi v4.**

## The domain for the example

Let's assume that we are developing an e-commerce site where we sell products. One day we would like to add a feature to track popularity of each product using a third party solution. To keep the API keys secret at the server side, we are planning to define a new GraphQL query to the existing GraphQL schema provided by Strapi.
#
This query will handle the integration to the 3rd party API and optionally return the product data if requested.

##  Initialize the project

For the sake of simplicity, we are setting up a new Strapi project for this example using the official guide, thus using npx from command line: 

```bash
 npx create-strapi-app@latest graphql-example --quickstart
```

After creating the initial administration account, we can use another terminal window to proceed.

###  Define the Product content type

In order to add a `Product` content type with an API and a single attribute called `name`, you can use the command line interface or the started admin web interface.

I will use the CLI so I can include its output. 

```bash
 npm run strapi generate content-type
```

```bash
? Content type display name Product
? Content type singular name product
? Content type plural name products
? Please choose the model type Collection Type
? Use draft and publish? No
? Do you want to add attributes? Yes
? Name of attribute name
? What type of attribute string
? Do you want to add another attribute? No
? Where do you want to add this model? Add model to new API
? Name of the new API? product
? Bootstrap API related files? Yes
✔  ++ /api/product/content-types/product/schema.json
✔  +- /api/product/content-types/product/schema.json
✔  ++ /api/product/controllers/product.js
✔  ++ /api/product/services/product.js
✔  ++ /api/product/routes/product.js
```

###  Add GraphQL plugin

The Strapi quick start project does not contain the GraphQL plugin, so we have to install it. You can follow the [plugin's documentation](https://docs.strapi.io/developer-docs/latest/plugins/graphql.html), however, it is just as easy that running this command:

```bash
 npm run strapi install graphql
```

When your Strapi application restarts, you can access the GraphQL playground at http://localhost:1337/graphql

Let's check the Product query which was created for the content type with the following query:

```graphql
query Products {
  products {
    data {
      id
      attributes {
        name
        createdAt
        updatedAt
      }
    }
  }
}
```
 
For the first try it fails because there is no permission set up for unauthenticated users.
#
After adding the `find` and `findOne` permissions of `Product` content type to the `Public` role in the admin `Settings` / `Users & Permissions Plugin` / `Roles` / `Public` location in the admin web interface, the above query should return empty list.

If you would like to see some results, then add a new product manually or (after providing the `create` permission for the `Public` role) with this GraphQL mutation:

```graphql
mutation CreateProduct {
  createProduct(data: {
    name: "The product"
  }) {
    data {
      id
    }
  }
}
```

###  Prepare to add custom GraphQL query

We can add customizations to the GraphQL plugin in Strapi's `register` lifecycle hook, which is in `./src/index.js`.
In a reasonably large project this file can contain lots of code, so to make it obvious where GraphQL related code is defined, we will create another file at `./src/graphql.js`. This will be responsible to collect the custom GraphQL queries and mutations and add them to Strapi.

After our changes the files look like this.

```bash
./src/index.js
```

```javascript
'use strict';

const graphql = require('./graphql')

module.exports = {

  register({ strapi }) {
    graphql(strapi) // externalize all graphql related code to ./src/graphql.js
  },
  
  bootstrap(/*{ strapi }*/) {},
}
```

```bash
./src/graphql.js
```

```javascript
'use strict';

const noop = (strapi) => ({nexus}) => ({})

const extensions = [noop]

module.exports = (strapi) => {
  const extensionService = strapi.plugin('graphql').service('extension')

  for (const extension of extensions) {
    extensionService.use(extension(strapi))
  }
}
```
##### 
Later we will replace the noop extension with the `popularity` extension, which will also be similar to `noop`, ie: it will be a function taking `strapi` as parameter, returns another function with a parameter which has a `nexus` field and returns the extension definition.

This complicated function is helping in the long run, as `strapi` is provided by our code, but `nexus` is provided by the GraphQL plugin's `extension` service. Both can be useful in our extension code to reach other Strapi services, plugins and use [nexus api](https://nexusjs.org/docs/api/introduction).

###  Use Nexus API

It is time to define our `popularity` extension. I will copy the `noop` extension into the `.src/api/popularity/graphql.js` file and include this non-working definition to the extensions.


```bash
./src/api/popularity/graphql.js
```

```javascript
'use strict';

module.exports = (strapi) => ({nexus}) => ({})
```

```bash
./src/graphql.js
```

```javascript
'use strict';

const popularity = require('./api/popularity/graphql')
const extensions = [popularity]

module.exports = (strapi) => {
  const extensionService = strapi.plugin('graphql').service('extension')

  for (const extension of extensions) {
    extensionService.use(extension(strapi))
  }
}
```
##### 
As you can see I have chosen to import the new module and add it to the extensions list. The drawback is that whenever we add another GraphQL query, we have to manually add it to the extension list, otherwise it won't be recognized.
##### 
Let's continue with the actual extension, fill in the `popularity` GraphQL definition. Our first approach is to use [nexus api](https://nexusjs.org/docs/api/introduction).
##### 

```bash
.src/api/popularity/graphql.js
```

```javascript
'use strict';

module.exports = (strapi) => ({nexus}) => ({
  types: [
    nexus.extendType({
      type: 'Query', // extending Query
      definition(t) {
        t.field('popularity', { // with this field
          type: 'PopularityResponse', // which has this custom type (defined below)
          args: {
            product: nexus.nonNull('ID') // and accepts a product id as argument
          },
          resolve: async (parent, args, context) => ({ // and resolves to the 3rd party popularity service logic
            stars: Math.floor(Math.random() * 5) + 1, // a simple mocked response
            product: args.product
          })
        })
      }
    }),
    nexus.objectType({
      name: 'PopularityResponse', // this is our custom object type
      definition(t) {
        t.nonNull.int('stars') // with a result of the 3rd party popularity service response

        t.field('product', { // and if requested, a field to query the product content type
          type: 'ProductEntityResponse',
          resolve: async (parent, args) => ({ // where we provide the resolver as Strapi does not know about relations of our new PopularityResponse type
            value: await strapi.entityService.findOne('api::product.product', parent.product, args)
          }) // but relations, components and dynamic zones of the Product will be handled by built-in resolvers
        })
      }
    }),
  ],
  resolversConfig: {
    'Query.popularity': {
      auth: {
        scope: ['api::product.product.findOne'] // we give permission to use the new query for those who has findOne permission of Product content type
      }
    }
  }
})
```
##### 
I have included a mocked response for the 3rd party call, and let the reader elaborate on how to continue the implementation regarding the integration with any 3rd parties or custom logic.
##### 
Now you can check the results in the GraphQL Playground using the below query.
##### 
```graphql
query GetPopularity {
  popularity(product: "1") {
    stars
    product {
      data {
        id
        attributes {
          name
        }
      }
    }
  }
}
```

This gives the result:

```json
{
  "data": {
    "popularity": {
      "stars": 3,
      "product": {
        "data": {
          "id": "1",
          "attributes": {
            "name": "The product"
          }
        }
      }
    }
  }
}
```

So our implementation works as we expect.

For us the **hardest problem** was to **link the custom response type** (`PopularityResponse`) and the **Product content type's resolvers**. The final trick was to provide a resolver for the immediate relations (`product` field in the example), and return the result in a format what Strapi's graphql plugin accepts (an object with `value` field). This information came from the [graphql plugin source code](https://github.com/strapi/strapi/blob/v4.1.1/packages/plugins/graphql/server/services/format/return-types.js), which implies that using this trick is considered a dependency on graphql plugin internals and can break during upgrades.

###  Use GraphQL Schema

Since Strapi v4.0.8, the `ProductResponseEntity` can be referenced from GraphQL SDL type definitions in Strapi. If you are interested, here is the same definition, but using GraphQL schema and avoiding nexus API.
 
```bash
.src/api/popularity/graphql.js
```

```javascript
'use strict';

module.exports = (strapi) => ({nexus}) => ({
  typeDefs: `
    type PopularityResponse {
      stars: Int!
      product: ProductEntityResponse
    }

    extend type Query {
      popularity(product: ID!): PopularityResponse
    }
  `,
  resolvers: {
    Query: {
      popularity: {
        resolve: async (parent, args, context) => ({
          stars: Math.floor(Math.random() * 5) + 1,
          product: args.product
        })
      }
    },
    PopularityResponse: {
      product: {
        resolve: async (parent, args) => ({
          value: await strapi.entityService.findOne('api::product.product', parent.product, args)
        })
      }
    }
  },
  resolversConfig: {
    'Query.popularity': {
      auth: {
        scope: ['api::product.product.findOne']
      }
    }
  }
})
```

#
Personally, I prefer the GraphQL SDL variant as it is more compact, and it is familiar to most developers. In case we make a mistake in the SDL definition, it is failing at starting up Strapi, which is usually the same when we use Nexus API.
#
For both cases the `resolversConfig` can add configuration for authorization, middlewares and policies. While it is possible to override existing queries and mutation's `resolversConfig`, you should keep in mind that the active `resolversConfig` would be result of merging Strapi's default resolvers configuration and your settings. This makes the resolvers' configuration overrides dependent on the original settings and the merging process (which both can change with Strapi upgrades). 

##  Conclusions

#
As we can see, it is not that hard to add customized queries to Strapi. However, there are major differences between Strapi v3 and v4 regarding GraphQL.

I hope the above example saves you the time we have spent to find out the ways to implement GraphQL queries in Strapi v4.


Strapi.jpg

Have you ever had difficulties with setting up a new query, defining new types, or re-using already existing types from other content-types in Strapi V4?  If your answer is yes, check out this blog post!

Have you ever had difficulties with setting up a new query, defining new types, or re-using already existing types from other content-types in Strapi V4? Did you feel confused about the available customizations when using GraphQL? Let us help you and show how we solved this in one of our projects!

How to add custom GraphQL query to Strapi V4

"As a developer, I'm always looking for challenges during the work time and after it too, and the challenges always find me as well. Last year I participated in a contest organized by the IThon.info. Every year they organize this seven-week long event where in the first 4 weeks participants have one full week to finish the tests made by the partners of the organizers. In the last 3 weeks, the tests are being launched on a fixed date with a fixed amount of time to use to complete. First I attended this competition in 2019 and registered for different categories like Java EE, Spring and language-independent programming and in 2020 I did the same.The tests were based on very broad topics from basic to the advanced Java stuff and of course, as their names state Java EE and Spring. To my surprise, I finished at 7th place in the Spring category which was organized by the Epam Systems. They mostly focused on advanced Java and Spring related questions, which in the last 3 weeks required a lot of technical skills to finish in time. But the biggest surprise was that I won the JAVA EE category, this category was organized by the IBM and they were mostly focusing on the core Java EE stuff like:_

Servlets
JSONB and JSONP and JAXB
Bean Validation
CDI
JPA and some JDBC questions
EJB
JAX-RS

_All of the Java EE specification related topics were there and I would say each test held some tricky questions which required some practice and real-life experience from the past. The time for the tests were typically small and you could only rely on your skills - this is what it made so much fun. I'm thankful for the opportunity and I hope I will see more familiar names and faces in this year."_

We are really proud of the dedication and performance of Nandi. He is a great example of the fact that it is never enough of challenges.

winner-takes-it-all.png

Guys at The IT Solutions are always looking for extra challenges besides daily challenges at work.

Guys at The IT Solutions are always looking for extra challenges besides daily challenges at work. One of our developers, Nandor Holozsnyak has won the 1st prize at a Java EE category competition. Please see his experiences about the competition.

The winner takes it all

Windows users can use the options given by the Office family, the PowerPoint, Linux users can use both LibreOffice or OpenOffice solutions like Impress.
We, of course, do have online alternatives like Prezi, Google Slides, there are tons out there, but as a developer, we may be attracted to something more minimal and something which can be versioned by ourself may be in a repository, and of course, we would not like to deal with power-hungry tools or we do not want to go to a website where we can edit our presentation.

In this article, we would like to introduce a tool that can come in handy in creating presentations that are meant to be easy to create, and because we are more into code, and code-related stuff, we may prefer to create creative stuff via code. Most of the developers are familiar with languages that are being used for documentation or tutorials, for example, AsciiDoc or Markdown, and what if we can make and design our presentations in Markdown with some minimal CSS and HTML knowledge?

For this problem Marp gives us a fairly simple solution. With this tool, we can convert Markdown files to:

HTML with an interactive presentation toolkit 
PDF
PPT

Sounds cool right? How can I start using it? It's easy.

**Marp** is a product based on multiple modules/extensions, let's take a look at those first:

**Marpit**
skinny framework based on the markdown-it parser
supports CommonMark specification of Markdown
Mostly written in JavaScript
**Marp-core**
Based on the Marpit module/package (don't be confused with the name core), it extendes the Marpit framework with additional features
Mostly written in TypeScript
Built-in official themes (CSS)
Emoji support
Math support
Auto-scaling features
**Marp CLI**
Command line interface for which depends on the Marp-core
Installation guide (multiple ways):
With NPM package manager (npm install -g @marp-team/marp-cli)
Standalone binary (can be downloaded from the GitHub repository)
With Windows package manager tools (Chocolatey or Scoop)
Gives the user the power to convert .md files to .html, .ppt, .pdf
Supports watch and server mode

If you are willing to create the next Markdown presenter tool then the Marpit framework is a good start, you can import it to your project and use the power of the framework, but right now we want to talk about the end product itself, **Marp**, which uses all the mentioned tools/modules above, and based on these tools you are able to create the most beautiful and minimalistic presentations.

To write your very first presentation using this tool, first install the Marp CLI and you are good to go. Let's make some slides, with some cool background, make sure every page has page numbers and try out some directives.

To start the CLI in watch mode just run the following: marp prezi.md -w (if we would like to enable HTML tags then use the -html flag too)

Check out the [Marp](https://marpit.marp.app/) website to know more.

Marp has a lot of potential being a cool and handy tool in our hand, if we are much more into the Markdown world, we can bring fantastic presentations to the audience with ease.



---

# TIS Presentation

We can use the typical Markdown syntax and every time we would like to create a new slide we just have to insert the 3 dashed **'`---`'** at the end of our slide.

In the header comment section we are able to configure global and local directives which can control:

- pagination

- background color

- text color

- enable HTML tags in our presentation

- header and footer content

---









Slide 1
# Second slide

We can customize slides individually from the global scope, we can use local scope directives, to use the local scope just start the property name with a '_', for example:

  - pagination can be turned off on slides (_paginate: false)

  - header and footer content can be changed (_header and _footer)

  - background related color or image

  - font color

  - custom directives written in Javascript

---

# CSS support

Marp has a wide variety of CSS support which can be found [here](https://marpit.marp.app/theme-css)

---

# And many more

The markdown code above can be checked out here as the 'final' presentation and the all the final assets (PDF, PPT) can be found here. The pictures are taken from the presentation too.
Have fun making awesome minimalistic slides with Marp! \o/

creating-presentation-developer-approach.png

If Infrastructure as Code exists, then does Presentation as Code exist too?

If Infrastructure as Code exists, then does Presentation as Code exist too? As a developer sometimes we are wondering how should we make a presentation for the next big event like knowledge share sessions, conferences, demos and we find a lot of stuff out there.

Creating presentation – the developer approach

Partly due to the growing number of (online) training courses, learning how to program has never been easier, but this makes the question of where to start increasingly difficult.

Based on recent GitHub statistics, nearly 300 different programming languages ​​are available to developers today. Of course, many of these can be excluded due to their lower number of users, but there are still plenty left such as C, C ++, Python, Java, Javascript, Node JS, PHP, etc. If we consider this, we can see that we have quite a large lake for fishing. With this in mind, we may wonder why so many have appeared.

A programming language is a set of commands, instructions, and other syntax rules used to create a program. Due to the rapid technological developments, not only the hardware on which our software runs has improved extremely, but the languages ​​have also been significantly improved and in some cases even completely replaced.

The first viable explanation for the creation of new languages is the evolving needs of the industry. Despite the desire to have a universal language for all projects, for the moment this is not possible and therefore we must compromise between productivity, generality and performance. Due to this, as new technologies appear in the industry, new languages are created which are better taylored to this tech. Possibly the best and most recent example of the above idea is the public emergence of machine learning and data science. This newly adopted technology has called for languages such as R to be developed specifically for this type of products.

Not only do new technologies bring new languages but new companies have the same effect. As the various tech giants continue to vie for more costumer attention, they push their own languages into the market to draw consumers away from other companies. To see this, we need not look further that the largest mobile OS oriented languages Swift and Kotlin. Apple, as the best example, in its quest to restrict their buyers to their products, created their own objective-C based language which can only be used on their products and has disallowed most others from being used on iOS.

New programming techniques harbour the same effect, think of the for-loop, it used to be a while loop with a counter but then someone realised it would be better to just create a new type of loop. The same goes with every paradigm, object-oriented programming is another example, we often see that some languages are referred to as “object-oriented” while some are not. Whenever we think of a new method for solving a problem, it creates an opening for a language adapted to this method.

As well as this, as hardware evolves, new languages are developed as old ones will need to be completely rewritten to meet industry standards. Demonstrating this effect is the switch to C from B which took place in the 1970s, and although we cannot see much of this happening today, it is something that will arrive eventually, especially with the projected developments in quantum computing. Not just this, but we are actually currently very bad at “software engineering” and much of what passes in this field would not pass in other fields of engineering, this means that as we improve, we get a better idea of the tools we need and can build from there.

Another important reason for choosing a specific programming language is the speed with which you can enter the market with your new product or service to be developed. With the introduction of agile product development where "Proof Of Concepts" and "MVP's" are often built in the beginning, speed seems to be more important than quality in order to test the idea with customers and to convince investors to step in. This often results later in a rebuild with a more mature language in the scale up phase.

Furthermore, when we realise that there is a major problem with an already widely used language, it is nearly impossible to repair entirely and cleanly as we would have to change the language fundamentally and would therefore ruin multiple codebases. The only major language which seemingly does this is Swift, for which, with every update, Apple seems to make major changes. This, however has drawn mass critcism as many frustrated developpers are consitently having to rewrite large portions of their code which previously worked flawlessly.

As well as this, as the industry opens up to a wider public, the demand for more readable languages for beginners grows until it opens the door for new languages as is the case for Go and Kotlin, which gained their popularity through their simple nature and easy development. As opposed to this, Scala is widely criticised for its complex features, driving many developers away.

Resulting from the above, we live in a world with countless languages to choose from. Many of them are great, just as many of them not so much. However what is certain is that the industry is always changing and therefore, in 10 years most of them will not look the same, and some of them will have had their places taken, by more modern, productive languages.

With an understanding of where all these languages are coming from, we can proceed in deciding which one to use. The first, and most important step in this is deciding what our final goal is. If it is to be able to develop a good-looking, professional website, you should definitely go for HTML, CSS, and JavaScript. However, if your objective is game development, you should be looking at C# and Java. Many large corporations are now using Java for their back-end. The biggest players in machine learning are Python and R. Mobile development depends on the OS but it is great to take a look at Swift, Kotlin and Java as well as potentially frameworks like ReactNative based on JavaScript and Flutter.

For the next step, it is always good to have a bit of introspect. If you are a complete beginner, you should go entirely for the productivity and generality line, choices such as Python dominate this area and this is a great place to start understanding concepts for its ease of use and readability. However, if you are experienced and looking to create a large project with much more control over development, Java related languages are great choices.

so-many-programming-languages-which-one-choose.png

This is a frequently asked question and it is not always easy to explain.

This is a frequently asked question and it is not always easy to explain. In this blog we give it a try.

So many programming languages, which one to choose

I wanted to escape from multis because I was tied up with the lots of unproductive processes, the slow decision making, the culture where everyone wants to show their value in a cramped way that makes the whole culture unproductive, and weird. I enjoyed the parts of my career when I got real empowerment and true responsibility to build something new, a new development site, a new product or a new process. I love solving problem from end-to-end that requires to understand the needs, then planning, get the buy in, and finally execute. So why should I join to a multi again and being responsible for a specific part only?

So, I met with Meindert and Quincy with these things in my mind. They were very sympathetic because they were open, honest and direct. Their vision and value matched very well with mine. I trusted them. I left the discussions with positive mind, I felt motivated and excited again after a long time. My brain started to think about how I would approach their goals, what I would do first to make it successful and I couldn’t stop thinking about these. Joining to a new company is having some risk of course but it’s not comparable to the huge opportunities it brings. We agreed quickly then I left work some vacation with full of motivation, excitement and happiness. 

**How did we start **

The start was really energetic, even more energetic then I expected. And when I say “the start” then I mean the next day right after I accepted the offer. I counted 58 email conversations with Meindert mainly from my holiday in Malta. J  The interview process of the first team had already been in progress however everything else like environment, equipment and infrastructure was behind. The first team will start in 1.5 month – Meindert said. Wow, what a challenge! – I said. For instance, if you now the lead time of getting lease line internet in downtown Debrecen then you would say it’s impossible. Another example is the average delivery time of high-end laptops, find a team who can start immediately and rebuild few things in the new office, buying furniture, etc. – everything should be ready by 1st September when the first team of 5 will start. 

And we did it finally, on time, with a fantastic result! I enjoyed all single minutes of this period. We get to know each other better and better and we resonated in the same frequency.  

looking-back-last-two-years.jpg

How we met each other, what I thought then, why I joined to the company, what was my expectation?

How we met each other, what I thought then, why I joined to the company, what was my expectation? I have already decided to change my career at the time when I got a call from an unknown recruiter (we became good partners later) in June 2018. I was interviewing in Budapest to the big names but I was not super happy.

Looking back for the last two years

**Why customers move to the cloud?**

**These applications that provide services like emailing, writing contracts and POs, invoicing or financial management are all hosted in the cloud today and you pay-as-you-use. You don’t need a server, switch, router and other IT infrastructure that would bother your time, attention and cash flow. You don’t even need to hire an IT technician to be able to use these applications. Very cool, isn’t it?  **

Later, you will need a tailor-made software as you are settled down and found out your own way of working that best suited to your needs. You find us, a solution developer company. We work together to understand your needs, how and what this software can help you to realize more value. Further on the road, we start the development and want to show you the results week by week, give it to you to play with and confirm it is really the thing that you need.

However, the complications come in this step: **where should we install this application for you to use?** Should we ask you to go to the shop and buy a server and all related things that needs to run it? Should we ask you to hire an IT guy to build it and maintain it regularly? Should you start learning new IT things like what is server backup and why it is important; why should I pay for this; what is security, disaster recovery, performance issues, load balancing and thousands of other things? No, you definitely want to focus on your own business.  

The answer is the cloud computing. We can use a credit card to buy the right-size resources within seconds, deploy the software to there and let you use it. The price includes all necessary things to run the software. You don’t even need to know what kind of magic the provider (AWS for instance) does in every minute to let you use the service.  

Are you growing and having more users that may slow down the software? Just go and ask to increase the capacity as needed. Done. You don’t need something anymore? Just go and ask to remove it and done. 

**What business challenges do customers face? What do customer’s technology and IT infrastructure look like? Where do customers host their technology? **

The analysis depends on what size of company and in what maturity state we are meeting with the customers. For instance, we can find these typical signs at our customer

Startups

starting from zero to something from day one to next day
too much things to focus on in the same time
focus on cash flow, short term goals
having individual, separated infrastructure
wide range of technology, mostly free or open source

Scaleups

increase speed and agility
performance, scaling is important
integration, automation, efficiency is key
mid to long term goals

Established companies

offer services to international markets
long term goals
reduce infrastructure cost
planning to move from private or hybrid cloud to public cloud
consolidating technology
focus on high availability, efficient monitoring, automation

Let’s dig deeper and see why customers are moving to cloud in the next blog post, what is the cloud adoption journey and what is the role of the Amazon Partner Network in this journey. 

digital-transformation-aws-1.jpg

A business case – consider you start a new, small business. When you start a new business then there are too many things in the same time at the beginning to be distracted easily and you need to manage your cash flow carefully as well. Most of the applications you will use as a service at the beginning because it’s easy to start with and enough at the beginning.

Blog Posts

Check out the latest articles written by our team!