Why Abstraction is Necessary for Modern Web Architecture
Why abstraction, and why should I reconsider my web-shop architecture? In the next few minutes, I will attempt to lay clear the increase in architectural flexibility, and the associated profit gains. This is especially true when abstraction is considered foundational rather than cosmetic, operational, or even departmental.
Use Abstraction! It will save you money and increase flexibility!
OK, that was more of a compression than an abstraction 😉
The long story – abstraction a forgotten art
The human brain is bursting with wonder all its own. Just think of the capabilities each of us has balanced between our shoulders.
One such capability is the core concept of using abstraction to grasp the complex world around us and store it in a condensed way.
This, in turn, makes it possible for us humans to talk about objects, structures, and concepts which would be impossible if we had to cope with all the details all the time.
What is Abstraction?
Abstraction is also one of the main principles of programming, making software solutions more flexible, maintainable and extensible.
We programmers are notoriously lazy. As such, not reinventing the wheel is one of the major axioms by which each and every one of us guides our lives by.
Besides saving time, abstraction also reduces the chance of bugs. As a result, should you find any crawling around inside your code, you simply need to squash them in one location, not multiple times over and over again, provided you’ve got your program structure right.
Using abstract definitions to derive concrete implementations helps accomplish precisely this.
Where have you forgotten to implement abstraction?
Nevertheless, there is one location where you might not be adhering to this general concept of abstraction: the central interface between your shop and your underlying search engine. Here you may have opted for quick integration, over decoupled code. As a result, you’ve most likely directly linked these two systems, as in the image below. Search Engines sit atop Webshop architecture, which is most often abstracted.
Perhaps you were lucky enough, when you opened the API documentation of your company’s proprietary site-search engine, to discover well-developed APIs making the integration easy like Sunday morning.
However, I want to challenge you to consider what there is to gain, by adding another layer of abstraction between shop and search engine.
Who needs more abstraction? Don’t make my life more complicated!
At first, you might think, why should I add yet another program or service to my ecosystem. Isn’t that just one more thing I need to take care of?
This depends heavily on what your overall system looks like. For a small pure player online shop, you may be right.
However, the bigger you grow, the more consumers of search results you have. Naturally, this increases the number of search results and related variations across the board. It follows, that the need, within your company, to enhance or manipulate the results will grow congruently. A situation like this markedly increases the rate at which your business stands to profit from abstracted access to the search engine.
One of the main advantages of structuring your system in this way is the greater autonomy you achieve from the site search engine.
Why do I want search engine autonomy?
At this point, it’s necessary to mention that site-search engines, largely, provide the same functionality. Each in its own unique way, of course. So, where’s the problem?
Site-Search APIs are unlikely to be the same among different engines. Whether you compare open source solutions like Solr to Elasticsearch, or commercial solutions like Algolia, FACT-Finder, Fredhopper to whatever else. Switching between or migrating systems will be a bear.
But why is that? All differences aside, the site-search engine use case is the same across the board. Core functionalities must be consistent:
- category navigation
Site-Search abstraction puts the focus on core functionalities – not APIs
The flexibility you gain through an abstraction-based solution cannot be underplayed.
Once you have created a layer to abstract out these functionalities and made them generally usable for every consumer of search within your company, it is simple to integrate any other solution and switch over just like that.
And, since there is no need to deeply integrate the different adapters into your shop’s software, you can more easily enable simple A/B tests.
Furthermore, if another department also integrates search functionalities, it could be easier for them to use your well-designed abstracted API without re-inventing the wheel locally. Details like, “how does Solr create facets”, or “how do I boost the matching terms in a certain field”, do not need to be rehashed by each department.
Solve this once in your abstraction layer, and everyone profits.
A real-world example worth having a look at is our Open Commerce Search Stack (OCSS). You can find an overview of the architecture in a previous blog post [https://blog.searchhub.io/introducing-open-commerce-search-stack-ocss]. The OCSS abstracts the underlying Elasticsearch component and makes it easier to use and integrate. And, because this adapter is Open Source, it can also be used for other search solutions.
By the way, this method also gives the ability to add functionalities on top. An advantage which cannot be overstated. Let’s have a look at a couple.
Examples of increased webshop flexibility with increased abstraction:
- You want to add real-time prices from another data source to the results found? Just add this as a post-processing step after the search engine retrieved the list of products.
- You want to map visitor queries to their best performing equivalent with our SmartQuery solution? Easy! Just plug in our JAR file, add a few lines of code, and BAAAM, you’re done.
This also enables the use of our redirect module, getting your customers to the right target page with campaigns, content, or the category they are looking for.
Oh, and if you simply want to version update your engine, any related API changes can be “hidden” from the consuming services, making it easy to stay up to date. Or at least making new features an optional enhancement that every department can start using whenever they have the time to integrate the necessary changes and switch to the new version of your centrally abstracted API.
Depending on the complexity of your webshop’s ecosystem and the variety of services you already use or plan to integrate, abstracting the architecture of your internal site-search solution and related connections can make a noticeable difference.
In the long run, it can save you a lot of time, and headaches. And in the end increase profits without having to reinvent the wheel.