What are the most common challenges when building an e-commerce system on Shopify? Let's start with standard Shopify theme templates.
The fundamental and most significant issue is that Liquid is a template language, making it challenging to develop. Custom databases, complex logic, and third-party service requests are impossible. Furthermore, when developers think about frameworks like Ruby on Rails, or Django, Liquid is a View layer. The developer has no direct access to the controllers and models that have been predetermined.
The second issue is that the Liquid theme tightly couples your code to Shopify. You won't be able to reuse the code if you want to move to a different system. It inhibits companies from evolving because it makes e-commerce platforms the sole arbiter of success. When businesses must change the platform, they are forced to discard the entire system. Thousands of hours and hundreds of thousands of dollars may be lost as a result.
The third Liquid theme drawback restricts you to how and what you can develop. Do you want to create a single-page application? No. Perhaps a progressive web application? No. Is it possible to unit-test your markup? Again, no! Even custom URLs are not an option.
What about headless? The headless technique decouples the front end from the backend, allowing you to interact with third-party services and obtain data via API. The main advantage of headless is that the front end may not be aware of the e-commerce platform it uses. As a result, you can develop and integrate whatever you want and connect all the services you require.
When you utilize Shopify as an e-commerce component of the headless system, you may encounter several typical difficulties.
To begin with, you'll need additional hosting to hold your front end, which increases the cost over the themed option. In addition, another hosting fee will rise alongside traffic, despite Shopify's cost not being influenced by it. So the prices might be relatively high in some instances.
Another issue is server-side rendering. Because Shopify Storefront API has IP-based limits, it's simple to render whatever you want on the client's side, but e-commerce sites should render pages on the server so that Google can index them correctly. However, JAMStack tools such as Next.js or Gatsby effectively address this issue.
Finally, the last significant issue is Shopify Apps. We can't use the part of the ecosystem that utilizes themes if we don't use a Shopify Theme. It's not a problem but a design feature; if we want to be self-sufficient and utilize a headless system, we should expect not to use features that increase coupling. Instead, we may create any connection with any third-party system that provides API.
When comparing these two methods, we notice that both have their drawbacks. The most significant distinction is that, in the headless variation, the problems are conquerable at the cost of development resources. Still, the themed variant has no way to address fundamental issues. So let's describe how the new Hydrogen by Shopify addresses that problems.
Is Shopify Hydrogen right for your eCommerce? Take a quiz
Hydrogen is a framework that combines React Server Components, streaming server-side rendering with suspense, and intelligent caching settings. It's the quick framework for developers and customers when coupled with the Storefront API globally accessible across all Shopify stores, Shopify-optimized commerce components, and a Vite-powered development environment. Additionally, Oxygen is a global hosting solution for Hydrogen storefronts.
Shopify's 2021 event, Shopify Unite, saw the debut of Oxygen, a method to host Hydrogen stores directly on Shopify that is quick, works worldwide, and is designed for ecommerce.
The Oxygen Shopify server overcomes the hosting issue of a headless solution, which we've described above. In addition, by providing a global hosting solution, Shopify aims to eliminate one of the main drawbacks of using a headless system.
It's still early days for Hydrogen in 2022. The initial version was made available on November 6, 2021, and the framework has been improved numerous times.
The longer that Oxygen has not yet been live, and will be available by the end of 2022. It implies that headless hosting difficulties have not yet been resolved, and organizations that rely on Hydrogen still require a dedicated server. Unlike JAMStack platforms like Next.js or Gatsby, Hydrogen does not prerender HTML files and instead employs server-side rendering, so you cannot utilize a simple hosting platform like AWS S3. However, there should be a Node.JS server that can be more costly for the website to work correctly.
To summarize, the Hydrogen Shopify stack currently does not offer a solution for the headless hosting problem.
Hydrogen extends Shopify features and ideas with commerce components, hooks, and utilities. In addition, it delivers boilerplate code that you may use to create your own storefront, allowing you to focus on creating distinct experiences.
The Storefront API's GraphQL types are used to generate and optimize the data for hydrogen. The structure of the information supplied to components, hooks, and utilities is based on the GraphQL types from the Storefront API.
While the Storefront API allows you to create bespoke storefronts in any language and technology, Hydrogen is a tool that aims to speed up the development process.
In other words, the architecture of a hydrogen application is built on top of a development framework and UI components. The Vite plugin for the Hydrogen platform offers server-side rendering (SSR), hydration middleware, and client component code transformations. The components, hooks, and utilities of Hydrogen UI are meant to support Shopify features and ideas.
Like in Liquid theme creation, Hydrogen provides developers with a precise path to follow. But, on the other hand, it makes higher-level development simpler.
Instead of using Webpack, the Developer will utilize the Vite plugin as a development environment tool. However, it implies that developers won't be able to use Hydrogen in existing projects by adding another npm dependency. Therefore, hydrogen must serve as a focal point of the system.
This is exactly what we see in data-sourcing strategies. It's all about the same goal when Hydrogen aspires to be the system's core. The Storefront API serves as the data source for this project's Shopify-based storefront. The data structure supplied to components, hooks, and utilities follow and adhere to the Storefront API's GraphQL types. You can directly deliver data from the Storefront API into components, hooks, and utilities.
Hydrogen can also handle data from third-party sources, such as API-first CMSes like Prismic or Contentful, or even non-Shopify e-commerce systems. If you want to integrate Hydrogen components with a non-Shopify data source, you must first convert the data into the appropriate formats for the Hydrogen. In addition, an adapter must translate third-party data into the types expected by Hydrogen. If you opt to use a third-party data source, you may query it in your bespoke storefront software.
However, you may not use the Hydrogen framework Shopify's layer with other frameworks like Gatsby or Next.js. Hydrogen utilizes a modified version of server components that support context and SSR (server-side rendering), which is not yet available in Next.js' current version. Also, you can't utilize server-only Hydrogen GraphQL queries with Storefront API integrations that use other frameworks.
In other words, Hydrogen provides a straightforward method to construct a contemporary Shopify shop at the expense of technological independence and software modifiability restrictions. It implies a quicker start-up and time-to-market, as well as higher long-term costs when compared to others.
Shopify React Hydrogen commerce components, hooks, and utilities are available in various types to help you speed up development.
Routing and session management are included in the framework components and hooks offered with the Hydrogen.
The basic building blocks for different component kinds include products, variants, and carts, all based on primitive components. Metafields, money representations, and other elements are included in primitive components.
The global components, such as ShopifyProvider, surround the whole application. For example, the ShopifyProvider component is connected to the hooks used for data retrieval from server components. Global components and hooks aim to link the data layer with the user interface layer.
The product and variant components and hooks describe the goods, digital downloads, services, and gift cards that a business offers. For example, if a product has options, like size or color, merchants can add a variant for each combination of options. These components make it easy to create product pages or product blocks.
The cart components and hooks are related to the products that a client intends to get. Therefore, such elements allow for rapid implementation of a shopping cart.
Translating a product page into multiple languages and currencies is the job of localization components and hooks. The LocalizationProvider component is present in Hydrogen.
Metafield components and hooks link Shopify resources with specialized information, such as part numbers or release dates.
Hydrogen also provides several utilities to assist you in speeding up your development process.
Hydrogen, again, aspires to be the heart of the system at both the framework and component levels. The data is received in Shopify format, transmitted across layers in Shopify format, and then React components accept the data in Shopify format.
Is it possible to utilize Hydrogen to create headless storefronts? The unexpected answer is no.
Hydrogen is a wonderful tool for creating modern Shopify stores. It allows developers to construct a Shopify store with React and contemporary JS, makes it a Single Page Application or even a Progressive Web App, and gains more control over rendering, but it's still a Shopify shop. The headless system's major aim is to decouple the frontend from the backend, whereas Shopify's main idea is to maintain tight integration.
Each system is a third-party system for the headless backend, whether it is an e-commerce platform or not. Therefore, the frontend should be unaware of platform specifics. Instead, Hydrogen places itself and Shopify in the center of the system. It's not bad because it's still a valuable tool for rapid Shopify development. It is, however, not headless.
It's also a wise business decision for Shopify. While the headless design is vendor-agnostic and enables freedom from any platform, Shopify, as a corporation, strikes back by providing tools for fast and contemporary development to its clients while maintaining tight ties between them.
If Hydrogen was not designed to create headless shops, it implies that it is intended to take the place of Liquid. However, it solves most of the Liquid issues since it has both a backend and frontend, employs powerful JavaScript instead of a simple templating language, and controls rendering and routing. Therefore, the following steps for Shopify will likely be the development of a template catalog similar to the Shopify Theme Store.
On the other hand, Hydrogen has several drawbacks from the headless design. Shopify apps that utilize Liquid as a front-end will not function with Hydrogen. There's also the problem of hosting. There is a need for a dedicated server until Shopify Hydrogen Oxygen hosting is available.
Now it's clear Shopify Oxygen Hydrogen isn't a tool for building headless systems but rather a contemporary replacement for Liquid; let's talk about the concerns raised at the start.
Does hydrogen solve the Liquid problem of complex development? Definitely. Modern JavaScript is capable of addressing nearly all current ecommerce issues.
As we previously suggested, Hydrogen intends to be the system's heart, and it tightly couples the front-end to Shopify, as Liquid does. The connection is not as tight as it may be, but it's enough to prevent the front-end from being reused on other ecommerce platforms. As a result, the Liquid coupling problem is unaddressed; instead, it has been intentionally created.
Hydrogen still plays a significant role in deciding what and how to construct, but it allows for more flexibility than Liquid does. You can build your own routing and SPA/PWAs, but the developer has no control over the bundler, dev server, or other tools. As a result, this issue is somewhat addressed.
What are the difficulties of headless development? Oxygen overcomes the limitations associated with hosting, but it is not yet live in mid-2022. As a result, the issue remains, but it will be addressed over several months.
Finally, as with headless stores, Hydrogen suffers from the Shopify Apps issue. As a result, that problem has not been addressed.
Finally, although hydrogen solves some Liquid and headless issues, it also has its drawbacks. So when should companies switch to Hydrogen? Restricting the building procedure also avoids architectural blunders. Hydrogen developers must follow the directions, but headless system developers should be able to build the approach from scratch. So, in a nutshell: When Liquid is not enough, the development team has no prior expertise in creating headless systems and keeping the coupling low so that the system may be vendor-agnostic.
Also Published Here