GraphQL, Hyperledger Fabric & Go – what you need to know?

Table of Contents

Before I go on to analyze GraphQL or Go language, I want to give an opinion that there is no programming language that is the best option for all applications. I claim that each language is adapted to use in specific cases.

Go language

Go language is a relatively young language. Less popular, at first, increases the time we have to spend on finding the best solution. This is due, among other things, to the fact that young external libraries are sometimes still underdeveloped, and using them sometimes creates unexpected problems. However, it should be remembered that the problem of the small number of packages available will decrease as the number of people writing in Go gets bigger. This language requires explicit error checking. Functions often return two values instead of throwing away an exception. One of them is the result of the operation, the other is an error variable.

In order to detect malfunctions in the application we have to check the value of this variable. Such an approach may hinder our work, but on the other hand it provides better consistency. It is worth noting the lack of generics, which can make it difficult to create clear code. However, based on the available information it is a temporary problem because the language development team is considering adding support for generic types in future versions of Go. This language allows you to take advantage of the hardware capabilities of today’s computers to a large extent thanks to concurrency.

The concurrency is a great advantage, but using it incorrectly can lead to unexpected results and make the application much more complicated – remember this. Note the rich instrumentation provided by Go. It is worth mentioning here the built-in test platform in the language, which additionally allows to generate reports about code coverage, or many built-in features, thanks to which you can be tempted to write an application without using the framework. In the Go language syntax we will not find classes. The entities that we will declare are instances of structures with methods assigned to their types. In other words, we declare the type of a structure, and then assign different methods to its type. We won’t find constructors and destructors in Go, but we can artificially implement them using functions or methods using defer instruction.

Objectivity in this language is realized by means of interfaces. We can create struct literals that resemble the object literals available in JavaScript. This language allows you to create packages on the main level of the written application, but it is not possible to add sub-packages. This can sometimes make it difficult to modularize applications. The performance of Go language seems to be much higher than e.g. Node.js, but you should consider the size of the project, its structure and possible development directions.

Opinion on GraphQL language

In the article I mentioned at the beginning I presented commonly described strengths of GraphQL query language. I definitely agree with the opinions presented in the article, but it’s worth considering whether to abandon REST-based API implementations and switch to GraphQL. Why these doubts? We should always think about whether the new solution would bring measurable benefits, ignoring the well-being of the programmer who used the new technology. I think that GraphQl query language is a very good solution if the optimal use of data transfer is important (mobile applications are a great example).

GraphQL will also work if the Api is huge and has a wide range of possibilities for a very large number of clients. However, the implementation of this query language raises a few problems that need to be noted. In case of small APIs, in my opinion, there will be a significant increase in complexity. This is because there are such things as types, mutations, resolvers or high-order components. This is not good from the maintenance perspective. Regardless of the size of the application, there may be complications associated with file transfer. This functionality is not currently part of the GraphQL specification, so it is up to the programmer to implement it.

The best solution seems to be to use a library that will implement the GraphQL multi-part request specification (an example is apollo-upload-server). This involves adding another dependency to the project. Such a library may be unavailable in the programming language used. An additional problem may occur when implementing cache on the HTTP layer level. API based on the REST standard has many endpoints, so you can easily configure the cache to match specific URL patterns or HTTP methods used. In GraphQL, there is one endpoint that supports all requests. Each query can be different, making it difficult to use this kind of caching in a similar way.

A way to reduce traffic to the server can be persistent queries, which can be used by the persistgraphql library, for example. However, this is only a partial solution to the problem, which will constitute another layer of complexity. GraphQL allows you to define a schema that provides benefits such as automatic validation and introspection (the ability to get information about supported queries). The disadvantage may be considered to be the staticity of diagrams, the definition of which determines the form of response that the client gets. Some of the associated constraints can be solved by using libraries such as Graph Ruby, which allow for dynamic software schema definition.

What about Hyperledger Fabric?

It remains for me to present my thoughts on the technology mentioned in the introduction called Hyperledger Fabric. In situations where public blockchain networks are insufficient, where users are anonymous and the change history register is available to everyone, a solution like Hyperledger Fabric seems to be a good choice. In my opinion, it allows to create very extensive, often complicated networks of connections between institutions and various types of organizations at much lower costs.

The mentioned decrease in costs would concern the lack of need to use the mediation of a trusted third party in case of establishing relations between the participants aiming at exchanging goods between themselves. Organisations and institutions may gain savings by optimising their business processes by reducing them to the form of a so-called smart contract, the integrity of which is guaranteed by the blockchain network. It is important to guarantee that the process cannot be cancelled or modified by a user who does not have the appropriate rights. Thanks to this, all changes are made with the consent of the parties participating in the process.

The goal I set myself when writing this series of articles is to encourage you, the readers, to learn and verify new solutions by using them in the applications I write. The choice of languages and technologies should be preceded by an in-depth analysis of often subjective opinions. I hope that I have managed to present the pros and cons of Go programming language, GraphQL query language and Hyperledger Fabric solution in a clear way. Perhaps my conclusions are subjective. Maybe you will check if I am right?

GraphQL, Hyperledger Fabric & Go – what you need to know?

Go language

Opinion on GraphQL language

What about Hyperledger Fabric?

Contact Us

Our Offices

Services

Industries

Links