ArticleIntroductionText

The developer community has put a significant amount of effort into creating code-first solutions to GraphQL API development, especially in the Python ecosystem, rightfully attempting to ease development while combatting code duplication.


Text

<p>Some consider this process as a natural evolution and see code-first solutions as the logical next step. However, both solutions come with intrinsic architectural choices and lead to multiple software options. We should consider placing the role of schema in architecture as a fundamental variable for every project, depending on the specifics. Let’s review our possibilities and then we’ll make a compelling case for schema-first as a default solution.</p>

<h2>The Background: Schema-First vs. Code-First Approaches</h2>

<p>If you don’t have a great deal of GraphQL experience, here is a quick recap. In GraphQL, the API is defined using its own <a href="https://graphql.org/learn/schema/" rel="noopener noreferrer" target="_blank">Schema Definition Language</a> (SDL):</p>

CodeBlock

<p>It might look familiar to you if you have had some experience with protocol buffers. As we can see, it comes with its own strong static type system with all primitives, lists, and even unions and interfaces. It’s worth remembering that GraphQL is not supposed to be used to describe tree-like structures but rather enable graph nodes relations, so we are encouraged to use connections between all meaningful entities and there is no root node (this is why the GraphQL logo is not a tree). For a comprehensive overview of GraphQL, check out our article on <a href="https://mirumee.com/blog/what-is-graphql?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_schema_first_graphql_less_travelled" rel="noopener noreferrer" target="_blank">what is GraphQL</a>.</p><p>In schema-first solutions, we need to write our schema in SDL language and then we load it into our server application, parse it into an internal representation and map resolvers (functions providing us with field values) to fields. Some of this process is performed manually and we need to have all data structures present both in the SDL format and the native application language.</p><p>This is how one simple example would look in our <a href="https://github.com/mirumee/ariadne" rel="noopener noreferrer" target="_blank">Ariadne</a> server:</p>

<div>To run it locally and play around, just install <a href="https://github.com/mirumee/ariadne" target="_blank" rel=“nofollow”>Ariadne</a> and <a href="https://www.uvicorn.org/" rel=“nofollow”>Uvicorn</a>. Now we can run it by a simple command:</div>

<p>Great! In the real world, you would probably choose to keep your schema in a separate <em>schema.graphql</em> file or even multiple files that are joined and validated while building executable schema. We decided to enable schema modularization from early on in Ariadne but here it would only make our example harder to understand.</p>
<p>The superpower of GraphQL comes mainly from the ability to precisely express what data fields, and in what shape, we desire on the client side. This is a sample query on our existing server:</p>

<p>SDL came surprisingly late to the party but now it is an official core part of GraphQL specification. However, developers already created frameworks, such as Graphene, in which GraphQL schema is defined as a native language abstraction and directly connected to resolvers. When the application starts up, the framework automatically compiles schema from those abstractions. This code-first approach is implemented in libraries such as <a href="https://graphene-python.org/" target="_blank" rel=“nofollow”>graphene</a> (Python), <a href="https://graphql-ruby.org/" target="_blank" rel=“nofollow”>graphql-ruby</a>, <a href="https://github.com/graphql-rust/juniper" target="_blank" rel=“nofollow”>juniper</a> (Rust), Prisma <a href="https://github.com/prisma/nexus-prisma" target="_blank" rel=“nofollow”>nexus</a> and <a href="https://sangria-graphql.org/" rel=“nofollow”>sangria</a> (Scala).</p>
<p>The previous example presented in Graphene would look more or less like this:</p>

<p>Why would anyone want to write SDL manually if code-first solutions are already out there? Who needs two languages instead of one? It is not as simple as it looks at first glance.</p>

Image

<h2>Why Choose Schema-First Approach in GraphQL Development?</h2>

<p>One of the main designing forces while working on new functionalities is confirmation bias and extrapolating what we know about the inner workings of the backend system into what we think will be a proper system interface. It is hard or nearly impossible for a backend developer to fully detach from preconceived notions about the implementation he is working on. As Daniel Kahneman describes in “Thinking, Fast and Slow”, our brains have two systems: one for intuitive, automatic responses and a second for deliberate, logical decisions. We heavily favor the first, as it requires less effort and improves responsiveness, but it leads us to simplifications and implicit pattern replication.</p>

Testimonial

We can be blind to the obvious, and we are also blind to our blindness.

<p>The intuitive and automatic system in our brains is a powerful and effective tool, but sometimes it is good to look at things from the other perspective. We often make different choices when a question is phrased differently and, similarly, we can end up with completely different code if we switch context. “We are all shaped by the tools we use,” is how Edsger W. Dijkstra phrased it.</p>

<h2>More Familiar Analog: Test-Driven Development</h2>

<p>Why mention such bizarre trivia in the article about GraphQL? We can show its relevance in a more familiar example.</p>
<p>The mental process mentioned above is one reason why Test Driven Development has such a strong impact on code quality and reliability. If you are interested in good practices, you have probably at least tried using TDD for a while and, even if you finally came to the conclusion that the benefits are not worth the hassle, you most likely discovered something peculiar about your code.</p>
<p>Using software as a client before implementing the solution forces us to first consider use cases and user convenience; we work only on code needed to fulfill assertions made in tests, limiting the resulting complexity to an absolute minimum. It also makes the use of mockups and fakes very desirable, allowing for usage of the interface only during development and delegating external parts for later. By moving test writing one step ahead of the production code, we end up with more modular and maintainable design; it gives us an opportunity to come up with usable interface long before getting our hands dirty with technical details.</p>
<p>This is a great practical exercise to better understand the importance of using contracts when reasoning about software that communicates. All we need to do now is to apply this principle to a higher layer of abstraction: APIs.</p>

<h2>Enhancing Collaboration with Schema-First Contracts</h2>

<p>So coming back to our everyday reality; treating a schema as a product of business code means that every change in the backend can cause interface changes. These are fine for backend development, since everything builds up from core business entities, but they introduce code dependency between the client and server side, making it implicitly the client’s responsibility to align with changes.</p>

<span style="font-family: __neueHasGrotesk_615dff, __neueHasGrotesk_Fallback_615dff, sans-serif; font-size: 20px; font-variant-ligatures: normal; font-variant-caps: normal;">Our job as developers is to lay the foundation from which it is easy to do good and hard to make costly mistakes. The problems we discuss here are not related to the attitude or communication of developers; this kind of code dependency results in all sorts of organization artifacts, component divisions, communication patterns, CI/CD flows and planning blind-spots that lead to avoidable conflicts, bugs, and poor design.</span>

<h2>Deep Dependency Issues in GraphQL Development</h2>

<p>The problems we see with GraphQL are not new or unique; they strongly resemble those encountered by designers of Object Oriented software or micro-services architects. History is full of lessons learned the hard way. This is the reason for the Dependency Inversion Principle (DIP), Inversion of Control (IoC) and Dependency Injection (DI). In our particular scenario, DIP applies the best.</p>

Deep Dependency Issues in GraphQL Development

ImageDescription

<h2>What is Dependency Inversion Principle (DIP)?</h2>

<p>According to <a href="https://en.wikipedia.org/wiki/Dependency_inversion_principle#cite_note-Martin2003-1" rel="noopener noreferrer" target="_blank">Wikipedia's, the definition Dependency Inversion Principle</a>&nbsp;states:</p><ol><li>high-level modules should not import anything from low-level modules. Both should depend on&nbsp;abstractions.</li><li>Abstractions should not depend on details. Details should depend on abstractions.</li></ol><p>The underlying idea behind this principle is to reverse runtime and code dependency in a project, giving us the freedom to use any implementation we want, as long as it is based on the right prototype. We basically introduce contract-based polymorphism into our system. Both the client and the implementation depend on a common interface, thus breaking the dependency nightmare and making it simple to check for compatibility issues.</p><p>In the OOP world, this results in Interfaces or Abstract Classes that are a base for concrete implementations; production algorithms are being built by injecting anticipated instances into places already defined by their interface in the general flow (Dependency Injection). For example, we may use a fake building block when testing or switch strategy on the fly, depending on the situation.</p>

<h2>Why I'm Ditching Traditional Classes for Modern GraphQL Development?</h2>

<p>Rules are there for a good reason and extend far outside the OOP kingdom. Such a guiding principle (DIP) is useful wherever we encounter dependency issues and a need for polymorphic behavior. <br><br>You should keep it in mind even if, like me, you are skeptical about object-oriented programming. Personally, I find <a href="https://medium.com/@dhkelmendi/solid-principles-made-easy-67b1246bcdf" rel="“nofollow”">SOLID</a> rules much more suited for the component-scale design than for business logic modules.</p>

<h2>How to Apply Schema-First in Your GraphQL Service Architecture</h2>

<p>TDD might help introduce DIP into the process of writing backend units since the programmer is also later the code user, but that trick won’t work on an API as the code is usually passed over to a frontend team.</p>
<p>The most obvious solution is to write SDL first, then give it to both the frontend and backend side to independently implement. There are a few existing solutions to mock GraphQL SDL with fake data and make it possible to test your client without any existing backend.</p>
<p>Another problem lies in the timing. A new API is nonexistent until the backend work is mostly finished and the interface is generated, meaning that client-side work happens once the backend is finished.</p>

<h2>Good Implementations of Schema-First Should Minimize Effort</h2>

<p>
  We should also think about how failure to keep layer content on similar
  abstraction levels causes a great number of problems. Very low-level details
  are too easily introduced into schema and data formatting when using
  code-first solutions, which would never occur to us as a valid option if we
  tried to come up with the schema shape first.
</p>
<p>
  It’s clear that APIs must be driven by their client use cases, ease of use,
  and the need to allow simultaneous frontend and backend implementation
  efforts. All of this comes almost for free when using schema-first GraphQL
  development for its contract-based approach.
</p>


<h2>Additional Benefits of Schema-First in GraphQL Development</h2>

<ol><li>Expressing GraphQL in its native language is ideal but, in the complex world of development, you might find keeping common knowledge more valuable.</li><li>Hiding your database schema makes it less likely to be directly exposed in your client’s interface in a well-known anti-pattern. This can lead to numerous problems like naming issues and schema updates.</li><li>Making schema an entity on its own could allow for a more flexible approach to designing your architecture and leave more wiggle room for moving stuff around late in the development cycle.</li><li>Last but not least, it is a much better approach to integrate into test-first development and QA processes. Make schema changes, along with black box acceptance testing, an integral part of your definition of done and use them to catch mistakes early into development.</li></ol>

Benefits of Schema-First in GraphQL Development

<h2>Pros and Cons of Code-First Development in GraphQL</h2>

<p>Schema-first development comes with a certain price tag. It is definitely more verbose on the backend side, almost certainly resulting in some level of code duplication and an additional layer of abstraction to manage manually that will be responsible for field and resolver mapping. This is true for all patterns dealing with Dependency Inversion Principle and apparently does not render them useless; either way, in some edge-case circumstances this may result in a lot of additional code and the end may not be worth the means.</p><p>We also need to be aware of quiet regression. Imagine enumeration type as expanded in SDL without the backend team noticing, you might need to check for additional value in your core logic — but the type system will probably catch only disappearing elements. This issue is platform-specific and can be prevented by proper tooling.</p><p>Many projects today consist of multiple services and schema relegation, or stitching for such architecture might also be more cumbersome and involve more upfront investment. Since not all platforms will come up with convenient code-first solutions and tooling, it is also hard to predict if there will be any compatibility problems.</p><p>You should also consider a code-first approach if you need to keep the shape of the API close to the data model, when you need to constantly align trivial changes between API and implementation, and when the frontend is not a priority.</p><p>You can read more about<a href="https://www.prisma.io/blog/the-problems-of-schema-first-graphql-development-x1mn4cb0tyl3" rel="noopener noreferrer" target="_blank"> the Problems of Schema-first GraphQL Server Development in Prisma's article.</a></p>

<h2>Ariadne: The Beauty in Simplicity GraphQL Development with Schema-First Approach</h2>

<p>Coming from a Django background, we naturally ended up using the Graphene ecosystem for our GraphQL APIs, which is code-first and is a heavily abstract framework to work with. As we encountered problems with this solution, some of which were related to the code-first approach, we realized it wasn’t for us. Unable to find a suitable schema-first solution for Python development, we eventually decided to just write our own. </p><p><br></p><p>Check out <a href="https://mirumee.com/blog/ariadne-0-2-0-released?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_schema_first_graphql_less_travelled" rel="noopener noreferrer" target="_blank">Ariadne</a>, which we think makes pythonic GraphQL server development simple and fun. It is deeply rooted in our appreciation for simplicity and extensibility, giving you all the tools needed to mindfully craft your reasonable service.</p>

Ariadne: Simplicity GraphQL Development with Schema-First Approach

<h2>Final Thoughts on Embracing Schema-First in GraphQL Development</h2>

<p>All things considered, schema-first development should be considered a default choice if no additional constraints are obvious, but the whole GraphQL ecosystem is in the early stage of rapid growth and it is hard to predict what the future will bring.</p><p>This first article is a manifesto but we’ve got a lot of other interesting ideas around the Schema-first approach that we will be sharing in future articles. So, keep your eyes open for those.</p><p>Meanwhile, you can also join our thriving community and explore our recent <a href="https://mirumee.com/blog/graphql-meetup-1-a-great-beginning" rel="noopener noreferrer" target="_blank">GraphQL Meetup #1</a> to see how we connect developers.</p>

DotsDivider

<p><em>Mirumee guides clients through their digital transformation by providing a wide range of services from design and architecture, through business process automation, to machine learning. We tailor services to the needs of organizations as diverse as governments and disruptive innovators on the ‘Forbes 30 Under 30’ list. Find out more by visiting our </em><a href="https://mirumee.com/services/" rel="noopener noreferrer" target="_blank"><em>services page</em></a><em>.</em></p>

Schema-First GraphQL: The Road Less Travelled

Implementing a CDN (Content Delivery Network) can significantly enhance your web application by reducing the need for multiple back-end servers. This shift not only results in faster loading times for end-users but also streamlines content delivery.

<p>However, integrating a CDN into your system is not straightforward and involves careful preparation. This article will guide you through the essential steps needed to effectively set up a CDN&nbsp;<span style="font-family: __neueHasGrotesk_615dff, __neueHasGrotesk_Fallback_615dff, sans-serif; font-size: 20px; font-variant-ligatures: normal; font-variant-caps: normal;">and make your site faster.</span></p>

<h2>Understanding the Core Issues with CDN Caching</h2>

<p>Let’s say that you have a popular site which is visited by a large amount of users every minute. You’ve may have already fixed all the code-related problems and patched the bottlenecks that were highlighted in the previous articles, but you still need quite a lot of servers to handle traffic peaks without downtime.</p><p>First of all we should think about the root cause of problems. During a high traffic peak, every client that enters your site (for example, with a link that leads to a list of products) forces the backend to fetch the product data from the database, render the appropriate template, and return the content to the client’s browser. This process is repeated for each click of every user visiting the same page.</p><p>We could save a lot of time if we could do this only once and reuse the result for multiple customers. which is where CDN comes to the fore.me text.</p>

CDN (Content Delivery Network) is a method of content delivery that uses a
distributed network of servers, spread across all continents. The end-user is
served by the closest CDN node without having to connect to the original server
which hosts the website. The CDN nodes usually have direct internet connections
with most internet providers, so their response is much faster. Some of the most
popular CDN services include Akamai, Cloudflare, and Cloudfront on AWS.


<h2>Cache Invalidation Challenges in CDN Caching</h2>

<p>
  Two of the most complex problems in computer science are naming things and
  cache invalidation. You can’t enable caching for all your content without
  tweaking your app’s code, otherwise you’ll end up serving the same content to
  each user, such as the same cart or checkout form. Let’s take a closer look at
  the cache invalidation problem.
</p>


<h2>How to Control the CDN Behavior?</h2>

Controlling the caching behavior is a very important part of the introduction of CDN. The backend application should have full control of cached content and also have the ability to invalidate it. Most of the hosted services like Akamai or Cloudfront deliver a special API that allows you to invalidate the content by specifying the URL. The CDN services also honor the standard cache controlling features defined by the HTTP protocol. Using them allows control of the cache without sticking to a specific CDN vendor. Controlling the cache is enabled by two HTTP headers — ‘Cache-Control’ and ‘ETag’.

<div>The value of this header basically controls how any higher level caching system should proceed with the content. It should be set to ‘no-cache’ for user-specific sections, like the user profile, cart or checkout.</div><div><br></div><div>In other application sections, this header could contain the maximum amount of time for caching a page (for example, 10 minutes).</div>

<p>This header contains a ‘version’ of content generated by the application. It’s extremely important to update this value when the content changes, otherwise the CDN will serve outdated content to the end user. The value could be any string you choose, such as the md5 hash of the content or the last update date.</p><p>So, we have Cache-Control and ETag, but how does it work under the hood?</p><p>Example:</p><p>Let’s consider the following setup:</p><p>User — a browser</p><p>CDN — a CDN endpoint (AWS Cloudfront, Akamai, Cloudflare, etc.)</p><p>Backend — a web application backend</p><p>The core idea is to point your main domain (example.com in this case) to the CDN endpoint instead of to your own web server. It will offload all content from your own servers to the CDN network managed by the third party.</p>

<p>
  In this case, the user requested a page that was not present in the CDN cache,
  so it was generated by the backend and stored in the CDN cache. It will be
  there for a maximum of 3600 seconds.
</p>
<p>
  Every subsequent user asking for example.com will receive the cached content
  without hitting the backend.
</p>
<p>This version of the content will be valid for the next 3600 seconds.</p>


<p>After the time elapses, the CDN will query the page from the backend again.</p><p>With every change to the content, the backend should update the ETag value to make the CDN aware of the newer version.</p>

<h2>Optimizing Performance with CDN Integration</h2>

<p>Setting up a CDN service in front of your site can improve your user’s experience while visiting the site. Nevertheless, you should remember that introducing a CDN or another high-level caching system can bring a new class of problems, so never start optimizing the performance with cache and CDN. When you’ve polished your codebase and optimized it as much as you can, you can add the CDN as the cherry on the cake and further improve site loading times.</p>

<p><em>Mirumee guides clients through their digital transformation by providing a wide range of services from design and architecture, through business process automation to machine learning. We tailor services to the needs of organizations as diverse as governments and disruptive innovators on the ‘Forbes 30 Under 30’ list. Find out more by visiting our </em><a href="https://mirumee.com/services/?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_improving_site_performance" rel="noopener noreferrer" target="_blank"><em>services page</em></a><em>.</em></p>

Improving Your Site Performance with CDN and Caching

Recommendation Systems improve both customer experience and sales. Recommendation System is a must-have for modern e-commerce. A simple system can be built in less than an hour

<h2>Why Python Recommendations Matter for eCommerce Success?</h2>

<p>You may not always realize it, but so many of the websites you use on a daily basis have built-in Recommendation Systems that are driving your experience — as well as nudging you towards purchases.</p><p>They are a must-have feature for any e-commerce website. We recently built one for a major apparel retailer which increased conversion rate by 1% and improved average order value by 5.55%. It helps if you have an expert team behind your implementation, but we believe that most people can get a handle on the concepts and even have a go at building their own simple systems. Let’s get down to business.</p>

<h3>Understanding Collaborative Filtering</h3>

<p style="font-family: __neueHasGrotesk_615dff, __neueHasGrotesk_Fallback_615dff, sans-serif; letter-spacing: 0.5px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 450; font-size: 20px; color: rgb(24, 24, 24); text-align: start;">The fundamental idea used in recommendation systems — Collaborative Filtering — works on the assumption that if two (or more) users rate common items the same way, they probably have similar taste. It is a mathematical equation with many unknowns — and the bigger the database of users and items, the more it sprawls towards infinity. But don’t let the math scare you off.</p><p style="font-family: __neueHasGrotesk_615dff, __neueHasGrotesk_Fallback_615dff, sans-serif; letter-spacing: 0.5px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 450; font-size: 20px; color: rgb(24, 24, 24); text-align: start;">Sudoku is a mathematical equation with nine unknowns. You can do it the nerdy way, reducing it to nine linked equations, but it takes a lot of work before you get down to real business. In fact, the quickest way to complete the puzzle is usually through logical thinking and risk (guessing). Filtering uses a similar mix of math and intuition.</p>

<h3>A Practical Example for Movie Recommendations</h3>

<p>Let’s imagine that cinephiles Tom and Ben both use our movie website. They don’t know each other but were equally excited by Gal Gadot running through no-man’s land in Wonder Woman, both rated Harry Potter as more “Accio” than just okay, both loved Avatar, and agreed that Godzilla kind of sucked.</p><p>However, when it came to the new Star Wars movie, things went a different way. Ben rated it first and loved it. We’d assume from what we know so far that Tom would feel the same, but he wasn’t into it at all. In fact, the algorithm now thinks that Tom’s preferences are more in line with Caitlyn’s.</p><p>The system would not be wrong to recommend Star Wars to Tom based on Ben’s rating. All the data suggests that Tom will like it; but there is still always an element of guessing, as there is no real accounting for taste. The system will never be right 100% of the time but, with enough data, we can find full or partial taste matches for people; learning as much from where people’s reactions are the same as from where they differ. It can collect people in pairs or groups and make the best possible guess with the information at hand.</p>

<h2>Importance of Data in Python-Based Recommendation Systems</h2>

<p>We can use two different types of customer feedback when to create data. The first, ‘explicit’ feedback, is when users provide clear, affirmative information through actions like rating or buying a product or watching a film on a service like Netflix. These are obvious choices, but human activity is often more subtle.</p><p>‘Implicit’ feedback is when a user gives us a suggestion of their interest by perhaps watching a trailer or reading a review. A user might click on a product but not buy it. They have signaled intent but not committed an action.</p><p>When building recommendation systems, we need to decide whether explicit or implicit feedback is of most value to us, and also how it should be weighted. Can we learn as much from intention as we can from a completed action? And how do we factor in negative implicit feedback like a user watching only the first few seconds of a movie trailer? It’s a complex area that we will debate in another post. For our current example, we can assume that rating a movie is sufficient user feedback.</p>

<span style="font-family: __neueHasGrotesk_615dff, __neueHasGrotesk_Fallback_615dff, sans-serif; font-size: 20px; font-variant-ligatures: normal; font-variant-caps: normal;">We should also say that, in our example, we are not dealing with the so-called&nbsp;</span><span style="font-family: __neueHasGrotesk_615dff, __neueHasGrotesk_Fallback_615dff, sans-serif; line-height: inherit; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 700; font-size: 20px;">cold-start</span><span style="font-family: __neueHasGrotesk_615dff, __neueHasGrotesk_Fallback_615dff, sans-serif; font-size: 20px; font-variant-ligatures: normal; font-variant-caps: normal;">&nbsp;</span><span style="font-family: __neueHasGrotesk_615dff, __neueHasGrotesk_Fallback_615dff, sans-serif; line-height: inherit; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 700; font-size: 20px;">problem</span><span style="font-family: __neueHasGrotesk_615dff, __neueHasGrotesk_Fallback_615dff, sans-serif; font-size: 20px; font-variant-ligatures: normal; font-variant-caps: normal;">. When new users sign up to a service or visit a site for the first time, we don’t know much about them yet. On our movie site, the user needs to watch a few films before we can make recommendations. And when a new movie is added, it needs some ratings before it can be paired with other films. <br><br>To get the ball rolling, we might make some educated guesses or ask new users a few questions when they sign up to start feeding data into the algorithm. On Netflix, you are asked to choose a few titles you like to help “jump-start” your recommendations as a new user. If you choose none, you’ll be shown a generic choice of popular titles and your activity from that point will be the basis for the process.</span>

<div>Assuming we’ve got our users and started gathered some explicit data, the next step towards building a recommendation system is to look at the actual ratings users gave:</div>

Understanding User Data for Accurate Python Recommendations

<p>This matrix, called <strong>rating matrix (R)</strong>, has some missing elements because, in real life, nobody has seen every movie. At this point, we can define what our recommendation system should do. <strong>We want the system to guesstimate how Caitlyn would rate Wonder Woman and Avatar</strong> so it can then <strong>recommend one or both to her if it decides that she would give them a high rating</strong>.</p><p>To do so, we can apply a technique called matrix factorization, more specifically, <strong>SVD</strong> (Singular Value Decomposition). It is a method of grouping items from the original matrix <strong>R</strong> into abstract concepts. It breaks down the elements of the matrix into single factors, removing all the information such as names and movie titles, to create pure mathematical results. These determine how each user correlates with each value. With this information, the system can try to predict missing fields in the <strong>R</strong> matrix by combining users' preferences with movie summaries. Of course, ours is only a simplification of what is actually a much more complex, automated process.</p>

More than 80 per cent of the TV shows and movies people watch on Netflix are discovered through the platform’s recommendation system.

<h2>Implementing SVD for Robust Python Recommendation Systems</h2>

<div>
  With the theory out of the way, we can start building the actual system.
  Fortunately, we don’t need to implement all the algebra magic ourselves, as
  there is a great Python library made specifically for recommendation systems:
  <a rel=“nofollow” target="_blank" href="http://surpriselib.com/">Surprise</a>. In a few lines of code, we’ll
  have our recommendation system up and running. First, let’s import the
  necessary components:
</div>


<div>Recommendation systems need historical data to work properly. As we are interested in knowing user movie ratings, we can use the famous MovieLens-100k dataset and present it as such:</div>

Implementing SVD for Robust Python Recommendation Systems

<div>In Surprise, all we need to do to get this data is to use Dataset class and then extract the <a href="https://en.wikipedia.org/wiki/Training,_validation,_and_test_sets">training set</a> (the dataset used for training our model):</div>

<p>Of course, this is just an example, in real life we won’t be using MovieLens. Surprise documentation provides a <a href="https://surprise.readthedocs.io/en/stable/getting_started.html#use-a-custom-dataset" rel="noopener noreferrer nofollow" target="_blank">nice tutorial</a> for loading custom datasets.</p><p>The library comes with the SVD technique we discussed earlier straight out of the box:</p>

<div>We create an object representing our model and train it on MovieLens. We are interested in predicting every user’s ratings for movies they haven’t seen, for which Surprise also has a tool:</div>

<div>build_anti_testset method returns a new dataset with user-movie pairs not present in the training set. In other words, movies that users haven’t yet seen. Predicting ratings for these blank fields is as simple as running one line:</div>

<div>We get a list of Prediction object describing users, movies and a predicted rating:</div>

<p>This list might look overwhelming, but we are only interested in three fields:</p><ul><li>uid — the user ID, for whom we carry out predictions</li><li>iid — item ID (here we treat movies as items)</li><li>est — estimated rating for an item, as we expect the user to give</li></ul><p>The actual <strong>recommendation</strong> happens when we display the top rated results to the user as something they might be interested in. For a detailed guide, refer to the <a href="https://surprise.readthedocs.io/en/stable/FAQ.html#how-to-get-the-top-n-recommendations-for-each-user" rel="noopener noreferrer" target="_blank">Surprise documentation</a>.</p>

<h2>Discover More Insights for Building a Powerful Recommendation System</h2>

<p>This article is part of a series. For more insights about building a recommendations system, read also:</p><ul><li><a href="https://mirumee.com/blog/everything-you-need-to-know-before-building-a-recommendation-system?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_building_python_recomm_systems" rel="noopener noreferrer" target="_blank">Everything You Need to Know Before Building a Recommendation System</a></li><li><a href="https://mirumee.com/blog/the-difference-between-implicit-and-explicit-data-for-business?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_building_python_recomm_systems" rel="noopener noreferrer" target="_blank">The Difference Between Implicit and Explicit Data for Business</a></li><li><br></li><li>In future, we’ll talk about how to display recommendations in a more effective way, as well as a post on choosing the right data for your system. If you want to learn a little more right now, these links are a pretty good place to start:</li><li style="text-indent: 1em;"><a href="https://surprise.readthedocs.io/en/stable/getting_started.html" rel="noopener noreferrer" target="_blank">Surprise library</a></li><li style="text-indent: 1em;"><a href="http://nicolas-hug.com/blog/matrix_facto_1" rel="noopener noreferrer" target="_blank">Understanding Matrix Factorization for Recommendation</a></li><li style="text-indent: 1em;"><a href="https://github.com/lyst/lightfm" rel="noopener noreferrer" target="_blank">LightFM — a hybrid recommendation system helping with cold start problem</a></li></ul>

<p><em>Mirumee guides clients through their digital transformation by providing a wide range of services from design and architecture, through business process automation, to machine learning. We tailor services to the needs of organizations as diverse as governments and disruptive innovators on the ‘Forbes 30 Under 30’ list. Find out more by visiting our </em><a href="https://mirumee.com/services/?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_building_python_recomm_systems" rel="noopener noreferrer" target="_blank"><em>services page</em></a><em>.</em></p>

Building Python Recommendation Systems that Work

Learn how to build powerful recommendation systems by combining user preferences with collaborative filtering. This article explores practical techniques for achieving accurate user matches and smart product bundling. It will help your system to deliver personalized and practical recommendations.

<p>In the first article of this series about <a href="https://mirumee.com/blog/building-python-recommendation-systems-that-work?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_everything_need_know_before_building_recomm_syst" rel="noopener noreferrer" target="_blank">building Python Recommendation Systems</a>, we discussed how they work and gave some simple tools that anyone can use to get started. The best place to start is to check out that article, but if you need a quick refresher, here are the basics:</p>

<ul><li>Recommendation Systems collect data on user behavior and predict which
    products or services will be of interest to them
  </li>
  <li>
    When users have similar histories and preferences, the system presents User
    B with recommendations that User A liked
  </li>
  <li>
    The basic job of a system is to fill in the gaps, deciding if a product that
    a user has not seen or interacted with will be of interest to them
  </li>
</ul>
<p>
  If you want the simplest possible example, click ‘Your Discover Weekly’ on
  Spotify and you will be given a list of songs that you have never played on
  the platform but which the recommendation system believes you will like based
  on your listening history.
</p>
<p>
  In the next two articles, we are going to go deeper, starting with some of the
  most common questions that come up when businesses think about building a
  Recommendation System.
</p>


<h2>How Do Recommendation Systems Benefit Different Businesses?</h2>

<p>The first question you need to ask when creating a Recommendation System (RS) is whether your users are generating enough data to make it worthwhile. It costs time and money to implement a good system. If your solution is not going to be effective for business, your valuable resources would be better spent elsewhere.</p><p>In Spotify, YouTube, Facebook, Netflix or Amazon, regular users are looking for ever-improving personalized experiences. As they use the system more, the recommendations should become more specific and more accurate.</p><p>If people only visit your store once or twice, you can’t offer that experience; but that doesn’t mean an RS is useless. Rather than having a personalized system, you can collate the behavior of all your users to make more general recommendations. For example, if a new user clicks on a specific coat in your store, you can recommend a scarf that was also purchased by previous customers who bought the coat.</p><p>In this scenario, almost all businesses can benefit from Recommendation Systems; the only time that it is unlikely to have any business value is if you have a limited product range and very low site traffic. If you offer only a few high-value products, which you sell infrequently, then the effort behind an RS may not be worth it.</p>

How Do Recommendation Systems Benefit Different Businesses?

<h2>How Many Data Points  Is Needed for a Recommendation System?</h2>

<p>How long is a piece of string? Many people accept the minimum threshold of 1,000 respondents before survey results can be published. With Recommendation Systems — as with opinion polls — the rule of thumb is “the more data the better”.</p><p>If we only sold 8 packs of diapers in our online store, but everyone who bought diapers also purchased diaper disposal bags, we have a very limited data set but a 100% correlation. It’s fair to say that our store should recommend disposal bags to every new user who views diapers. Of course, the trend may change as we gather more data over time, but the initial assumption is solid. We don’t need 1,000 people buying both products before we call it an upselling opportunity.</p><p>A good Recommendation System is one that can spot trends as soon as they emerge and use future responses to confirm or disprove the assumption. And more data does not always mean clearer insight. And if a million people like Game of Thrones on our ratings site and 50% of those people also like True Detective, we can’t draw any strong conclusion.</p>

<h2>How to Determine Optimal User Matches?</h2>

<p>Everyone is unique. My former best friend and I agreed totally on music and films. We were 100% matched until he told me that he doesn’t like Pearl Jam… We never spoke again.</p><p>An RS will never be able to match User A to User B with perfect results, as their tastes will diverge at some point. If two users both rate 9 bands as good but differ in their opinion of the tenth, they are still a very strong match. If User A rates the eleventh band as good, we should still assume User B will like them. But at what point do users stop being a good match? 90% compatibility? 80… 60… 40?</p><p>The truth is, recommendation engines don’t set a threshold when looking for compatibility between people; they look for the best possible match. If we have a user, Alice, who has a 95% compatibility with Bob, 80% with Carol, and 30% with Dave, the system will start by looking at Bob when deciding if Alice will like a certain band. If Bob has not given a response to that band’s music, the system will move on to Carol, and then to Dave. The more users we have in the data set, the more likely it is that a person with a high compatibility will give a response that the system can leverage.</p>

<h2>What’s Better: User Matches or Product Bundling?</h2>

<p>We are discussing two basic types of recommendation here. The first is user-to-user, in which we see that User A is similar to User B and make suggestions to User B based on what their ‘digital twin’ bought or browsed. The second is product bundling, in which our scarf and coat were popular choices together, as were the diapers and the disposal bags.</p><p>The best Recommendation Systems are able to utilize both sets of parameters to extrapolate the very most from the data. But there are rules of thumb that are worth considering. For example, in an online store, while your customers are browsing products, you might want to focus on user-to-user recommendations and show them products that similar customers liked. Once they are in the checkout and have the items in their cart, you might want to push product bundles. For example, if someone just has the diapers in their cart, a good system would remind them to add disposal bags before they pay the bill.</p>

<h2>When Is It Necessary to Implement a Cold-Start Engine?</h2>

<div>
  Cold starts, as described in the previous article, are when a new user comes
  to a site and we know nothing about them. So, how can we start making
  recommendations to give them the best possible experience from their first
  visit?
</div>


Users have almost infinite choice and you have only a short time to grab their attention. Give people a personalized experience first time out.

<p>
  Sites like Netflix ask new users to select a few movies they are interested in
  before entering the site for the first time. If the new user chooses ten
  romcoms, Netflix will probably suggest Maid In Manhattan and The Big Sick.
</p>
<p>
  Whether you need a cold start engine depends on your product range. If you are
  a men’s hiking apparel store, you have a niche of products and your users are
  likely to be men who like day trips in the mountains. You don’t need to refine
  the content the user sees.
</p>
<p>
  However, if your clothing store sells to women and men of all ages, across a
  range of fashions and functionalities, you might want to work out who is
  viewing your page so you can present them with items they might buy. In this
  case, your cold start engine might be a dozen pictures of men and women in
  different clothing. By asking your new user to click on the picture that
  matches their style, you can find out in one click that your new, unique site
  visitor is a teenage girl who likes a sporty style.
</p>
<p>
  Of course, you can quickly find out the same information as the user starts
  browsing, but one click might be the difference between a satisfied customer
  and a bored browser, so it is worth it if you have a wide customer demographic
  and a large product range.
</p>


When Is It Necessary to Implement a Cold-Start Engine?

<h2>How to Measure Recommendation System Effectiveness?</h2>

<p>The bottom line is always the bottom line. If your Recommendation System is working, you will see a growth in sales. However, if we assume that a 1% growth in sales is a significant change, how do we know that the success is down to our Recommendation System and not our marketing, or product trends, or the failures of our competitors? If we are investing in something, we need to know that it works and is worth pouring more resources into.</p><p>The answer, A/B testing, is also a key, standard feature of our upcoming Saleor Cloud solution. By creating 2 different versions of our store — one which utilizes our Recommendation System and one which does not — different customers see different versions of the storefront and we are able to observe which is more effective, both in general and for sales of specific products.</p><p>Essentially, we use hard data to check if our data-driven recommendations are working. Is there really any other way?</p>

<h2>Find Out More Insights into Building a Recommendation System</h2>

<p>This article is part of a series. For more insights about building a recommendations system, read also:</p><ul><li><a href="https://mirumee.com/blog/building-python-recommendation-systems-that-work?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_everything_need_know_before_building_recomm_syst_bottom" rel="noopener noreferrer" target="_blank">Building Python Recommendation Systems that Work</a></li><li><a href="https://blog.mirumee.com/the-difference-between-implicit-and-explicit-data-for-business-351f70ff3fbf?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_everything_need_know_before_building_recomm_syst" rel="noopener noreferrer" target="_blank">The Difference Between Implicit and Explicit Data for Business</a></li><li><br></li><li><span style="font-size: 20px;">If you are thinking about building a Recommendation System for your e-commerce, feel free to&nbsp;</span><a href="https://mirumee.typeform.com/to/mx7ayh3F?typeform-source=mirumee.com" rel="noopener noreferrer" target="_blank" style="font-size: 20px;">get in touch and speak to us about your project</a><span style="font-size: 20px;">.</span></li></ul>

<p><em>Mirumee guides clients through their digital transformation by providing a wide range of services from design and architecture, through business process automation to machine learning. We tailor services to the needs of organizations as diverse as governments and disruptive innovators on the ‘Forbes 30 Under 30’ list. Find out more by visiting our </em><a href="https://mirumee.com/services/?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_everything_need_know_before_building_recomm_syst" rel="noopener noreferrer" target="_blank"><em>services page</em></a><em>.</em></p>

Everything You Need to Know Before Building a Recommendation System

I could simply tell you it was a computer language designed by Facebook, and I wouldn’t be lying, but you could find out just as much by reading its Wikipedia entry. To understand the importance of GraphQL it’s crucial to look at it in the right context.

<h2>Evolution of Templating in Web Development</h2>

<p>As the applications we rely on become more and more complex, the desire to separate how they work from how they look grows stronger. Years ago, and I mean years ago (in the 1990s), it was common for each platform to take care of its backend and also render all of its user-visible interface. This was the simplest solution, although customization quickly became a challenge. Modifying the appearance directly in the code meant that the application could no longer be easily upgraded, so various templating solutions were devised.</p><p>Some systems opted for templates to be written in the same programming language that the surrounding platform used. This is how Wordpress-based systems work to this day, with the template being the main logic loop. It mixes the code responsible for drawing the user interface (HTML) with logic that fetches data from the database and executes all the required plugins.</p><p>Others chose to utilize domain-specific languages (special languages created to solve a particular problem) to describe the looks, the platform would then interpret them when rendering a response. Chances are this is how your Magento-based store is styled today.</p><p>The first approach has the downside that programmers who modify the template need to be full-stack developers, with a strong grasp of both the backend logic (including its language of choice) and the languages used to build the interface (eg. HTML, CSS, JavaScript). As the template itself acts as the main logic loop it inadvertently affects business logic, while modifying the looks becomes a risk that you need to specifically test against. The page might look as it should, but what if the programmer forgot to include the call to your tax service?</p><p>The latter approach means that your frontend engineers would likely need to learn a new language and that a large chunk of their knowledge is going to be specific to the platform itself. While breaking business logic becomes much more difficult, at some point your organization is starting to hire Magento theme developers instead of frontend engineers. A potential candidate’s vast knowledge of modern frontend frameworks is going to be irrelevant unless they learn how to create a theme for the platform.</p>

<p>For two pieces of software to be able to talk to each other, they need to know how to exchange information, and how to interpret any data the other party might choose to send their way. There are standards that describe particular use cases, languages, and protocols that dictate how programs talk to each other.</p><p>Usually, the party with an established address is called the server and the party that connects to it is referred to as the client. For communication to begin, the client has to reach out (connect) to the server. Think of it like a hungry patron entering a restaurant; there’s simply no way for a server to know the whereabouts of all the hungry people in town.</p><p>A communication standard meant for programmatic consumption is called an application programming interface (an API) and an address of a server implementing said standard is called an API endpoint. When a web browser connects to a web server, it’s using its HTTP (the Hypertext Transfer Protocol that powers the web) API by connecting to its HTTP endpoint located at the address you provided in the address bar.</p>

<h2>The Rise of AJAX and Its Impact on Web Applications</h2>

<p>Both mentioned templating solutions have their individual limitations beyond the ones listed above, yet the most glaring shortcoming is that they were developed in times where everything was rendered by the server. If every action of the user is taking a round-trip to the server, there’s no way to support offline mode. If every interaction requires the entire page to be redrawn, how do we implement a live search of a catalogue of five million products?</p><p>That’s how we arrived at hybrid solutions where most of the layout would be rendered by the server, but another — <em>asynchronous</em> — method allows the user interface to fetch additional data as needed. That’s where AJAX (asynchronous JavaScript and XML) first appeared. While AJAX was more of a concept than a standard, it proposed a way to fetch snippets of HTML (or XML if you insisted on staying true to its name) then add them to the page that was already rendered.</p><p>AJAX made new kinds of website elements possible to implement, but since there was no standardized way to do it, developers from different companies (and sometimes from different rooms in the same office) had very different opinions on how everything should work. Eventually, server-to-server communication was largely standardized around a specification named <em>Simple Object Access Protocol</em> (SOAP), while browser-to-server communication chose <em>Representational State Transfer</em> (REST).</p>

<h2>Comparing SOAP and REST: Resources vs Procedures</h2>

<div>SOAP and REST each use a very different approach to interface design.</div><div><br></div><div>SOAP is a Remote Procedure Call (RPC) mechanism. It offers a list of predefined operations; the “procedures”, with each procedure accepting a predefined number of parameters, and returning a number of named values of predefined types. A hypothetical addition procedure might accept two parameters, a and b, of type number and return a single value named sum, also of type number.</div><div><br></div><div>REST is an API revolving around resources. Each resource represents either a single entity or a collection of entities of a particular kind. Every resource supports a number of operations that can be: created, read, updated, and deleted. A hypothetical books resource collection might contain a single resource representing The Little Prince by Antoine de Saint-Exupéry. We could then update it with the year of publication, an International Standard Book Number, and later ask for the resource to have the information sent back to us.</div>

<h2>The Emergence of Single-Page Applications (SPAs)</h2>

<p>
  Building dynamic interfaces with AJAX was a pain. This was because the code to
  draw the same parts of the user interface had to live both on the server- and
  client-side; the first version would be generated by the server and sent to
  the browser. Then, as the user interacted with the page, certain parts would
  need to be redrawn by the JavaScript code running in the browser. Whenever
  visual changes were made, they would have to be made in both places,
  potentially requiring different types of talent for each part. This is hardly
  an ideal solution.
</p>
<p>
  Recent years gave rise to a new type of frontend frameworks, ones where the
  entire application is rendered by JavaScript in the browser. The server no
  longer needs to prepare the initial version of the page as the so-called
  <em>single-page applications</em> (SPA, named after the fact that the entire
  navigation happens without leaving the application) only use the server to
  fetch the necessary facts about objects, not the page layout.
</p>
<p>
  Applications written in React, Vue.js or Angular have no use of whichever
  outdated template solution was implemented by the server. The architecture of
  headless servers (as the servers no longer have a user interface) with rich
  clients allows frontend engineers to build the entire user experience using
  technologies they’re familiar with, and in languages of their choice. Updating
  the text on your <em>about</em> page no longer requires a backend developer,
  but as everything becomes API-driven, the architecture choices behind the API
  become the limiting factor of the team’s performance.
</p>
<p>
  SOAP did a lot of things right, but in doing so, it mandated a very complex
  representation for any information transferred, which in turn made it
  difficult to work with for JavaScript programmers. REST’s insistence on
  dealing with object states instead of state transitions means there is no
  obvious way to represent abstract concepts that don’t directly map to tangible
  objects.
</p>
<p>
  To understand the limitations of REST, imagine an API representing the apples
  I hold. Every time one of my friends uses the application to claim one of my
  apples, I want to decrease the number of apples available.
</p>
<p>
  A naive solution would be to introduce a ‘<em>me</em>’ resource with a field
  holding the current number of apples at hand. However, since reading and
  writing are distinct operations, there is no safe way of decreasing the number
  by one without risking what’s called a <em>race condition</em>: the case where
  two clients read a value and then both try to subsequently modify it, each
  oblivious to the other’s actions. Assuming there are 5 apples to start with,
  both clients would read the number 5 and then issue an update, both setting
  the number to 4.
</p>
<p>
  In reality, you need to work around this by either introducing an explicit
  resource for each apple or a resource for each
  <em>act of taking an apple</em>, even though the latter is an abstract concept
  that does not represent a tangible object. If you tried to implement the
  hypothetical <em>addition</em> procedure example given earlier, you’d face
  similar issues. Real-world application logic is full of atomic operations and
  state transitions where the client simply can’t be trusted with determining
  the resulting state, either because of possible race conditions, or because of
  business or even legal constraints, and this is where — unfortunately — the
  create/read/update/delete mantra of REST falls flat.
</p>
<p>
  There is another limitation common to both REST and SOAP. We’ve celebrated the
  fact that single-page applications mean no longer having to update the server
  each time the client is modified. However, as the exact set of fields returned
  by the server is controlled by the server itself, when we need to display
  additional data we face a choice to make: either modify the server to send
  more fields or issue an additional request to the server. A server returning
  more fields could mean that in the most common cases we’re sending over data
  that is not immediately useful to the client and we’re wasting network
  bandwidth. This is called <em>over-fetching</em>. Forcing the client to make
  an additional connection to the server in the few cases when more data is
  required means a longer waiting time for the end-user as each connection is a
  cost we pay in network latency (the time required for data to reach the server
  and return). This is called<em> under-fetching</em>.
</p>


<p>Finally, we are ready to understand what GraphQL really is. In short, it’s a computer language designed specifically to solve the problems of a modern web developer. It is also a collection of API specifications that describe how to speak GraphQL over HTTP, the protocol that web applications use.</p><p>While GraphQL is often compared to REST, in reality, it’s much closer to SOAP. It’s an RPC mechanism that offers a collection of named operations (SOAP calls them procedures, whereas GraphQL has queries, mutations, and subscriptions).</p><p>Unlike SOAP, it uses a simple data format to represent objects. For this reason, it’s very simple to deal with in JavaScript code.</p><p>Unlike REST, it revolves around named operations instead of resources. That makes it easy to implement scenarios that don’t map to tangible objects or that operate on multiple objects at the same time.</p><p>Unlike both SOAP and REST, it requires the client to specify the set of fields (including related objects) it expects in return. This deals with the problem of under- and over-fetching while maintaining forward compatibility.</p><p>Unlike REST, GraphQL comes with an introspection interface which means API endpoints are self-documenting. This was an issue SOAP eventually solved by distributing Web Services Description Language (WSDL) files, while REST awkwardly tries to solve the same issue by generating documentation pages that are often neither useful for human reading nor suitable for computers. The introspection mechanism interface gave life to a rich tooling ecosystem including automated ways to detect whether the client’s code refers to any API areas the server considers to be deprecated (prior to their actual removal).</p><p>Given that GraphQL separates its protocol specification from its transport specifications, it’s possible for an application to use the same GraphQL engine for both resolving queries sent by web clients and for executing queries internally within the application, thus becoming the single data-access mechanism for all business logic.</p><p>Given all of its technological advancements and the standard now being governed by its own GraphQL Foundation, operating under the Linux Foundation, don’t allow anyone cajole you into thinking that GraphQL is nothing more than a passing fad, or just some hyperbole peddled by Facebook engineers who don’t understand REST.</p>

<h2>Engaging with the GraphQL Community</h2>

<p>In conclusion, GraphQL has emerged as a powerful tool for modern web development, addressing many limitations of traditional REST APIs. Its flexibility and efficiency have made it a popular choice among developers. For a deeper dive into the community and advancements of GraphQL, check out our detailed experiences from the <a href="https://mirumee.com/blog/graphql-meetup-1-a-great-beginning?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_what_is_graphql" rel="noopener noreferrer" target="_blank">GraphQL Meetup #1: A Great Beginning</a> and <a href="https://mirumee.com/blog/graphql-summit-2018-san-francisco?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_what_is_graphql" rel="noopener noreferrer" target="_blank">GraphQL Summit 2018 in San Francisco</a>, where we explored cutting-edge developments and networked with industry leaders.</p>

<p><em>Mirumee guides clients through their digital transformation by providing a wide range of services from design and architecture, through business process automation, to machine learning. We tailor services to the needs of organizations as diverse as governments and disruptive innovators on the ‘Forbes 30 Under 30’ list. Find out more by visiting our </em><a href="https://mirumee.com/services/?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_what_is_graphql" rel="noopener noreferrer" target="_blank"><em>services page</em></a><em>.</em></p><p><br></p><p><em>Originally published at </em><a href="https://saleor.io/" rel="noopener noreferrer" target="_blank"><em>Saleor.io</em></a><em>, </em><a href="https://saleor.io/blog/what-is-graphql-137/" rel="noopener noreferrer" target="_blank"><em>What is GraphQL?</em></a></p>

What is GraphQL?

Discover how hybrid recommendations, combining user data with product attributes, effectively solve the cold-start problem. This approach ensures personalized suggestions for both new users and products.

<p>In our recent series of blog posts on recommendation systems, we covered the basic concept and gave some examples of what happens behind the scenes. If you're curious about how these systems work, you'll find these posts quite interesting:</p><ul><li><a href="https://mirumee.com/blog/everything-you-need-to-know-before-building-a-recommendation-system?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_cold_start_problem_how_to_deal" rel="noopener noreferrer" target="_blank">Everything You Need to Know Before Building a Recommendation System</a></li><li><a href="https://mirumee.com/blog/building-python-recommendation-systems-that-work?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_cold_start_problem_how_to_deal" rel="noopener noreferrer" target="_blank">Building Python Recommendation Systems that Work</a></li><li><a href="https://mirumee.com/blog/the-difference-between-implicit-and-explicit-data-for-business?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_cold_start_problem_how_to_deal" rel="noopener noreferrer" target="_blank">The Difference Between Implicit and Explicit Data for Business</a></li></ul><p>This time around, let’s consider a more practical, albeit hypothetical, scenario taken from the e-commerce sector.</p>

<h2>Addressing the Cold-Start Problem and Hybrid Recommendations</h2>

<p>Let’s assume that we already have a specific customer base for our online-store and a set product base in which all products have already been ordered. Some products are best-sellers, some of them sell averagely and some products that sell poorly. Our recommendation system would perform quite well under such conditions, as it is designed to take into account the interaction between user behavior, the online shop and its products.</p><p>At some point we would need to refresh our product range, adding new products which only partly relate to the previous best-sellers or ones that sold averagely well. After a while, despite the apparent similarities to existing products, we may notice the recommendation system failing to recommend the new range, leading to these products selling poorly or not at all.</p><p>In machine learning terminology we call such behavior of simple recommendation systems a cold-start problem.</p>

<h2>Is It Worth Worrying About Cold-Start Problems?</h2>

<p>The answer is a definitive yes. When the recommendation system is directly related to your revenue and business, you should pay attention to its possible shortcomings.</p><p>As with the example above, when launching a brand new product line the desired behavior of a recommendation system would be to recommend to the user relevant products from the new line, as well as other suitably matched products, to provide more exposure and visibility; herein lies the problem.</p><p>With a simple recommendation system, the cold-start problem will make it impossible to promote them as valid recommendations. According to the collaborative filtering concept, the recommendation engine will always rate popular products higher than new products, regardless of a user’s interaction or preferences. Typically, products with higher visibility sell better than products which are hardly ever recommended.</p><p>That leads to the situation of falling into a loop where the recommendation system promotes products that are already popular, and often those that do not suit the user. A similar mechanism occurs for new users who have not bought anything yet. The above scenarios can be called <em>product cold-start</em> and <em>user cold-start</em>.</p>

<h2>What Can Minimize the Effects of Cold-Start Problems?</h2>

<p>Before we start looking for a solution to the problem, it’s worth initially looking into what is causing it. As previously outlined, a cold start occurs when we introduce new products or new users appear. We may consider the main reason to be that it is difficult for us to find a point of reference from other products and users.</p>

<h3>The Basics of Recommendation Systems</h3>

<p>Simple recommendation systems make use of interaction data by capturing which user bought which products. In reality, we also have information about who our users are (their age, location and so on) and product data (category, description, or any other attribute). Leveraging this data allows us to find similarities between users and products (example below).</p><p>In general, recommendation systems that are able to combine different approaches are called hybrids. The combination of external features which describe products and users, together with any implementation of matrix factorization, perfectly fits the hybrid recommendation algorithms group.</p>

<p>Let’s begin with the data that is related to the product. Products can be assigned to specific categories, collections, descriptions or product-specific characteristics such as size, model or color. Taking such characteristics into account should allow us to get an idea of what the new product is, and how it relates to the well-selling products already on offer.</p>

<p style="font-family: __neueHasGrotesk_615dff, __neueHasGrotesk_Fallback_615dff, sans-serif; letter-spacing: 0.5px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 450; font-size: 20px; color: rgb(24, 24, 24); text-align: start;"><span style="line-height: 30px; letter-spacing: inherit; font-style: inherit; font-weight: inherit; font-size: inherit; color: inherit; text-align: inherit;">Obtaining data for products is relatively easy, but things get a little more complicated when attempting to gather data for improving user features. First of all, this is information that users have to leave in the system as they use the platform. This means the data may have different levels of completeness depending on how much the user has left. Examples of such data can be: user location; login frequency; previously logged in; typical amounts spent; etc. It gets slightly more complicated when we try to collect behavioral information such as: products viewed; type of device; length of time browsing a products details page; average session duration; etc.</span><br></p><span style="font-family: __neueHasGrotesk_615dff, __neueHasGrotesk_Fallback_615dff, sans-serif; font-size: 20px; font-variant-ligatures: normal; font-variant-caps: normal;">Naturally, the more different types of data we have, the more choice we have when constructing the proposed solutions; which consequently leads to better recommendation results. One very smart example is the LightFM model, presented by Maciej Kula, which combines any additional numeric type features with matrix factorization methods in a very intuitive and simple way.</span>

<h2>Hybrid Recommendations vs. Collaborative Filtering</h2>

<p>To illustrate the differences between the two methods of recommendation, we can show some educational examples below. Of course, these are based on simple examples, so it should not be taken literally.</p><p>We have an online shop which currently has several products on offer. Today we have released a new product (let’s say it’s a Saleor t-shirt). In theory, this could be a fragment of our product list.</p>

Hybrid Recommendations vs. Collaborative Filtering

<p>Based on the above example, we can see some product similarities through their attributes, e.g. product 1, 3, and 5 are similar by their color attribute; products 2 and 3 by their category attribute; products 1 and 3 by color and collection simultaneously.</p><p>Let’s now take a look at the table below. It should be interpreted that when the value for the user-product pair is 1, it means that the product has already been bought. If it is 0, it means that the user has not (yet) bought the product.</p>

<p>On the basis of the above tables, we will try to analyze what might the recommendations be for Caitlyn using the CF and hybrid models. The model based solely on collaborative filtering will likely propose Caitlyn jeans. This is because Caitlyn bought saleor-socks, just like Tom and Ben; Tom and Ben also bought jeans. Sunglasses would likely be proposed in second place based on Tom’s other purchase. And lastly, the Saleor t-shirt, as no one has bought it yet.</p>

<h3>How the Hybrid Model Enhances Recommendation Accuracy</h3>

<p>The hybrid model will consider the problem of recommendation in two ways.</p><p>First of all, Caitlyn’s preferences based on her choices will be checked — in this case, we see that so far she has bought purple socks branded by Saleor and a random white t-shirt. With this info, the preferred products in order of preference would be those that meet more of these tastes(values) — in order of similarity, it would be: a Saleor t-shirt (2 of its features coincide with those of the socks and 1 coincides with a white t-shirt), then sunglasses (the color coincides with the color of the socks), and finally the jeans (they have no features in common with Caitlyn’s purchases).</p><p>Secondly, the model will attempt to replicate the user’s taste according to the behavior of the CF-based model presented earlier. The next step is to mix CF-based information with information based on the user’s taste preferences.</p><p>We can observe that both approaches have given completely different results. So what will the end result likely be? It is difficult to say because of how each unique hybrid model combines its data. It depends on the specific model case and its hyperparameters. It is worth noting that new, or not yet popular, products are still presented to the prospective customer, not simply ignored by the recommendation system.</p>

<h2>Hybrid Recommendations Solve Cold-Start Problems with Enhanced Product and User Data</h2>

<p>
  When a recommendation system is implemented with care and precision, it can be
  hugely beneficial for your e-commerce.
</p>
<p>
  Each type of recommendation system improves user experience, however, simple
  recommendation systems based solely on user interaction with products will
  likely fail when new products and users appear. Hybrid recommendation systems
  significantly reduce the possibility of cold-start problems thanks to
  additional information gathered that describes the properties of users and
  products.
</p>
<p>
  If you want to learn more about hybrid recommendation systems, these links
  provide more technical details:
</p>
<ul>
  <li>
    <a
      href="https://www.manning.com/books/practical-recommender-systems"
      rel="noopener noreferrer nofollow"
      target="_blank"
      >Practical Recommender Systems</a
    >
  </li>
  <li>
    <a
      href="https://towardsdatascience.com/creating-a-hybrid-content-collaborative-movie-recommender-using-deep-learning-cc8b431618af"
      rel="noopener noreferrer nofollow"
      target="_blank"
      >Collaborative Movie Recommender Using Deep Learning</a
    >
  </li>
  <li>
    <a
      href="https://arxiv.org/pdf/1507.08439.pdf"
      rel="noopener noreferrer nofollow"
      target="_blank"
      >LightFM</a
    >
  </li>
</ul>


Cold-Start Problem and How to Deal with It

On the face of it, it would seem that progressive web applications are simply static files and JS code that can be hosted similarly as static websites. In fact, PWAs provide many more benefits and thus require more elements that demand your attention when building and deploying such an application.

<p>I would like to present these aspects and demonstrate the possibility of how you can deploy a modern app to AWS, the right way.</p><p>In this article, you will learn how to deploy your modern PWA application on AWS using S3 for storing the content, CloudFront for distributing the application, and Lambdas functions for handling push-state URLs and server-side rendering. Also, we will explain what to look for in terms of how PWAs and CloudFront cache work.</p>

<h2>Why Choose AWS CloudFront for PWA Deployment?</h2>

<p>First of all, you may ask which service you should use in front of your app, and why choose CloudFront? In one of our previous blog post, we outlines <a href="https://mirumee.com/blog/improving-your-site-performance" rel="noopener noreferrer" target="_blank">the benefits of using a CDN like CloudFront, highlighting improved performance and scalability</a>.</p><p>But what else does it give us? CloudFront is a powerful tool, it allows associating special lambda functions called Lambda@Edge. They give us full control over how requests are handled under the hood and what is returned to the browser. We can use them to achieve attractive URLs without ending extensions and to provide pre-rendered HTML pages for search bots.</p><p>Lambda@Edge functions allow us to modify the request/response cycle during any of the following stages:</p><ul><li>After CloudFront receives a request from a viewer (viewer request)</li><li>Before CloudFront forwards the request to the origin (origin request)</li><li>After CloudFront receives the response from the origin (origin response)</li><li>Before CloudFront forwards the response to the viewer (viewer response)</li></ul>

Why Choose AWS CloudFront for PWA Deployment?

<div>As far as the CloudFront cache is concerned, the function marked as origin request is only executed if there is no data in the cache, while the viewer request function is always run.</div>

<h2>Implementing Server-Side Rendering (SSR)</h2>

<div>There is no doubt that your app should be easily indexable by many search engines since we want to allow as many people as possible to reach it. Unfortunately, some engines use pretty basic crawlers which are only capable of crawling static HTML sites, and in doing so, ignoring all javascript code. To deal with this situation we need to use server-side rendering. SSR is a method of providing a fully rendered page to the client.</div>

<div>The crawler makes a request to the CloudFront service and the latter forwards it to a third-party service, such as <a href="https://github.com/GoogleChrome/rendertron" rel="nofollow" target="_blank">Rendertron</a> or <a href="https://prerender.io/" rel="nofollow" target="_blank">prerender.io</a>, which generates a static HTML page. To increase load speed we should cache rendered pages and make sure that SSR is only used for search engine requests.</div>

Implementing Server-Side Rendering (SSR) Method

<p>CloudFront caches responses against the request headers it sends. It does not forward the user request’s User-Agent to the origin, therefore limiting the header’s data, hence decreasing the number of hits to the origin.</p><p>So how do we detect a crawler?</p><p>We still need to forward the User-Agent header to the origin, but we reduce the number of unique values.</p><p>Instead of the real value of this header, we will use our own value. We set it to SSR if the header matches any whitelisted search engines, otherwise, we simply set it to CloudFront. In doing this we only have two possible values of this header.</p>

<p>First of all, we need to add a User-Agent to the whitelisted headers in our CloudFront distribution.</p><p>We can do that via the AWS dashboard:</p><p>CloudFront Distributions &gt; &lt;your distribution&gt; Behaviors &gt; Edit &gt; Whitelist Headers &gt; Enter a custom header User-Agent &gt; Add Custom</p>

<h2>Enhancing SEO with Viewer Request Lambda Functions</h2>

<p>Since this function always runs with the client's request, it shouldn’t be necessary to call on any external services or resources.</p><p>Let’s write the first Lambda function to detect crawlers:</p>

<div>That’s it!</div><div><br></div><div>We now know which requests come from search engines. Now we are able to continue to the next step of pre-rendering the content for those requests.</div>

<h2>Dynamic Rendering with Rendertron for PWAs</h2>

<p>This dynamic rendering app was created to serve the correct content to any bot that does not render or execute JavaScript. Since it’s a standalone HTTP server, it’s easy to use and integrate with existing projects. There is a fully-functional demo service which is great for exploring this tool at the beginning. For production usage, consider using your own instance of this service.</p><p>The next step is to create a Lambda function which, depending on the user agent set, will return the original response or ask Rendertron for the static HTML page version and then send it back to the client.</p>

Dynamic Rendering with Rendertron for PWAs

<div>We are going to write a function that will be executed before CloudFront forwards the request to the origin.</div>

<h2>Deploying with AWS Cloud Development Kit (CDK)</h2>

<p>Now that we know how to properly configure CloudFront and what Lambda functions should contain, it’s time to connect all the pieces together and deploy our application. Instead of creating all required resources manually, we will automate this process using a great tool from AWS — Cloud Development Kit. It allows us to model our infrastructure and provision the app’s resources using, among other languages, JavaScript. It’s easy to prepare reusable modules divided into logical parts or larger, high-level app components that describe the entire app environment.</p><p>Here is a list of the AWS resources that we need to create our static application:</p><ul><li>S3 Bucket — for storing app content</li><li>Viewer request Lambda function — to detect crawlers and set request headers</li><li>Origin request Lambda function — to handle server-side rendering</li><li>Access Identity and Roles — to allow services access to collaborate</li></ul><p>Via the following URL, you can find ready-to-run code that will automatically build necessary resources for our app.</p><p>All that’s left is to go through the step-by-step instructions from this repo and upload the application’s content to the appropriate S3 bucket.</p><p>In the command output, you’ll see a dedicated CloudFront URL where your app will be accessible.</p>

<h2>Best Practices for SPA/PWA Deployment on AWS</h2>

<div>
  A solid understanding of the operation and mechanisms of the CloudFront
  service is key to launching a fast and efficient web application. Thanks to
  this and other AWS tools, such as CDK, we do not have to focus on the
  architecture or the deployment process. We only need to be concerned about
  what we are most interested in — the application we plan to run.
</div>


Deployment of SPA/PWA Applications in the Real World

As a developer, you may start a small project with a monolith architecture using one of the many well-known frameworks. That’s a good start because it allows you to prototype fast and quickly respond to business needs. It sounds like a startup, doesn’t it?

<p>You work on the project with your colleagues and it grows. The business is happy and has great plans for the project.</p><p>The problem with that is businesses don’t usually know anything about architecture. They shouldn’t necessarily need to — that’s your job!</p><p>Adding more and more functionalities doesn’t help the whole monolith architecture. You can try your best to keep the code neat and tidy but by adding new features to the project, it eventually becomes too much for the supposed-to-be small project.</p><p>Going forward, the decision has to be made to split the monolith into microservices. And that’s fine, everyone is trending towards microservices these days.</p>

<p><a href="https://grpc.io/" rel="noopener noreferrer" target="_blank">gRPC is an open-source, modern, high performance framework </a>that was designed by Google to connect its data centers over a decade ago.</p><p>It’s okay if you don’t have data centers — you can use them to communicate with any services. Not only microservices, but also mobile, web, IoT, or even libraries.</p><p>By design, it is fast, compact, and scalable. It is language-agnostic, which means you can easily connect services written in different languages. All you need are defined procedures and messages for services. The rest, like implementations of clients, servers, and serialized data you get for free. They are generated by the gRPC scripts for your languages of choice. You just need to utilize them and implement what they are doing.</p><p>So, are we making contracts between clients and servers like in GraphQL, and no other communications are allowed? Pretty much! We are defining beforehand exactly what your services are offering and the exact messages for the communications. You don’t have to construct many REST endpoints, we just call a direct method on the client side. Sounds great, right?</p><p>Let me show you some other cool stuff.</p>

<p>Let me introduce you to some of the benefits of gRPC. In the next part, I will explore why gRPC stands out as a powerful framework for modern applications, emphasizing its efficiency, versatility, and performance. Whether you're new to gRPC or looking to deepen your understanding, I will provide valuable insights into its key advantages and practical applications.</p>

<div>So, as mentioned before, a Remote Procedure Call looks like a standard method to a developer, but underneath it’s calling a different service to do something and return the response. Code examples are best to illustrate the basic concepts — a basic example could look like this:</div>

<p>Let me explain step by step what we are doing here.</p><p>As you can see from the first line, this is a proto3 file. This format is used for defining methods and serializing messages. More on that subject later.</p><p>Next, we have the service definition UserStore. Let’s assume this is the service that holds all the information of our users. For now, we have only one unary (request -&gt; response) RPC method which is called GetUserDataByEmail. It expects a request message UserEmailRequest and will return the message UserResponse.</p><p>Ok, so far so good. You can also see that we can build more complex messages with it. Like the UserResponse is defining one of the fields as a User message. That’s correct, this is a feature of a protobuf which is quite powerful and is a whole other topic.</p><p>So we have definitions. What next?</p><p>Now we need to somehow access this RPC method in our application. To do that, we use a protocol buffer compiler to generate code for clients and servers. It might look like this:</p>

<p>As I said before, gRPC is language agnostic and offers tools for almost every popular language. This one is for Python. You will need to generate this for each language that you use.</p><p>This compiler will generate two files for python:</p><ul><li><code>user_store_pb2.py </code>— which contains generated classes for request and response messages</li><li><code>user_store_pb2_grpc.py </code>— which contains generated client and server classes.</li></ul><p>All you need to do now is import and use them — like this:</p><p><em>Client</em>:</p>

<p>So far, this looks fairly easy — but why do we use protobufs? (here’s the next great thing) you don’t have to!</p><p>gRPC was designed to be not only language agnostic, but also encoding! gRPC is not a monolithic framework. You can swap out some things if you want. You can use JSON or XML for messaging if you prefer. Meanwhile, let me inform you of the benefits of using protobufs.</p><p>They are compact. Especially in comparison to JSON or XML, they’re really compact. Let’s compare how many bytes will be needed for the same information for those three data types.</p>

Embed

<p>If you are sending IDs only, this makes a huge difference.</p><p>But size is not the only thing. Protobufs have many features that are beneficial. To name a few:</p><ul><li>Protobuf fields may be marked as deprecated. This will greatly improve the way of working with multiple teams or services.</li></ul>

<ul><li>You can define enums and use them as possible values for fields. Or even map all messages to the JSON if you need.</li><li>Built-in serialization</li><li>Typing</li></ul><p>And many more.</p><p>One important thing to remember! In Protobuf3 (the latest one), every field in the message is optional. This means you don’t always have to populate all defined fields. They will receive default values set to them like empty strings, e.g., 0, False, or so.</p><p>This is important considering the older version, Protobuf2, was the exact opposite. You needed to mark each field as ‘optional’ if needed.</p><p>You can find more on protobufs here.</p>

<div>All this sounds fine, but our example, GetUserDataByEmail, looks like a synchronous call. We send a request and we wait for a response. This is correct. But it doesn’t mean that it is synchronous only. It can be used asynchronously if you want. This is closely connected to the language you are using but is possible.</div>

<p>Are there other possible communication types other than unary request -&gt; response?</p><p>In short, yes. We have everything you might need.</p>

<div>This one we already know. The client sends a request and waits for a response. Basic stuff.</div>

<div>This is more complex but also well known. The client sends a request and in return gets a stream of messages. Useful if you are writing an application and want some progress bars for actions, e.g., streaming music or video.</div>

<div>Same as before but from the client side. The client sends a stream of messages to the server.</div>

<div>This is new — you can now define the bidirectional communication of streams. They are independent of each other so the client and server can send messages in any order.</div>

<p>Like any other communication system, you can define a timeout for responses. This is also independent of clients and servers. You can define it according to your needs. You can even cancel and RPC at any time. Keep in mind that this will not roll back anything and this feature needs to be implemented by you in the application itself.</p><p>But how is that possible, I hear you ask? What kind of sorcery is that?</p><p>Well, it’s not sorcery for sure!</p><p>Underneath, gRPC is using the newer HTTP2 transfer protocol instead of using the previous HTTP1.1. Thanks to HTTP2, we can send binaries instead of text (HTTP1.1) to support the handling of multiple requests at the same time. This standard is still new; you can find more in <a href="https://web.dev/articles/performance-http2" rel="noopener noreferrer" target="_blank">Introduction to HTTP/2</a>.</p>

<h2><strong>Things You May Not Like about gRPC</strong></h2>

<div>Everything comes at a cost and we were waiting for that!</div><div><br></div><div>Unfortunately, as with many solutions, this also has some cons that you should be aware of.</div>

<div>gRPC is widely used by many large companies such as Netflix, Spotify, and Cisco but is still quite new for most developers. You may spend some time looking for best practices, learning about protobufs, or searching for examples or workarounds. However, this is changing and more and more information is becoming available.</div>

<div>Early-stage tech normally means that the tools for it are even younger. Although a lot has been done already, you don’t really need them, but here is an <a href="https://github.com/grpc-ecosystem/awesome-grpc" rel="nofollow" target="_blank">awesome gRPC list on GitHub </a>anyway.</div>

<div>Its biggest advantage is also its biggest flaw. It’s hard to debug a message when you need to decode it first. There are tools for that, but you need to learn how to use them first.</div>

<div>It is coming, but not there yet.</div>

m-zine

Schema-First GraphQL: The Road Less Travelled

Improving Your Site Performance with CDN and Caching

Building Python Recommendation Systems that Work

Everything You Need to Know Before Building a Recommendation System

What is GraphQL?

Cold-Start Problem and How to Deal with It

Deployment of SPA/PWA Applications in the Real World

Why You Should Consider gRPC

Visual Studio Code — Quick Bits

How does a QA bite into a QA-less project?

Let’s engineer great products and systems together