ArticleIntroductionText

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.

Text

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

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.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.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.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?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.

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.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.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.

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

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?That’s how we arrived at hybrid solutions where most of the layout would be rendered by the server, but another — asynchronous — 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.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 Simple Object Access Protocol (SOAP), while browser-to-server communication chose Representational State Transfer (REST).

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

<div>SOAP and REST each use a very different approach to interface design.</div><div> </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> </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>

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.


 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
 single-page applications (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.


 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 about 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.


 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.


 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.


 A naive solution would be to introduce a ‘me’ 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 race condition: 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.


 In reality, you need to work around this by either introducing an explicit
 resource for each apple or a resource for each
 act of taking an apple, even though the latter is an abstract concept
 that does not represent a tangible object. If you tried to implement the
 hypothetical addition 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.


 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 over-fetching. 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 under-fetching.

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.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).Unlike SOAP, it uses a simple data format to represent objects. For this reason, it’s very simple to deal with in JavaScript code.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.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.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).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.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.

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

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.

DotsDivider

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 <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">services page</a>. Originally published at <a href="https://saleor.io/" rel="noopener noreferrer" target="_blank">Saleor.io</a>, <a href="https://saleor.io/blog/what-is-graphql-137/" rel="noopener noreferrer" target="_blank">What is GraphQL?</a>

What is GraphQL?

As 2018 draws to a close, we look back on a transformative year at Mirumee Software. From pioneering advancements in e-commerce solutions to expanding our portfolio with innovative projects, this year has been a testament to our commitment to technological excellence and client success.

<h2>Up-and-Coming Technologies</h2>

Last week, we took a look forward to some of the wider <a href="https://mirumee.com/blog/whats-on-our-e-commerce-radar-in-2019?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_2018_year_tech_at_mirumee" rel="noopener noreferrer" target="_blank">trends we think will be influencing e-commerce in 2019</a>. It’s exciting guessing what comes next but, as Head of Technology at Mirumee, I want to take a glance back at the technologies and events that grabbed our attention in 2018.

While we started to adopt GraphQL in January 2017, it wasn’t until March 2018 that we decided that the technology was mature enough to finally lay REST to rest.Since then, our team has attended GraphQL Europe 2018 in Berlin and <a href="https://mirumee.com/blog/graphql-summit-2018-san-francisco?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_2018_year_tech_at_mirumee" rel="noopener noreferrer" target="_blank">theGraphQL Summit 2018 in San Francisco</a>.Any remaining doubt about picking the right tools was eradicated when we saw how both small, dedicated teams and some of the largest companies in the world, across a number of industries, are now getting on board.GraphQL has proven itself to be an outstanding technology. The querying protocol allows clients to share a single endpoint and precisely control the subset of data they receive. The client-side caching layer provided by Apollo means that all views are rendered instantly, even if only a partial response is initially available.The most important thing about GraphQL for me, however, is the RPC interface provided by mutations. REST is decent at mapping CRUD operations to HTTP request methods. Unfortunately, it turns out that not every operation is a CRUD operation, unless you’re willing to bend the definition and invent arbitrary resources. Mutations name the actual state transitions (think “start the espresso machine” or “cancel order”) and their arguments, while REST has the server figure out why a client is trying to change a shipment’s state to “cancelled” while simultaneously providing a package tracking code.<a href="https://getsaleor.com/" rel="noopener noreferrer" target="_blank">Saleor’s</a> API is now powered exclusively by GraphQL and the <a href="https://medium.com/saleor/saleor-2-0-release-graphql-first-headless-e-commerce-1330f2151585?source=post_page-----a4156872267c--------------------------------" rel="noopener noreferrer" target="_blank">proof-of-concept progressive web app</a> we’ve built to demonstrate its power is silky smooth.

We started to use TypeScript back in 2016 but, back then, it was still competing with Flow, and the type
 definitions and errors reported for React code left much to be desired. After TypeScript 2.0 shipped in late 2016,
 things got much better and the functionality quickly surpassed that of Flow.
In 2017 we switched two relatively large client-side applications to TypeScript and, after seeing positive results,
 we decided to fully embrace it in 2018. When we started designing <a rel="nofollow" target="_blank" href="https://medium.com/saleor/summer-release-of-saleor-dashboard-2-0-preview-14bbe69c0f58?source=post_page-----a4156872267c--------------------------------">Dashboard 2.0 for Saleor
 </a>, we knew that no other tool could give us the confidence to have the
 entire administration panel depend on such a fragile foundation as JavaScript.
 TypeScript 3 came in July and improved matters even further, most notably improving the cryptic error messages
 related to using complex types in React JSX. This made TypeScript a natural fit for the PWA storefront we built to
 demonstrate the possibilities of a modern e-commerce platform.
 The language can be a pain when dealing with poorly typed dependencies, and upgrading to a
 stricter version of the TypeScript compiler can reveal typing errors even in popular libraries.
 However, any lost time is gained back, with interest, thanks to the excellent auto-complete function and fewer hours
 spent debugging and making sure the refactoring you’re working on doesn’t change the application’s behavior.

Since GraphQL originated from Facebook, it felt natural to pair it with Facebook’s own Relay on the client side.
 However, our initial excitement at building a next generation API started to die down when we saw how much Relay
 relied on magic to deliver its functionality.
At the end of 2017, we finally made the switch to Apollo GraphQL and working with GraphQL has been a blast
 ever since. Apollo not only provides a great client implementation with modern React bindings, they’ve also
 managed to attract a very active community that has provided an abundance of libraries and extensions.
It would also be unfair of me to talk about Apollo without mentioning the great tools aimed at developers. Their
 TypeScript interfaces are usually a pleasure to work with, including automatic type generation based on the schema and
 whatever queries are used in code.
The cherry on top is the <a rel="nofollow" href="https://marketplace.visualstudio.com/items?itemName=apollographql.vscode-apollo&amp;source=post_page-----a4156872267c--------------------------------" target="_blank">Visual Studio Code plugin</a> that provides syntax highlighting, query validation, and auto-complete
 suggestions as you type.
We wanted to give something back as a thank-you for all it has given to us over the last year, so we taught it to speak Python.

Image

Up-and-Coming Technologies: Apollo GraphQL

We’re still not done with GraphQL. The second half of 2018 saw the first release of <a href="https://github.com/mirumee/ariadne?source=post_page-----a4156872267c--------------------------------" rel="noopener noreferrer" target="_blank">Ariadne</a>, our own alternative to Python’s de-facto standard GraphQL server — Graphene.<a href="https://mirumee.com/blog/ariadne-0-2-0-released?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_2018_year_tech_at_mirumee" rel="noopener noreferrer" target="_blank">Ariadne version 0.2.0</a> is fully asynchronous and we’re actively working on making it a first-class citizen in asynchronous web frameworks like Django Channels and Starlette.

We were initially skeptical about adopting <a href="https://storybook.js.org/" rel="noopener noreferrer nofollow" target="_blank">Storybook</a> but I can now say that it’s one of my favorite technical improvements of the last few years.
Complex views, such as order management screens, have so many possible UI states that it pains me to think about manually recreating each and every one to properly style the components.
Storybook makes it a breeze to describe all those UI states without running the entire application. Want to see how the page looks while loading data? You got it… no network throttling needed.
While the convenience of having instant access to all of your application’s UI is the major benefit of adopting an “artbook” system like Storybook, we also discovered that designing components with Storybook in mind often leads to a beautiful decoupling of function (containers) from looks (visual components). It gives us code that is easier to read and test.

Creating a full-time AI team was one huge benefit of nearly doubling our staff
 in 2018. While we’re still far from bringing our kitchen appliances to life
 (which will, no doubt, ultimately lead to the dreaded toaster uprising of
 2021), we already have some customers A/B-testing the performance of
 recommendation engines powered by both classic collective intelligence and
 neural network models trained on observed customer behavior.


 While the hardware necessary to train and evaluate machine learning
 models is still prohibitively expensive for many applications, we feel
 that this is a key area that commerce needs to explore in order to provide
 better online experiences.

2018 was a remarkable year for community engagement at Mirumee. We took part in and organized a variety of events that not only brought our team closer but also strengthened our ties with the local community.

<div><h3>Saleor Became the Fastest Growing E-Commerce Platform</h3></div>

Thanks to Saleor’s awesome community, it became the fastest growing project, as well as the #1 Python platform, on the open source e-commerce tracker <a target="_blank" rel="nofollow" href="https://www.ecommwar.com/">eCommWar</a>.

Saleor Became the Fastest Growing E-Commerce Platform

Year after year our engineers volunteer to teach programming at the
 <a rel="nofollow" target="_blank" href="https://djangogirls.org/">Django Girls</a> workshops in our hometown,
 Wrocław.

We love the Django Girls initiative. We try to help as a company by
 contributing illustration work, providing attendees with themed backpacks, and
 documenting the event
 <a rel="nofollow" target="_blank" href="https://www.facebook.com/DjangoGirlsWroclaw/videos/vb.330578143781914/338234503424529/">on video</a>.

<h3>Diversity and Women in Technology</h3>

We really care about diversity and we believe <a href="https://mirumee.com/blog/women-in-tech-and-science-why-hiring-female-coders-is-not-an-easy-task?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_2018_year_tech_at_mirumee" rel="noopener noreferrer" target="_blank">having variety within our team</a> is a huge benefit to both company culture and the quality of the products we offer.That’s why our team could not skip the <a href="https://mirumee.com/blog/taking-inspiration-from-the-european-women-in-tech-conference-in-amsterdam?source=post_page-----a4156872267c--------------------------------" rel="noopener noreferrer" target="_blank">European Women in Technology Conference in Amsterdam.</a>

Last but not least, since 2018 proved to be a year of GraphQL, we wanted to pass some of our experience back to the community. When we couldn’t find an existing GraphQL event, we decided to start out own. The first ever <a rel="nofollow" target="_blank" href="https://www.meetup.com/pl-PL/GraphQL-Wroclaw/?source=post_page-----a4156872267c--------------------------------">GraphQL Wrocław</a> group was set up on Meetup and our inaugural event attracted over 300 members within days of being announced. What a great start to 2019!

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 <a href="https://mirumee.com/services/?utm_campaign=article&amp;utm_medium=internal_link&amp;utm_source=art_2018_year_tech_at_mirumee" rel="noopener noreferrer" target="_blank">services page</a>.&nbsp;

m-zine

Author

Patryk Zawadzki

Articles

What is GraphQL?

2018: A Year in Technology at Mirumee Software

Author

Articles

Patryk Zawadzki

What is GraphQL?

2018: A Year in Technology at Mirumee Software

Let’s engineer great products and systems together