DEV Community: Bogdan Nedelcu

GraphQL at global scale: Facebook

Bogdan Nedelcu — Thu, 28 May 2020 09:53:58 +0000

From the news:

A few weeks ago Facebook rolled out its new desktop design.

One of the many improvements they are experimenting with is lazy loading where they prefetch both the code and the data needed by a view.

What draw my attention is the introduction of entry points:

"files that wrap a code-split point and transform inputs into queries.
These files are very small and are downloaded in advance for any
reachable code-split point."

The so-called entry points unify the fetching of code and data a view needs in one single GraphQL query:

"This has the added benefit of creating a single JavaScript function
that contains all the data-fetching needs for any given point in the
app, which can be used for the server preloading discussed earlier."

The new approach leverages GraphQL's ability to unity request and minimizes network usage in a way I have never seen before.

This literally blew my mind. 🚀

I cannot wait for further releases of their performance improvements and will try to use this in my future projects.

What do you think?

Have you ever seen code and data fetching done simultaneously?

More on Facebook's engineering blog here.

The price of software: Unit testing

Bogdan Nedelcu — Thu, 07 May 2020 07:16:25 +0000

Test automation is one of the best investments an engineering team can do when developing software. The industry accepts that testing units is the fastest and most simple form to automate tests. But does that mean we should unit test our whole codebase? How much of our code should we cover with unit testing? How can we be most efficient?

Measuring Tests Effectiveness

Finding program bugs when developing is cheaper than fixing them afterward. Handling user concerns, maintaining transaction consistency, isolating, and then releasing a patch for a defect is expensive.

The goal of testing is to reduce the cost of software.

The difference between the price of process and the cost of bugs is the real return of investment of writing tests.

Code Coverage

The traditional way to measure how much we are testing is the so-called code coverage. We obtain the value of coverage as the percentage of source code that runs when executing tests.

In addition to the number of lines of code, different criteria can be used in the coverage calculation: function coverage, statement coverage, and so on. However, they all rely on the ratio of total code versus code executed when running tests as measurement.

The assumption behind measuring code coverage is that a program which entirely tested will have fewer defects. In practice, aiming for 100% coverage is not very realistic.

Testing Fatigue

The cost of writing unit tests increases exponentially as we get closer to 100% coverage. The number of defects detected decreases at the same rate.

Writing tests to get the test coverage from 90% to 100% is expensive and highly ineffective in preventing bugs.

Aiming for complete test coverage couples the tests with the implementation to a level where development effort for a feature can even double. We get slowly out of sync with product development when we spend too much time testing implementation details.

The Cost of Unit Testing

Being unit testing the fastest way to test, we fall in the trap of overusing it. To increase code coverage, we test code that does not correspond to a specific unit but ties many units together. The effort of mocking and stubbing becomes higher than writing the business logic itself. We are at that point writing integration tests using the unit test approach and tools.

The return on investment of those unit tests is minimal because they rely heavily on mocking of their dependencies and will pass even if those dependencies have changed their interfaces. Making mocks and fakes aware of changes in the constructs they replace results into heavy maintenance work.

Abusing unit testing adds overhead to the development process without reducing defect density.

It is usually much more cost-effective to write an integration test than several unit tests if we already have a decent integration test setup.

Using the traditional code coverage as a synonym for program correctness or code heath will lead to a negative return on test efforts and increase development time rather than decreasing it.

The Effective Code Coverage

Tests are beneficial if they prevent the maximum amount of bugs unit of time invested. Code coverage is only useful if we include the context in the calculation. A better parameter to quantify out test efforts is something we can call the effective code coverage. That is the percentage of code that the development team decided should be unit tested and the ones that execute when running tests.

Depending on the project and the programming language, this metric will not be higher than 20% to 40% of the total source code. That is because we target code that:

identifies as a unit
is ideally reused

Because tests do not suffocate development, the return on investment of this method is much higher. The approach gives space to investing testing time that would normally go into unit assertions in integration or end to end tests.

This testing philosophy requires flexibility in thinking and relies heavily on context: the kind of software we are writing and its purpose, language, frameworks, and, architecture choices we make. Therefore, the parts of the source code that must be unit tested change with the same frequency as our product does.

Although counter-intuitive, decreasing the amount of unit testing can improve the overall code quality.

We should avoid writing unit tests that are too close to implementation details. Instead, focusing on reusable modules and their interfaces will maximize the number of defects identified per unit time.

Approach unit testing in the same way you approach any form of automation. Traditional process analysis, including cost and time, help make a much better decision than absolute measures of coverage. The remaining testing time can be invested in more sophisticated testing methods, closer to user expectation, and changing less frequently.

Summing up

Rather than absolute metrics use context in your decision making. Be intentional about your choices and always keep an open mind.

Testing setups with the highest return of investment are a mix of unit, integration, end-to-end, and manual tests. The perfect blend depends on your product, tech stack, and team.

Did you enjoyed the content? Follow me on dev.to and LinkedIn to get more of this in your feed. As originally published on bogdanned.com.

The Graph in GraphQL

Bogdan Nedelcu — Tue, 14 Apr 2020 06:53:49 +0000

GraphQL is today a ubiquitous choice for building APIs. The technology, open-sourced by Facebook, allows clients to fetch what only they need and aggregates requests under a unique query interface. With GraphQL, we can build faster applications, consume fewer data, and leverage fantastic developer tooling. I have been fascinated by GraphQL ever since its release. However, a question kept coming back to me: How does it leverage the power of graphs? In the following lines, we will start by taking a look at graphs, trees, and recursive properties. With that knowledge, let's dive deep into the original specifications and the javascript implementation of the server runtime. We will break apart the inner workings of GraphQL into its most simple and smaller parts and then put them back together. In the process, we will uncover how the data-structures are used to create the technology that changed the web as we know it.

What is a Graph?

A long time before GraphQL there where graphs, but what are they exactly? Graphs are data structures that resemble the natural way we build mental models and relate concepts. In graphs, relationships between represented entities are as relevant as the entities themselves.\
We build graphs with abstract objects called nodes or vertices. The connection between two nodes is called an edge. We can then explore a graph recursively following the edges in a specific order.

A-Cyclical Directed Graphs

There are different types of graphs, depending on how the nodes and the edges are arranged. We will focus for now on a-cyclical directed graphs because these are the ones we find in GraphQL. A directed edge has a start and an end and can only be traversed following that direction. Adding direction to the edges changes the meaning of the relationship between nodes and introduces a hierarchy. Let's say, for example, we want to represent money loans with a graph. Every edge would represent money borrowed, and the direction would represent the money flow from the lender to the party taking the loan.

From a Graph to a Tree

Graphs can transform into a different data structure depending on the constraints applied to them. A graph cycle or a circuit is a set of edges where the last edge is also the first edge. When a graph has no cycles is called an a-cyclical graph. A directional graph that is also a-cyclical is known as a tree.

The tree structure has several advantages because of its recursive nature. The elementary unit of a tree is a root node and one or many children nodes. If we model our data as a graph and impose the necessary constraints on it, we can leverage tree properties to process it. While one can transverse a tree as a whole is usually easier to work at a local level, node by node. Read and write operations can be extended to the full length of a tree by executing functions on the root node and then recursively on the subsequent children.

Modelling with Graph(QL)

As we all know in GraphQL, we represent our business domain by using a schema. The schema itself is a graph composed of types representing different entities. Types are extracted from a problem space using domain-driven techniques. They can have different fields, and every field points again to another type. In the picture above you can see that lastname, firstname and email point to the scalar type String. Scalar types do not have any subfields and they represent the leaves of the query tree. A path through the schema will always resolve in a collection of scalars structured like a tree. Most GraphQL implementations allow developers to add their own scalars with custom validation and serialization functions. The relationships between a type and its fields are unidirectional edges and are the building block of the schema. That makes the GraphQL Schema an acyclic directed graph. As we mentioned before this kind of graph can be read like a tree, visiting each tree once, in a process called tree traversal. A GraphQL query is a path in the graph, going from the root type to its subtypes until we reach scalar types with no subfields. As a result, a query is a projection of a certain subset of the GraphQL schema to a tree. On the backend side, every field of a type maps to a resolver function that returns its value when queried. The query result is created by merging the result of running resolver functions for every field extracted from the schema. GraphQL, however, does not stop here. Tree properties and recursive functions are used not only to model data but mainly to validate and execute queries on that schema.

Schema parsing

The GraphQl server parses the schema document at execution time. Types are extracted and stored as plain Javascript Objects with references to their fields, and to the resolver functions in a dictionary called typeMap. When a field must be resolved the execution algorithm will look for it in the dictionary and use both the resolver function and the references to its subtypes to build its value.



// Simplified structure of the type map
let typeMap = {
  rootType: {
    fields: { // array with the fields of the root ype
      user: {
        type: {
          fields: {
            lastname: {...},
            settings: {...},
          }
        },
        resolve: () => ({})  // points to a resolve function for the type
      },
      settings: {
        type: {
          fields: {
            membership: {...},
          }
        },
        resolve: () => ({})  // points to a resolve function for the type
      }
    }
  },
};

As every type contains a reference to its resolver function, one can resolve the whole schema by repeating three steps:

Retrieve a type from the typeMap dictionary
Run its resolver function
Repeat the same on the fields of this type

To sum up: the GraphQL schema document is parsed on the server. During the parsing process, the types extracted and stored together with references to its resolver functions in a dictionary called typeMap. Because of its tree-like structure, the dictionary can be read and wrote using recursive functions following different transversals.

Query Parsing

The GraphQL server parses every query from a string to an Abstract Syntax Tree(AST). An AST is a tree representation of the syntax of source code from a particular language. Every node in the tree represents a statement in the query, including its type, arguments, and position.

The AST is a common abstraction for compilers and is used to validate syntax correctness in a process called semantic analysis. Again, because of its tree-like structure, the AST can be processed and interpreted by recursive functions. This process is behind the query validation feature that GraphQL editors usually offer.

Query Execution

Once a query operation has been converted to an AST and its structure validated, we can use the tree properties to execute the query. The core of the execution algorithm is a recursive function that runs on every node of the query tree following a depth-first-search order.

The traversal ensures that fields are executed and resolved in a stable and consistent order. Following the first order traversal the field execution function will be called on each field in the following sequence:
The executeField function contains the magic behind the field value resolution and is well described in the GraphQL specifications. The function arguments are the name of the type is being run on, the definition of that type from the typeMap dictionary and the resolver function. First, the algorithm executes the resolver function and stores the return. Next, it completes the field value depending on its type. If the field type is a scalar, its value is simply "coerced" using a serialization function and directly returned. If the field type is an Object the completeValue process is started. The function collectFields assembles all the subfields on the respective object type that have not been resolved by the resolver function and returns a fieldGroup, an array ordered respecting the depth‐first‐search style. Then executeField runs recursively on each one of the subfields collected, in parallel. Finally, the algorithm merges and coerces the values returned by the first execution of the resolver function and the completeValue return and builds the final result according to the order in the query AST tree.

The resolution algorithm described above is a simplification of the GraphQL specifications. Proper error handling and response building make the actual implementation more tricky. Parsing queries into trees simplifies the resolution algorithm by leveraging recursiveness and ensures the consistency of field execution for queries on schemas of any shape and size.

Summing up

Graphs are the core reason why GraphQL is such a great choice to build and consume APIs. On the one hand, graphs allow developers to model the data in a natural way using directional relationships and hierarchies. The GraphQL Schema is a direct representation of a problem space based on natural language.

On the other hand, GraphQL leverages the recursive properties of AST trees to validate and execute queries. The depth first-order transversal of query trees enables stable and predictable parallel data fetching. The recursive nature of queries enabled fast development of tools like GraphiQL and the Apollo Client that leverage it for client-side query validation, caching and cache invalidation.

Final thoughts

To build exceptional software we need a fundamental understanding of the tools we use. It is usually simple pieces put together in harmony that make up sophisticated technology. The core abstraction in GraphQL is the graph. A linear algebra concept used to represent information in a non-linear and hierarchical way, or simply put: how we think about it every other day.

Even more fascinating is the fact that at the core of any technology we find the incredible ways humans solve problems naturally.

Originally published on bogdanned.com.

On Deno and the future of Node

Bogdan Nedelcu — Tue, 18 Feb 2020 08:13:00 +0000

What would Node look like if it was written today? In one word: Deno. The JS runtime has Typescript build in and simplifies module resolution. On top, it takes security to the next level and closes the gap between how we write javascript on the backend and the browser.

Not so long ago ...

Released in 2009 node took over the world incredibly fast. Despite the initial skepticism about running javascript in the backend, the community backup was unrivaled. Soon, sophisticated tooling appeared, and years later(2014), Microsoft released Typescript, double betting on Javascript.

Today, Node is one of the most popular choices for backend development. The event-based server philosophy ensures a high performance/throughput ratio. Running Javascript makes is an accessible tool for many developers. In a way, one can say, Node democratized backend development by lowering the barrier of entry. I have been happily using Node in the last five years, but at the same time, I wonder what does the future awaits?

The new kid around the block: Deno

Started in 2018, the Deno project, as the website states, provides a secure runtime for Javascript and Typescript. It is composed of basically two parts: a typescript frontend and a Rust backend. The communication between the two happens by messaging with TypedArrays.

Deno is a JavaScript/TypeScript runtime with secure defaults and a great developer experience. — The Deno Website

Under the hood, we find a snapshotted version of the Typescript compiler, the V8 engine, and the Tokio event loop. Altogether, shipped as one binary of less than ten MB or as a Rust crate.

Ageing API's

Removing promises from Node back in 2010, helped the community at is early stage. But as javascript started to move faster and faster and introducing the await and async functionalities, Node's APIs started to age.

A considerable effort is made today to bring them up to speed and keep consistent versioning at the same time. Many of the API calls must still be wrapped in constructors like promisify to be used with the Promise syntax. This extra step adds overhead to development and increases boilerplate in applications.

In contrast, Promises are Deno's native bindings for async behavior. The Rust backend mirrors the promise objects received from the Typescript frontend with Rust Futures. Async actions in Deno always return a Promise.

Another noticeable thing about Node is that it relies on Buffer objects to read and write data. In a step to bring uniformity with browser interfaces, Deno uses TypedArrays everywhere. Being consistent when reading and writing files across the backend and front end is much easier when using the same data structures.

Typescript with Zero Setup

If you use Typescript, you know it is a remarkable tool. It introduces a type system that can be enforced as applications grow. This reduces the overhead of conventional static typing by providing flexibility. A project can be partially typed in the begging, and type coverage can be extended as the application grows.

In Node, Typescript can be used directly with ts-node, although one must be careful in production. The safest and most performant choice is to use ts-node for development. Then compile to javascript for production. The setup for development can be complicated, especially together with other features like hot code reloading.

On the other hand, Deno is all about Typescript. It uses a snapshotted version of the compiler and catches unchanged files. Do you want to run Typescript code? Just run the Deno binary. No config. No hustle. Is that easy, and of course it supports javascript too.

Browser Like Package Resolution

The current resolution scheme of Node overcomplicates module resolution. The algorithm provides flexibility in file location and naming with a considerable tradeoff in complexity.

A require call would first search for a file with the same name and a .js, .json, or .node extension. If the path specified does not include a leading '/', './', or '../' node assumes the module is a core module or a dependency in the node_modules folder. If the name does not match, a core module node will check the node_modules at that location. If nothing is found, it will get to the parent directory and continue to do so until it reaches the root of the file system.

Additionally, folders can be specified as modules in the package.json file. The require function is also aware of the package.json file of all the folder begins checked. Once a folder is found, Node will look for anindex.js or index.node file inside it. The freedom of not having to provide a file extension and the flexibility of package.json comes at a considerable increase in complexity and decrease in performance.

Deno simplifies the algorithm by providing two types of module resolution, relative and URL based:

import * from "https://deno.land/std/testing/asserts.ts";

In addition, the resolution algorithm does not use package.json file or the node_modules folder. Instead of require, it uses ES Modules imports. This allows us to use a modern approach to code management without the need of a pre-compiler and brings us again closer to how Javascript is used in the browser.

Distributed Package Management

Server-less adoption is at this moment doubling every year. Developers use to split monoliths into microservices. Now we are splitting micro-services into functions. Why? Well, on the one hand, nobody wants to deal with orchestration unless we have too. On the other hand, distributed systems are more flexible and can be changed faster. The bottom line is, applications are becoming systems of smaller and separated parts.

A typical javascript backend application represents 0.3% of the code is using. The rest is made up of packages in the node_modules folder. And many are hardly used at runtime. At the same time, the whole ecosystem depends on a centralized package manager: npm.

Deno brings a distributed approach to package management. Packages can be resolved by URL and catched afterward. Applications are lighter and less dependent on a single and centralized package registry.

On Security

When doing backend development, I expect security to work outside the box. The last thing I want to think about is a linter file or node module accessing the network or the file system.

In Deno, internal functions cannot call V8 API's arbitrarily as they do in Node. The communication between Deno's APIs and the JS engine is centralized and unified with messaging based on typed arrays.

Unless specifically allowed, scripts can't access files, the environment, or the network. — deno.land

Scripts executed with Deno can access the file system and network only if the user explicitly specifies it. And even better, permission can be given at file, folder level, or network path level with the —allow flag. This offers developers granular control of read and write actions that happen at runtime.

$ deno --allow-net https://deno.land/std/examples/echo_server.ts

Security by default is a significant upgrade compared to the "trust" policy applied to dependencies one pulls from npn. With Deno you can run and develop applications with the confidence that they will do what they are expected to.

Summing up

Deno is how Node would look like if it would be built today. It improves security, simplifies module resolution, and runs Typescript.

As I am writing this article, we are still at version 0.33 and growing fast. I am sure if you are here is because you are to some degree using Node or Javascript. If you are like me, you probably love it. But as they say, to love something truly means to let it go.

I am looking forward to seeing Deno grow beyond merely a scripting runtime and to hearing about the first experiences in production. As long as developers continue disrupting ourselves, we can always expect faster, more straightforward, and more reliable software.

Originally published on bogdanned.com.