Luca Ongaro's blog

MiniSearch, a client-side full-text search engine

2019-01-30T16:08:00+01:00

This blog post is to introduce MiniSearch, a JavaScript library that provides client-side full-text search capabilities. It has zero runtime dependencies, and uses a space optimized index to support memory constrained environments like mobile browsers. It offers prefix search, fuzzy match, boosting, auto suggestions, and many of the features expected from a server-side search engine like Solr or ElasticSearch.

MiniSearch is designed to be flexible and easy to use, and I think that a quick example can introduce it better than a long explanation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// A collection of documents we want to search among
const documents = [
  { id: 1, title: 'Moby Dick', text: 'Call me Ishmael. Some years ago...' },
  { id: 2, title: 'Zen and the Art of Motorcycle Maintenance', text: 'I can see by my watch...' },
  { id: 3, title: 'Neuromancer', text: 'The sky above the port was...' },
  { id: 4, title: 'Zen and the Art of Archery', text: 'At first sight it must seem...' },
  // ...and more
]

// Create the search engine, and set `title` and `text` as searchable fields
let miniSearch = new MiniSearch({ fields: ['title', 'text'] })

// Index all documents (this is fast!)
miniSearch.addAll(documents)

// Search with default options. It will return the id of the matching documents,
// along with a relevance score and match information
miniSearch.search('zen art motorcycle')
// => [ { id: 2, score: 2.77258, match: { ... } }, { id: 4, score: 1.38629, match: { ... } } ]

// Search only within specific fields
miniSearch.search('zen', { fields: ['title'] })

// Boost some fields to give them more importance (here "title")
miniSearch.search('zen', { boost: { title: 2 } })

// Prefix search (so that 'moto' will match 'motorcycle')
miniSearch.search('moto', { prefix: true })

// Fuzzy search, in this example, with a max edit distance of 0.2 * term length.
// The mispelled 'ismael' will match 'ishmael'.
miniSearch.search('ismael', { fuzzy: 0.2 })

// Get suggestions for a partial search
miniSearch.autoSuggest('zen ar')
// => [ { suggestion: 'zen archery art', terms: [ 'zen', 'archery', 'art' ], score: 1.73332 },
//      { suggestion: 'zen art', terms: [ 'zen', 'art' ], score: 1.21313 } ]

Here is a small demo application to play with, and experiment with different options:

As can be tested in the demo, the ~5000 songs are indexed client-side upon each page load in a fraction of a second, and the search happens in real time as the user types, with no detectable latency.

What’s the point of a client-side search engine?

Recently, for a web application I was working on, I needed to allow users to search for products in the inventory of several resellers. Each of these resellers typically offers several thousands different products. The app needed to offer advanced full-text features like fuzzy match (finding results also when a term does not match exactly, for example due to a mispell), prefix search (searching for the initial part of a term should already yield results before the whole word is typed in), and proper ranking of results (more relevant results should appear first).

Normally, for such use cases, a search engine like Solr or ElasticSearch would be the obvious choice. The challenge though, was to make search as fast as possible, but also resilient to spotty Internet connections on users’ smartphones. I started to think whether it would make sense to implement the search index client-side instead of server-side: it might sound a bit unorthodox, but a client-side search engine has several advantages.

First, once the index is loaded, a temporary interruption of the Internet connectivity would not affect the search experience: if the search index lives on the client side, no network request is necessary. Moreover, there would be no need to setup and run a search server, making the architecture simpler. Running the search engine client-side is also inherently scalable: no additional load is placed on the server when more users access the platform, as each of them is running their own instance of the search engine in their browser. Finally, with a good implementation, search can be made much faster, as network latency is eliminated entirely, and results can be computed in real time as the user types.

Of course, there are limits to how big a collection of documents can be in order to fit in the browser memory, but these limits are surprisingly high, especially when using the right data structures. Some use cases that are served well by client-side search are, for example, product search for a medium-sized online shop, search through a blog, or address book search. Proper full-text search can give a much better user experience compared to a crude string comparison or regular expression search, due to better ranking of results and handling of mispelled terms.

Implementing the index

As a rough calculation, if we have 5000 documents to search among, and each document is on average 200 characters long (either documents are small, or we are only iterested in searching by title, or within a small description), then storing all the documents in uncompressed form takes roughly 2MB (JavaScript strings are typically stored using 2 bytes per character). That is more or less the size of a good quality image, and usually more than acceptable to store in memory.

There is one problem with this calculation though: it is only taking into account the size of the raw documents, not of the search index data. Typical implementations of inverse indexes for full-text search, trade off space utilization for lookup efficiency, and therefore take a lot more space than the original documents. This is not a problem for search engines running server-side, where data can be stored on disk, and also RAM is plenty, but it is not acceptable if the index data has to live in the browser memory. Can we devise a data structure that is at the same time compact and efficient?

Luckily, there are some good candidates. One data structure that fits our requirements particularily well, and therefore the one I ended up choosing, is the radix tree: it is a variant of a prefix tree that further optimizes space by merging nodes that are the only children with their parent. A radix tree is a great candidate for our space constrained inverted index because:

It supports efficient lookup of a term, in time proportional to the length of the term being searched. The same holds for insertion and deletion.
Being it a prefix tree, searching for all terms having a certain prefix is also efficient, and takes time proportional to the length of the prefix.
The data structure is compact, because common prefixes are stored only once. Because of that, in some cases the index could even be smaller than the original collection of documents. In general, the index size will be of the same order of dimension as the size of the collection of documents.
“Fuzzy” search, which is searching for terms within a maximum edit distance from a given term, can also be implemented. It cannot be as efficient as in other techniques like n-gram indexes, but for small edit distances it can be made efficient enough. Also, as the search happens client-side, it makes sense to use a bit more CPU, while keeping the index smaller. Other data structures allowing for efficient fuzzy search would take a lot more space.

Implementing a radix tree in JavaScript takes a little patience, but with a good amount of testing it is not difficult (and can be quite enjoyable if you are a data structure enthusiast like me). Along with the necessary unit tests, I find especially valuable in algorithmic code to add some generative property based tests, to discover unforeseen corner cases.

Building on the foundations of a well-tested radix tree implementation, the search engine is mostly a matter of building up the index in a way that supports all the planned features (boosting, search in a specific field, etc.), and following well researched ranking algorithms like Tf-Idf. The most complex part was implementing fuzzy search, which is done by traversing the radix tree while maintaining a “budget” of edits: if we are looking for the word “color” within an edit distance of 2, we will find “colour” (edit distance 1), and “connor” (edit distance 2), but not “colorful” (edit distance 3, exceeding budget).

A suite of performance benchmarks also provides a convenient way to measure performance improvements and avoid regressions. Measuring performance in a rigorous way is especially important for algorithmic code, where it is otherwise far too common to make the mistake of implementing “optimizations” that obfuscate the code while not giving any tangible benefit.

Comparison with other libraries

MiniSearch is not the only library of its kind. There are a few other libraries with similar goals, among which Lunr.js and Fuse.js. These libraries are well implemented, and although they all provide client-side full-text search, they have different use cases and feature sets.

Fuse.js is optimized for smaller collections of documents: it uses the Bitap algorithm, that provides good fuzzy matching, but iterates through the whole collection of documents upon each search. For this reason it is not ideal for my use case, where Fuse.js incurs in a noticeable delay. Despite this shortcoming, for small collections Fuse.js works quite well and is easy to use.

Lunr.js is probably the most similar library. Its implementation is quite similar to MiniSearch, and it performs similarily. The project is well maintained, and I can definitely recommend it, having used it in several projects before switching to MiniSearch. The main differences with MiniSearch are the following:

MiniSearch index takes sensibly less space than Lunr’s one. On my applications, MiniSearch typically uses less than half of the space used by Lunr, for the same collection. This was one of the main design goals of MiniSearch, in order to support memory-constrained cases like mobile apps. That said, Lunr is already quite space optimized, so for many use cases this difference won’t be too important.
Lunr comes with stemming and language support. MiniSearch provides the facilities to add those, but does not provide them out of the box. Stemming and language support are useful features, but they are often not needed, make the library bigger, and can sometimes lead to unexpected results. For these reasons, I chose to leave them out of scope for MiniSearch, and explain instead in the docs how to add them, if needed. That said, if you know you need them, Lunr might be an easier choice.
Lunr index cannot be changed after creation. MiniSearch instead makes it possible to add and remove documents to the index at any moment. If documents in your collection can be edited by the user, then MiniSearch makes it possible to index just the documents that change, instead of re-indexing the whole collection.
Lunr provides an advanced query language that can express some queries that are currently not possible in MiniSearch. For example, Lunr can search for terms that start with “uni” and end with “ty”, but have any character in the middle, like “unity” and “university”. On the other hand, if you do not need those, you might find MiniSearch API simpler to use.
MiniSearch offers an auto-suggestion feature out of the box. For example, for the partial search “uni”, MiniSearch could suggest “university”, “unicorn”, etc. The suggestions are calculated on the actual documents, and sorted by relevance. This feature can be used to implement auto-completion, like in the demo application shown above. Lunr does not currently offer this feature.

Notably, MiniSearch, Lunr, and Fuse.js all come with zero runtime dependencies, which is quite a good surprise for JavaScript packages!

Conclusion

I hope I managed to give a good enough introduction to client-side full-text search, its pros and cons, and the design decisions behind MiniSearch. I had quite some fun implementing this library, and I am happy to see it used in production by now on way more use cases than I initially forecasted. It was also a teachful experience to delve through the code of other similar projects: each of them came to different interesting solutions to the tricky problem of implementing efficient client-side full-text search.

If you are considering to adopt MiniSearch for a project, more detailed information is available in the documentation and the API reference. MiniSearch is open-source software, and contributions to its code and documentation are more than welcome!

Adopting best practices without being adopted by them

2018-09-19T16:03:00+02:00

A software developer I know was recently faced with a problem: when practicing Test Driven Development (abbreviated as TDD), they felt that the resulting code tended not to follow design patterns. How can one achieve well structured code, that follows the Design Patterns, through TDD?

I feel that this is an interesting question, because it uncovers some important considerations on the way software development is taught and practiced.

The issue, in my opinion, stems from a wrong (but understandable) assumption: that TDD and Design Patterns are best practices that a professional software developer is supposed to follow. Hence the feeling that something must be missing or wrong, if both cannot be achieved at the same time.

TDD and Design Patterns are both tools, not goals. They can be of great help, but they are in no way necessary attributes of good software development, nor rules to abide to.

Design Patterns: the good and the bad

Knowledge of Design Patterns is, in my opinion, much more useful for communication than for architecturing software. Patterns assign names to common “shapes” of software programs, and thus give us useful vocabulary to talk with other developers about code we need to collaborate on, pointing out, for example, how one class implements a “visitor pattern” in order to solve a problem. In this sense, knowing and studying design patterns is useful.

On the other hand, patterns are NOT a benchmark to measure how good some code is, and also not a menu of the proper ways to solve problems with software. First, they are obviously not an exhaustive list of all the possible valid ways to structure code. The original “Gang of Four” classic book lists 23 design patterns, but good design is clearly not about picking the right option out of these 23. Also, those patterns are heavily focused on Object Oriented design, which is just one possible programming discipline: in other contexts, like functional programming, most of those patterns do not have much meaning, while different patterns emerge.

Thinking in terms of patterns when designing code might even be limiting: it’s easy to end up “shoehorning” a solution into a pattern, and failing to recognize simpler solutions. Or worse, recognizing those simpler solutions, but still following the pattern for fear of judgement or to pass a code review.

In other words, patterns are names for structures that we often recognize in code. It’s good to explore them and to give them names, because that empowers us to communicate ideas. But they are not a menu of options, nor a benchmark to measure against. By all means study them, they will enrich your knowledge, but use them as tools, not as a limit on what can be done.

Test Driven Development: a powerful tool, but still a tool

Test Driven Development is a technique, the means to a goal. It’s a powerful and often counter-intuitive method that can guide us in the implementation of a solution. It is definitely not a mandatory way to write software, nor a necessary condition for good code.

Learning to write code test-first is not easy, and takes discipline, but it yields great benefits. It’s important for a well-rounded software developer to learn TDD, and mastering it can take years, but is well worth the effort. That said, tools are things that we choose to use: we should not feel forced to adopt them in all cases.

TDD is especially good when one is faced with a problem that is well understood, even if the implementation can be tricky: it guides us through the implementation, helping us to move in little steps and to formalize what we intend to do in each iteration. Also, it ensures by nature that the code we produce is tested.

When uncertainty is high and the problem is not well understood yet, it’s often necessary to explore the problem space first, by implementing tentative solutions, or by researching and experimenting. In those cases, working in a strictly iterative way gets cumbersome and counter-productive, and it is perfectly reasonable to avoid TDD. Ultimately, you should make sure that you can practice TDD, but if you find yourself hindered by it in a situation, don’t be ashamed to avoid it.

In most situations you should really make sure you write good tests: having good tests decreases the cost of changing your code, and makes it possible to collaborate and evolve the code base productively. But whether you should choose to write tests first or last depends on what is more conductive to good code and tests, in your specific case: TDD is often, but not always, the answer.

Conclusion: sharpen your tools, and mute non-constructive judgement

In conclusion, TDD and Design Patterns (but also Pair Programming, OOD, DDD, Agile, etc.) are tools at your disposal. You should understand why they were conceived, and what issues they help to avoid. You should spend due time learning and mastering them, if you want to be a well-rounded software crafter. Still, once you know them well, remember to keep your critical thinking alert, and to retain the choice of which tools to use in each specific situation.

Unfortunately, these disciplines have often being misused as judgement criteria. One reason is that assuming that there is “One True Way™” to do things well makes the task of teaching and evaluating performance a lot easier (and sterile). Both in education and in professional settings, it’s often too tempting for teachers, recruiters, and supervisors to evaluate developers against a checklist. Moreover, communities are formed around practices, with the goal of promoting their adoption. Those communities tend to protect their identity from change, sometime forgetting the original motivation for the practice. That way, even genuinely good practices can get stretched outside their boundaries and become akin to cults. The antidote is to always demand to know why something is better, without accepting tautological answers.

Our aim should be to master our art more and more every day, and for that we need our critical thinking well sharpened. The satisfaction and peace of mind that derives from a continuous pursue of mastery is a lot more valuable than the temporary reward of satisfying other people’s checklist of expectations, or of pledging our unconditionate belonging to an established group. Surrendering to peer pressure even when our best judgement suggests something different is a false relief.

This does not mean that you should disregard others’ informed opinion, nor that your own judgement will always be correct. But if you have properly considered and understood the options, and you still think there’s a better way, then follow your intuition with an open mind. Either you will prove yourself right, or you will understand your mistake: in both cases you will have learned something.

Delayed jobs with Rails and RabbitMQ

2018-07-31T15:34:00+02:00

I recently had the need to schedule background jobs with a specified delay into the future from a Ruby on Rails application. I had to implement a retry mechanism with backoff, so I needed to be able to express something like “execute job X, but wait Y seconds before doing so”. Clearly, I needed this mechanism to be non-blocking: if a job is scheduled 5 minutes in the future, the workers should be free to process other jobs in the meantime.

Some popular ActiveJob adapters like Resque or Sidekiq implement this feature, which is exposed in the ActiveJob API as the wait: <seconds> option:

1
SomeJob.set(wait: 5.minutes).perform_later(some_argument)

My adapter of choice though is Sneakers, which is based on the superb RabbitMQ. Unfortunately, as of July 2018, the Sneakers adapter does not implement delayed jobs out of the box, as the feature table for ActiveJob::QueueAdapters dutyfully reports (copied from the official docs):

1
2
3
4
5
6
7
8
9
10
11
12
13
|                   | Async | Queues | Delayed    | Priorities | Timeout | Retries |
|-------------------|-------|--------|------------|------------|---------|---------|
| Backburner        | Yes   | Yes    | Yes        | Yes        | Job     | Global  |
| Delayed Job       | Yes   | Yes    | Yes        | Job        | Global  | Global  |
| Qu                | Yes   | Yes    | No         | No         | No      | Global  |
| Que               | Yes   | Yes    | Yes        | Job        | No      | Job     |
| queue_classic     | Yes   | Yes    | Yes*       | No         | No      | No      |
| Resque            | Yes   | Yes    | Yes (Gem)  | Queue      | Global  | Yes     |
| Sidekiq           | Yes   | Yes    | Yes        | Queue      | No      | Job     |
| Sneakers          | Yes   | Yes    | No         | Queue      | Queue   | No      |
| Sucker Punch      | Yes   | Yes    | Yes        | No         | No      | No      |
| Active Job Async  | Yes   | Yes    | Yes        | No         | No      | No      |
| Active Job Inline | No    | Yes    | N/A        | N/A        | N/A     | N/A     |

Sneakers and RabbitMQ are a perfect fit for my specific application: we leverage the highly available queues and versatile AMQP semantics for several use-cases, involving services written in other languages than Ruby. For example, our RabbitMQ exposes a MQTT frontend that collects metrics from our IoT devices, and makes it possible to implement several decoupled data processing pipelines, something cumbersome to implement with Rails-specific queuing mechanisms. Therefore, changing the queue backend just for this feature was not a desireable option: I decided to implement the missing feature instead, and I will show you how.

Luckily, there exists a well designed RabbitMQ plugin that does exactly what I needed, so I just had to write the adapter logic for it. The plugin is called rabbitmq_delayed_message_exchange, and can be easily added to an existing RabbitMQ installation by downloading the binary build, putting it into the plugins directory, and enabling it.

The plugin is well-documented and fairly straightforward to use, for those familiar with RabbitMQ and AMQP. In order to schedule delayed messages, one just has to:

Declare an exchange with type x-delayed-message, and an extra x-delayed-type header to indicate the desired routing semantic to follow after the delay elapses (like “direct”, or “topic”, etc.).
Publish messages on that exchange, providing an x-delay header indicating the desired delay in milliseconds.
Queues bound to the exchange will then receive the message after the given delay elapses, and from this point on everything works according to the standard AMQP protocol.

What was missing was only the integration between this plugin and our Rails + ActiveJob + Sneakers setup. Essentially, I needed to publish jobs that specify a delay on a x-delayed-message exchange, setting the x-delay header. Also, it was necessary to make sure that the delayed exchange actually exists, and that the queue on which we want to route the job is bound to it.

Here’s the code that I ended up writing. It re-defines the enqueue_at method on the SneakersAdapter (the original implementation just raises a NotImplementedError, so augmenting the original class is a reasonable option here):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
require 'sneakers'

module Sneakers
  module DelayedJobSupport
    def enqueue_at(job, timestamp)
      delay = timestamp - Time.current.to_f
      # Just enqueue job if delay is zero or negative
      return enqueue(job) if delay < 0

      # Ensure queue is bound to the delayed message exchange
      self.class.ensure_delayed_exchange_bound(job.queue_name)

      # Publish on the delayed message exchange
      self.class.delayed_publisher.publish(
        ActiveSupport::JSON.encode(job.serialize),
        headers: { 'x-delay' => (delay.to_f * 1000).to_i },
        routing_key: job.queue_name)
    end

    module ClassMethods
      def delayed_publisher
        @delayed_publisher ||= Sneakers::Publisher.new({
          exchange: 'delayed.exchange',
          exchange_options: {
            type: 'x-delayed-message',
            arguments: { 'x-delayed-type' => 'direct' },
            durable: true,
            auto_delete: false
          }
        })
      end

      # The first time a queue receives a delayed job, make sure
      # that the queue is bound to the delayed message exchange
      def ensure_delayed_exchange_bound(queue_name)
        @bound_to_delayed_exchange ||= {}
        return nil if @bound_to_delayed_exchange[queue_name].present?
        delayed_publisher.ensure_connection!
        queue = delayed_publisher.channel.queue(queue_name, Sneakers::CONFIG[:queue_options])
        queue.bind(delayed_publisher.exchange, routing_key: queue_name)
        @bound_to_delayed_exchange[queue_name] = true
      end
    end
  end
end

module ActiveJob
  module QueueAdapters
    class SneakersAdapter
      # Add support for delayed jobs to SneakersAdapter
      extend Sneakers::DelayedJobSupport::ClassMethods
      prepend Sneakers::DelayedJobSupport
    end
  end
end

I can now schedule jobs with a given delay using the standard wait: <seconds> or wait_until: <timestamp> options:

1
2
3
SomeJob.set(wait: 5.minutes).perform_later(some_argument)

SomeJob.set(wait_until: 10.minutes.from_now).perform_later(some_argument)

Wrapping up

RabbitMQ is an excellent messaging queue system (although merits and demerits, when speaking about technologies, are always contextual, so be skeptical of anyone saying “if you don’t use X, you’re doing it wrong”). Sneakers offers a nice adapter to use RabbitMQ as an ActiveJob backend in Ruby on Rails. Unfortunately, it does not implement delayed jobs out of the box.

Luckily, with the help of a nice semi-official plugin, this feature is easy to implement, as shown in this post.

On Engineering Software and Trade-Offs

2017-11-13T14:36:00+01:00

As software developers, we tend to be quite opinionated about our tools and techniques. Our own specific education and experiences shape our preferences, and we often identify with several schools of thought. We might be, for example, advocates of functional programming, practitioners of test driven development, or microservices enthusiasts. On top of this, we all have our preferences when it comes to technology: our favorite programming languages, databases, infrastructure… These preferences shape our identity as software developers, and exert a profound influence on the way we think: we view problems through those lenses, and determine the way we envision solutions.

On one hand, this is often a good thing: these disciplines provide us with a useful model of the programming reality and with ways to navigate it. On the other, strong beliefs might cause us to end up stuck defending our own stance, unable to see the merits of a different view point. It is not unusual to witness developers belonging to different schools of thought vehemently argue over some technical decision, each strenuously defending their own view of the (programming) World.

While there is nothing wrong in recognizing the merits of a technique and in adopting it, we should never forget one fundamental point: pretty much every technical discipline or tool embodies a trade-off. Techniques and technologies are solutions to specific problems, and their merits or flaws are never absolute, but always bound to the context. Being aware of where these trade-offs lie is necessary not only to operate the right choices of tech, but also to maintain an open and flexible mind, capable of changing approach when necessary. Moreover, knowing where costs and benefits lie, provide us with the opportunity to innovate in ways that shift the trade-offs in a better direction.

Static vs. Dynamic Typing

One prominent example of something that many software developers hold strong opinions about, is statically versus dynamically typed languages. Advocates of static typing on one hand often maintain that strong typing is absolutely necessary for any serious project, while – on the other hand – users of dynamically typed languages regard static typing as a tedious and mostly unnecessary ceremony.

Despite these strong beliefs, evidence shows that both approaches can be extremely successful, ruling out a single objective winner of the diatribe. If dynamic typing cannot scale, how can we explain the existence of numerous large projects written in JavaScript, Python, Ruby, etc.? Let alone the immense success of C as a system programming language, which, while definitely not dynamically typed, can hardly be considered a strong type system. Equally, if it was true that static typing only hinders productivity and expressiveness, how could we account for the vast number of widely adopted strongly type languages, and their evident success on the field? The situation is not different if we turn our attention to demerits: no matter how opinionated we might be on one side or the other, we can at least agree that terrible code can be written in any practical language, no matter the type system.

Therefore, instead of adopting an absolute view point, let’s try to focus on the trade-offs of these two approaches. One way to look at it, is that static typing reduces the number of runtime errors, at the cost of requiring more effort to express solutions in code. Seen through these lenses, we can start appreciating how contextual the specific merits of both disciplines are. The cost of runtime errors is indeed vastly different for each specific application.

In a web application for example, “runtime” often means the development machine on which code is written, or the automated test environment. In a non-critical application adopting continuous delivery, even when the occasional bug slips to production, it can easily be reverted or patched with a new deployment. In these situations, favoring a language that makes it convenient to write automated tests, and shortens the test-code-deploy cycle, might often be the right choice. As a counter example, native mobile applications and embedded software follow release cycles that make it costly to deploy a fix to all users, if a runtime bug is discovered. In this cases, a strong type system can help catching defects and inconsistencies before it’s too late, and is worth some more effort to get our software to compile.

One objection to this line of reasoning could be that we should strive to minimize defects, no matter if they are more or less costly. That is of course true, but the point is that this minimization is subject to a cost structure, and the optimal solution depends on those costs. If that wasn’t the case, we would witness a world of absolutely bug-free software. The reality is quite different, and our job as engineers comes necessarily with a fair share of risk management considerations.

Of course there are other trade-offs at play, such as the extent to which IDEs can help us, versus the redundancy of the hints we have to give to compilers for them to help us catching inconsistencies. Again, the point is that being aware of them makes us better equipped to make informed decisions.

There are numerous examples of innovations on both sides that all rely on an awareness of these trade-offs and a conscious effort to improve on them. Type inference is an effort to reduce the additional effort of writing statically typed code, and got to the point that some static languages, like Crystal, hardly require any type annotation at all. On the other hand, there are dynamic languages that add some static analysis capabilities to their toolbox, as seen in Dialyzer for Erlang and Elixir, or Flow for JavaScript, making the static vs. dynamic typing distinction more like a gradient of possibilities than a binary choice.

Microservices vs. Monolith

Another example of a polarizing diatribe is microservices versus monolithic architectures. The term “monolith” is already subtly conveying an association with something old and clumsy, almost prehistoric, testifying how heated the debate is. Equally, the Internet is bubbling with examples of microservice architectures gone awry. But once again, let’s try to steer the conversation away from fruitless animosity by focusing on trade-offs of the respective solutions.

Microservices divide an application in separate and independent artifacts communicating with each other passing messages through standardized interfaces, usually (but not exclusively) implemented as HTTP APIs. As such, microservice architectures make it easier to evolve and improve at the level of the single service: as long as the interface stays the same, a service can be completely rewritten without the other services even noticing. On the other hand, microservices make the boundaries between services way more rigid: changing those boundaries requires careful coordination between different services, and often between different teams.

Depending on the life cycle of a project, and on how stable the functional boundaries are expected to be, this trade-off can change dramatically, making one approach or the other preferable or problematic. This dynamic is not exclusive of our industry: in management studies, this trade-off is known as modularity vs. integrality, and there are plenty of case studies showing how each approach has proved beneficial or detrimental to companies in different contexts.

Once again, being aware of these costs and benefits, makes it possible to consider the context in which we operate our decisions. Moreover, we often have the possibility to shift the balance or hedge the risks, for example by adopting a modular architecture even within a single service, or splitting our services only where boundaries are well known and stable.

Distributed Systems vs. Centralized Systems

One final example is distributed systems versus centralized ones. There has been a lot of innovation in the field of distributed systems in recent years, and we have witnessed a proliferation of new decentralized solutions dealing with storage, configuration management, messaging queues, and more. Proponents of this approach outline the benefits of distribution when it comes to scaling and resilience, but the wave of innovation brought also a certain disdain for centralized solutions.

Distributed systems are a welcome addition to our choice of technologies, but once again, their advantages do not come without a cost. A distributed system reduces the chances of a failure of the whole system, at the cost of having to run and coordinate several nodes, therefore incurring in some overhead, and increasing the chances that any single node will fail, requiring intervention. This might seem like a reasonable trade-off to accept, but there are products or teams where an occasional short downtime is more acceptable than a sustained higher effort on operations.

A centralized system is harder to scale, but on the other hand it is not susceptible to network partitions, hence it is not subject to the CAP theorem and can be at the same time available and consistent. Therefore, depending on the scale and requirements of a particular project, different approaches are preferable.

By keeping this trade-off in mind, and by knowing the specific context and requirements of a project, we are able to make informed decisions, and to consciously mitigate the risks that come with our technology of choice. Furthermore, centralized systems can be backed-up and replicated, and distributed systems can alleviate the operational burden by automating some operations, and by adopting an application design that takes into consideration from the beginning the limits of the system, when it comes to consistency or availability.

Conclusions

In conclusion, the software development universe is full of polarizing dichotomies, and engineers often have strong opinions: functional programming versus object orientation, client-side versus server-side rendering, performance versus maintainability, and so on. Experience should teach us that in each of those dichotomies lies a trade-off, as well as different boundaries of applicability. Reflecting on costs and benefits helps us keeping a flexible mind and recognizing opportunities to adopt different strategies. Reminding ourselves that every solution is contextual and never absolute is an exercise of intellectual honesty, if we strive to be well-rounded engineers. Finally, focusing on trade-offs and context, rather than on position and beliefs, makes technical discussions a lot more enjoyable and less prone to end with an impasse.