DEV Community: Michael Bromley

Lightning Fast Headless Commerce with Vendure and Remix

Michael Bromley — Wed, 25 May 2022 11:43:03 +0000

Remix is a new full-stack JavaScript framework which focuses on web standards, modern web app UX,
and which promises to help you build better websites. In this post we'll explore how Remix is ideally suited to
headless commerce.

First of all, if you don't know the term "headless commerce", it just means e-commerce applications where the storefront communicates with the commerce backend via an API. Vendure is one such "headless" server - it deals with all the product, order & customer data and logic, and the storefront interacts with it via its GraphQL API.

I've been aware of Remix for a while, but it was only after reading
their blog post comparing Remix to Next.js that I really sat up and paid
attention. I soon discovered that it could be an ideal framework on which to build a headless commerce storefront:

it supports server-rendering by default
it ships minimal Javascript to the browser, keeping initial loads fast
it has native support for prefetching to speed up page loads
it encourages graceful error handling
it runs on edge servers (more on this later)

In fact, I was so impressed with what I saw that I decided to make Vendure
an official sponsor of the inaugural Remix Conf!

React made simple

As a React newbie, I wasn't sure what I was letting myself in for - I've dabbled with Next.js, but I'm not afraid to
admit that some of the more advanced uses of hooks still confuse me. I was really happy to discover that the whole
design of Remix meant I very rarely needed to reach for anything more complex than useState!

For the initial proof of concept I had the help of a React-savvy friend to get
things started, and after sharing my progress on Twitter I got
some invaluable tips from Kent from the Remix team (shout
out to Kent for his incredible work supporting and boosting the Remix community!)

After that I found I was able to move quickly, even with my limited React experience! The more notoriously complex
aspects of building a React app - wrangling build tools, dealing with state management libraries - seem to be completely
side-stepped by Remix's opinionated approach to the app-building experience.

Effortless server rendering

E-commerce is the archetypal example of the need for server-side rendering (SSR) of web applications. Why? Because
ensuring that search engine crawlers can read our pages is essential to driving traffic to our shop. Back in the early
days of JavaScript web apps, we had some interesting solutions to this problem - anyone else remember using headless
Chrome to crawl our sites and generate static HTML files? On the other hand, build-time static site generators like Gatsby can become difficult to scale to stores with hundreds or thousands of products.

Thankfully, most modern JS frameworks have some kind of built-in support for SSR. Remix is a great example of this. The
server and client code exists in the same file and passing data from the server to the client is a matter of returning
an object from the loader function.

Not only does this approach make your pages SEO-ready by default, it also allows you to limit the browser bundle to only that code strictly needed on the client. This can massively reduce the amount of JavaScript sent to the browser,
significantly reducing load times and speeding up the storefront experience.

Bye-bye client libraries

Since Remix is a full-stack framework, it is able to load data directly from a database rather than requiring an HTTP
API like most front end frameworks. I was curious to see how it would work with Vendure's GraphQL API as a data source.

I was very pleasantly surprised to find that it works really well! I would usually reach for a full-featured GraphQL
client with a normalized cache like Apollo Client or Urql, but by fully embracing the Remix way, plain old fetch
worked perfectly. The usual issues of client state getting out of sync (which I typically solved with a normalized
client cache) are solved by Remix's method of revalidating any data that might have changed.

Not only does this significantly simplify data handling, it also completely removes the need to ship any kind of
GraphQL client library to the browser!

Living on the Edge

Since a Remix app is both a server and a client application, we can't just host it like a simple static website. It
actually executes JavaScript when a new request comes in. So how do we host it?

One option is to run it as a traditional Express app. But due to the smart platform-agnostic design of Remix, it can run
in any Node.js server like Vercel,
Netlify or AWS Architect. Furthermore, it can run on non-Node.js platforms like Cloudflare Workers or Deno Deploy.

Cloudflare Workers is a particularly exciting technology - it allows you to run code
at "the edge" - which means a network of servers distributed all around the world. So if a customer in Sydney visits
your store, they will be served by a Cloudflare server right there in Sydney. Likewise in Vienna, Lagos, Seattle or any
of the 250+ locations worldwide. This can dramatically reduce the latency of requests, making your storefront lightning fast (as you'll see in the demo below!).

Show me!

Yes, the video above is in real-time!

The Vendure server is a default installation running on a $5 Digital Ocean droplet backed by SQLite. No special caching or performance tricks - just a completely vanilla install.

The Remix storefront is running on Cloudflare Pages. It feels like a static website, but it's fully dynamic.

The combination of Remix's performance-first design running at the edge really has to be seen to be believed. Try it for yourself! 👇

🛒 remix-storefront.vendure.io

👨‍💻 github.com/vendure-ecommerce/storefront-remix-starter

Special thanks to Edo Rivai for doing the initial work on the Remix storefront repo - your React expertise got me started in the right direction! Also thanks is due to Conor Burns & Timur Dogan of 0xcb.dev who first got it running on Cloudflare Pages 🙏.

Towards Vendure v2.0

Michael Bromley — Tue, 15 Mar 2022 21:19:00 +0000

Today sees the release of version 1.5 of Vendure, the open-source headless commerce framework. This release sees Vendure reach a point of high stability & maturity, with all major APIs completed and almost a year of bug fixes and refinements behind us.

Just 10 months after the v1.0 launch, Vendure is now being used in production in dozens of stores, from small boutique print shops to huge Europe-wide marketplaces to billion-dollar startups and yes, even giants like IBM.

With a active and growing community, Vendure is truly a mature, proven and production-ready headless commerce platform.

So what's next? Let's talk about the future. Let's talk about Vendure v2.0!

What's special about v2.0? Well, there are a number of changes and features I’d like to introduce which I cannot, since they would require breaking changes. I try my best to follow semantic versioning, which means that all v1.x.x releases should be backwards-compatible. In other words, updating the Vendure package versions should not require any changes to your existing code. So far we’ve done a pretty good job of this!

However, certain changes simply cannot be made without changing the database schema, updating dependent libraries with breaking API changes, or altering parts of the Vendure data model. Here are some examples of breaking changes which need to wait until v2.0:

Updating the underlying libraries that Vendure is built on to their latest versions, namely NestJS, GraphQL, Apollo Server & Angular.
Modifying the data model to support multiple stock locations.
Adding support for bundle products (allowing custom products to be assembled from disparate product variants)
Improving support for true multivendor marketplaces - this will be a major focus of the next version, since there is huge demand for it and there seems to be very few alternatives out there at present. If you are interested in this feature, I invite you to share ideas & feedback in this issue.
Removing deprecated APIs.

All of the above and more are planned for Vendure v2.0. You can see the status of these issues in our roadmap.

It is also possible to start testing these changes now by using the @next tag:

npm install @vendure/core@next

This will install a version like 2.0.0-next.1, which reflects the major branch of the Vendure repo. Changes in these pre-release versions can be found in the CHANGELOG_NEXT.md file. I’m using the @next version in my own Vendure projects, but the usual caveats about using pre-release software apply!

I have no set timeline for the release of v2.0, but I would expect it to be ready within the next six months 🤞.

Thanks for reading, and if you'd like to find out more about Vendure, head over to our Getting Started guide.

GraphQL Fundamentals: Hands-On

Michael Bromley — Mon, 17 Jan 2022 11:16:52 +0000

In this post we will explore some of the fundamental concepts of GraphQL in a hands-on way. The goal of this post is to allow the beginner to gain a familiarity with the basic features of GraphQL.

Setting up

The best way to learn is to do. So this tutorial will be light on theory and heavy on practical exercises.

So we'll need a real graphql server to play with. Let's use Vendure, an open-source GraphQL e-commerce framework. I chose Vendure because it is really easy to set up - all you need is to make sure you have Node.js installed. Plus I built it so I know the API quite well 😉

To install a local instance of Vendure, run:

npx @vendure/create my-shop

and follow the prompts. Select SQLite and use the defaults for all other prompts. Installation should take about 5 minutes and then you'll have a full, production-grade GraphQL server pre-populated with sample data ready to play with!

Once installation is complete, open up http://localhost:3000/shop-api in your browser.

Note: if you are unable to install Vendure locally for any reason (e.g. you are on a mobile device), you can still follow along with this article by using the public demo server at demo.vendure.io/shop-api.

You should see the GraphQL Playground - an interactive interface for working directly with the GraphQL server. This is what we'll be using for all the exercises on this article.

Your first query

GraphQL allows us to fetch data by sending queries. Queries are similar to GET requests in a REST API. Let's write our first query:

query {
  product(id: 1) {
    id
    name
  }
}

Copy this into the left pane of the playground and then press the play button. You should see the response in the right pane:

{
  "data": {
    "product": {
      "id": "1",
      "name": "Laptop"
    }
  }
}

Congratulations! You executed your first graphql operation!

What did we do here? Let's analyze each part of this.

query: First of all we are declaring that we are making a query. This is in contrast to a mutation (which we will cover below). Technically you can omit that query keyword, but we'll keep using it just to be more explicit.
product: Next we are specifying the query we wish to use: product. Each GraphQL server defines a set of possible queries. Since Vendure is an e-commerce server, it exposes queries related to products, orders, customers, etc.
id: 1: We then pass an argument to our query, specifying the ID of the product we want to return. You can think of this very much like a function call. Just like function calls, GraphQL queries can take zero, one or more arguments.
{ id, name }: We finally specify the fields we want to return. Fields are like properties on a JavaScript object. In this case, we want to know just the ID and name of the product.

Selecting fields

One of the big benefits of GraphQL over REST APIs is that you can specify the exact data you need, and the server will return those and only those fields. This means you can avoid sending too much data over the wire, leading to faster data transfer and lower bandwidth usage.

Let's try adding some more fields to our query. Add the slug and description fields to the selection, and press the play button. You should see that these two new fields are added to the result:

{
  "data": {
    "product": {
      "id": "1",
      "name": "Laptop",
      "slug": "laptop",
      "description": "Now equipped with seventh-generation Intel Core processors, ..."
    }
  }
}

Now let's try an experiment: what happens if we add a field to our selection that does not actually exist on our product. Try adding the field age, and you'll get the following result:

{
  "error": {
    "errors": [
      {
        "message": "Cannot query field \"age\" on type \"Product\". Did you mean \"name\"?",
        "locations": [
          {
            "line": 7,
            "column": 5
          }
        ]
      }
    ]
  }
}

Schema & Types

This highlights another important property of GraphQL: it is statically typed. That is to say, the exact fields available, and the types of data they can hold (strings, numbers, dates etc.) are explicitly defined in a schema. The schema, in fact, defines all available queries and mutations, and the exact type of objects they can return.

This is an extremely powerful property of GraphQL and allows things like auto-complete and automatic validation of data you send to the server.

You have already seen the auto-complete as you typed the field names above. You can also see all available fields on a given object by pressing ctrl + space:

At the bottom of the auto-complete popup, in orange text, you'll see the type of that field. GraphQL types are analogous to primitives in JavaScript, String, Boolean, Int, Float & ID. In GraphQL these are known as scalar types.

When a field represents a more complex data type, GraphQL supports object types. In fact, we've been working with an object type all along - the Product object! That's right, queries themselves have a type. In this case, the product query has the type Product.

📖 Reference: graphql.org Scalar Types, graphql.org Object Types

Nested Objects

Another of the major benefits of GraphQL is that a single query allows you to fetch an object plus nested relations. What would require several individual http requests using a REST API can be achieved in a single GraphQL query.

To illustrate that, let's update our query to select all the variants of our Laptop product:

query {
  product(id: 1) {
    id
    name
    slug
    description
    variants {
      name
      sku
      price
    } 
  }
}

Now when we run this, we'll get the requested fields on each of the laptop variants:

{
  "data": {
    "product": {
      "id": "1",
      "name": "Laptop",
      "slug": "laptop",
      "description": "Now equipped with seventh-generation Intel Core processors, ...",
      "variants": [
        {
          "name": "Laptop 13 inch 8GB",
          "sku": "L2201308",
          "price": 129900
        },
        {
          "name": "Laptop 15 inch 8GB",
          "sku": "L2201508",
          "price": 139900
        },
        {
          "name": "Laptop 13 inch 16GB",
          "sku": "L2201316",
          "price": 219900
        },
        {
          "name": "Laptop 15 inch 16GB",
          "sku": "L2201516",
          "price": 229900
        }
      ]
    }
  }
}

In a REST API, we'd typically need to make 5 separate requests to get all that data - one for the product, and one for each of the 4 variants!

Hands-on: Queries

Now that we know the fundamental concepts of GraphQL queries, spend some time exploring the Vendure API! Use the ctrl + space hotkey to bring up the available queries and their fields.

Mutations

Mutations are the counterpart to queries, and as the name suggests, they are used to mutate (change) data. Mutations are similar to POST or PUT requests in a REST API.

Let's execute a mutation. Paste this into the left hand panel of the playground:

mutation {
  addItemToOrder(productVariantId:1, quantity: 1) {
    ...on Order {
      id
      state
      totalQuantity
      totalWithTax
    }
    ...on ErrorResult {
      errorCode
      message
    }
  }
}

Press the play button and you'll see something like this:

{
  "data": {
    "addItemToOrder": {
      "id": "1",
      "state": "AddingItems",
      "totalQuantity": 1,
      "totalWithTax": 155880
    }
  }
}

Let's once again break down each part of the mutation syntax:

mutation: declares that we are dealing with a mutation as opposed to a query. Unlike with queries, this keyword is not optional.
addItemToOrder: the name of the mutation as declared by our schema.
productVariantId: 1: like queries, mutations can (and usually do) take arguments.
... on Order: this is known as an inline fragment. Since things might go wrong when adding an item to an order (e.g. insufficient stock), the mutation will return either an Order object, or an ErrorResult object. This syntax is like saying "if it returns an Order, then give me the ID, state, totalQuantity & totalWithTax fields. If it returns an ErrorResult, then give me the errorCode and message fields." You can try this out by entering quantity: -1 and observing what happens.

As you can see, mutations share all the same parts as a query. In fact, the only real difference is the mutation keyword at the start. Just like with queries, they have arguments and they return a type. In this case the type is a combination of several object types (known in GraphQL as a union type, a more advanced topic out of the scope of this tutorial).

📖 Reference: graphql.org Mutations, graphql.org Union Types

Hands-on: Mutations

Now you can explore for yourself how mutations work using the GraphQL playground. With the initial mutation { } keyword in place, pressing ctrl + space will now bring up auto-complete on all available mutations.

Here's a challenge for you: see if you are able to successfully execute the adjustOrderLine mutation in order to change the quantity of laptops in your order.

Wrapping Up

In this post we've covered how to set up a full-featured GraphQL server using Vendure, and then learned the basics of queries and mutations. These two concepts form the basis of everything you'll be doing with GraphQL.

But of course this is more that you can learn - fragments, interfaces, named operations, variables, aliases and more. If you like the style of this tutorial and would like to see a follow-up that takes the next step into these more advanced topics, please leave a comment below!

And if you enjoyed working with Vendure - check out the GitHub repo and leave a star! 🙏

What makes e-commerce apps so hard to build?

Michael Bromley — Sun, 16 Jan 2022 14:59:52 +0000

E-commerce is a cornerstone of the internet economy. There are millions of e-commerce applications out there and more being built every day. For such a common type of application, they are famously hard to get right.

In this post I'll outline some of the factors that make e-commerce applications the final boss of web apps, and then discuss some of the solutions.

The Problems

If you want to build an e-commerce app, you need to think about:

SEO. This is critical. Thus you need to carefully consider SSR vs SSG, caching, invalidation, url design, redirects.
Performance. Long loading times or sluggish response to input will drive away customers and impact SEO (see 1). Bundles need to be kept lean. And remember, marketing plans to later add 3MB of JS via Google Tag Manager 🙃.
You have an impatient audience who can go elsewhere. This is not some intranet app that users are obliged to use. You need to win them over with a superior user experience.
You are dealing with financial transactions. Bugs can be very consequential! A rounding error on a high-traffic site can get ugly 😬.
Storefront apps are complex. Beyond basic product list/detail/checkout, you have search, filtering, wishlists, auth + accounts, gift cards, promotions, taxes, shipping, and on and on.
Integrations. A typical e-commerce app will minimally integrate with one or more payment providers, shipping providers, then maybe taxes, recommendations, CMS, reviews, emails etc.
Legacy systems. Many businesses run on tech that cannot easily be changed. So your shiny new app will have to talk via SOAP or CSV files or do daily data imports from some server in head office.
The messy real world. Payments will fail, customers will call to change an order, refund or return. Stock levels will get out of sync with the warehouse. It's a concatenation of edge cases.
Scaling. Black Friday/Cyber Monday should not take down your website! But you also don't want to pay for a maxed-out server all year round.
Internationalization. Are you selling in multiple countries? OK now you need to think about multiple languages, multiple currencies and exchange rates, display formats and (worst of all) multiple sets of tax rules.
Taxes. I know I already just mentioned them, but getting tax compliance right is so hard that it deserves its own bullet point.
A long shelf life. The typical e-commerce application needs to be operational for many years, even a decade or more. Especially when a lot of work has been done to integrate with existing systems, the cost of migrating to an entirely new platform is high. Therefore they need to be able to adapt to tomorrow's technology landscape.

The Solutions

There is no single solution to all of these problems. Rather, there are a number of approaches which offer different trade-offs. Broadly, we can think of three axes of solution:

SaaS vs Framework
Monolithic vs Headless
Proprietary vs Open source

SaaS vs Framework

SaaS platforms take care of the operational issues, at least in theory. Even giants like Shopify can still have outages but in general they deal with traffic spikes well and let you forget about servers. Moreover, SaaS platforms free your team from needing to worry about upgrades and maintenance headaches.

With widespread adoption, the leading SaaS platforms include much of the typical functionality required by most businesses, thereby cutting down the amount of custom development needed. For smaller and simpler use-cases, they can be a complete solution, and there are often existing integrations for most popular services for payments, shipping, taxes etc.

Where they can fall down is when it comes to very particular business requirements. Remember those csv imports from that one supplier? Or the custom order flow demanded by the business model? You can end up having to write a lot of custom code, sometimes fighting against the platform. Or else cobbling together a Rube Goldberg collection of third-party extensions which becomes expensive in terms of money and maintenance.

SaaS examples: Shopify, BigCommerce, Commercetools, Swell

E-commerce frameworks provide the building blocks for developers to create completely custom applications. Those tricky integrations with back-office systems and those specialized workflows can be custom built by extending the core functionality of the framework.

Frameworks typically require at least some custom implementation work, potentially driving up initial costs. Furthermore they need to be hosted, meaning that you are responsible for operations and keeping your store live over Black Friday. On the other hand, savings can be had in ongoing costs, as many frameworks do not require a yearly license to operate.

Framework examples: Magento, Saleor, Vendure, WooCommerce, Shopware

Monolith vs Headless

Monoliths refer to applications in which the front-end storefront part is an inseparable part of the backend platform. Typically, the same platform will be generating the storefront based on a templating or theme system. Monolithic architecture has been around for a long time and is the most common way of building e-commerce apps.
Monolith examples: Shopify, Magento, WooCommerce.

Headless platforms, on the other hand, do not handle the storefront at all. Rather, they provide APIs (typically REST or GraphQL) which expose all e-commerce functionality, allowing a storefront to be created to the exact needs of the business, using the latest technologies.

Headless architecture removes the technological lock-in of monolithic solutions, de-coupling the storefront app(s) from the commerce backend. This can allow merchants to take full advantage of the latest techniques to produce fast websites with a great user experience. It also allows a single backend to power web, mobile, point-of-sale and other apps simultaneously.

From a developer perspective, headless frees up teams to use the technologies and workflows that suit them best. No more limitations of a restrictive theme system. No more being bound to non-optimal processes imposed by the backend.

The major challenge with headless is that you get no storefront out of the box. Presenting raw JSON to customers won't fly! Building a storefront is a large undertaking, so the up-from implementation cost will be higher than with monolithic solutions which include a storefront.

To mitigate this factor, there are an increasing number of storefront projects which have done all the hard work of implementing a modern commerce front end app, allowing you to plug them in to the headless backend of your choice. Examples include Vue Storefront and Vercel's Next.js Commerce.

In recent years, headless architecture has been gaining a lot of interest to the point that many of the traditionally monolithic solutions have either added support for headless (Shopify, Magento) or have completely shifted focus.

Headless examples: Commercetools, Swell, Vendure, Crystallize

Proprietary vs Open Source

Proprietary platforms do not make their code available, or make it available only under a commercial license. All of the SaaS platforms fall under this category, and there are also some proprietary frameworks - especially at the higher end of the market.

Open source projects have long played a major role in e-commerce. Especially at the mid-market, open source solutions like WooCommerce and Magento still dominate.

The advantages of open source platforms include pricing, a potentially larger developer community (and thus hiring pool), the ability to modify the code to fix issues and some degree of protection from vendor lock-in.

The trade-offs with open source solutions are the same as with frameworks in general, as open source solutions are typically self-hosted frameworks. Proprietary platforms may also be able to offer better customer support and things like service level agreements, which are not always available for open-source products.

Many open source projects also offer a hosted version, which combines some of the strengths of SaaS with the control offered by frameworks.

Vendure

I started building Vendure as an attempt to solve the particular combination of problems that our business had encountered. Vendure is an open-source headless commerce framework. Now that we've covered each of these terms, you should have an appreciation of the problems it is solving and the trade-offs that it makes.

It handles all typical e-commerce functionality (and we spent a very long time getting taxes right!), whilst providing extension points which allow virtually any custom functionality to be added.

It embraces modern tooling, including TypeScript and GraphQL, and is built on one of the most popular and widely-used Node.js frameworks - NestJS. A primary goal of Vendure is to provide an outstanding developer experience which allows developers to build rapidly and have fun whilst doing so!

It has integrations with Vue Storefront and Next.js Commerce, meaning you can get up and running with a basic full stack headless commerce store in literally minutes. It is used in production on projects of all sizes, from solo founder-built shops to rapidly-growing startups to Fortune 500 enterprises.

So if you are looking to start an e-commerce project and you think that a headless, open-source framework would be a good fit for your requirements, get started with Vendure!

Open Source win: IBM shifts legacy commerce systems to my one-man OSS project

Michael Bromley — Fri, 17 Dec 2021 08:58:10 +0000

For the past 3.5 years I've been working on an open-source e-commerce platform, Vendure.

It's in a niche known as "headless commerce" which is really hot right now, so I've had lots of interest from investors over the past year. However, I'm determined to see how far I can take things as a bootstrapped indie-hacker.

Yesterday was a major milestone as I was able to announce that IBM have adopted Vendure to replace an outdated, proprietary system that had been slowing them down and causing huge expense in terms of license fees as well as lost developer productivity.

This is really exciting because it shows just how much progress the open-source movement has made, that even the largest enterprises are willing to bet on lean, relatively new projects like Vendure - a single-person open-source project!

It's a sign that the technology stack is important. Developer experience, maintainability, documentation, openness - all these things actually contribute to the cost of running a system. So from both a technical and financial viewpoint, OSS solutions increasingly make more sense.

There's that old phrase, "nobody got fired for buying IBM". Well, I'm hoping that this will make it clear that my project is a safe choice, no matter the company size.

Just thought I'd share the success!

If you want to know more about Vendure, I recently wrote a short intro tutorial, and I plan a more in-depth series of tutorials in the coming weeks.

Set up a Node.js e-commerce app in 10 minutes with Vendure

Michael Bromley — Mon, 13 Dec 2021 21:21:31 +0000

Vendure is a modern headless e-commerce framework written in TypeScript and built on top of the excellent NestJS framework.

By "headless" we mean that it exposes an API (GraphQL in the case of Vendure), which allows you to build your storefront using your favourite front-end technology, be it Next.js, Vue, Svelte, or anything else you like!

Headless e-commerce has a somewhat justified reputation of being more complex and development-intensive than off-the-shelf SaaS solutions like Shopify. But with Vendure we aim to cut down your development time to the bare minimum with a combination of:

a rich set of features
integrations with existing solutions
optimal developer experience
modern technologies and workflows

In this tutorial I will take you step-by-step through setting up a fully-functional headless e-commerce server.

Installation

To create your app, run the following command:

npx @vendure/create my-shop

This will guide you through the setup by asking you a series of questions. Select the following options:

√ Which database are you using? 
  » SQLite
√ Which programming language will you be using? 
  » TypeScript
√ Populate with some sample product data? 
  » yes
√ What identifier do you want to use for the superadmin user? 
  » superadmin
√ What password do you want to use for the superadmin user?
  » superadmin

Now go make yourself a drink or check your dev.to feed for a few minutes while we install all the dependencies and scaffold your app!

Once everything is done you should see this message:

Success! Created a new Vendure server at <path>/my-shop

We suggest that you start by typing:

    cd my-shop
    npm start

Happy hacking!

And... that's it! cd into the newly-created directory and run npm start.

Congratulations - you now have a fully-functional headless e-commerce server.

Test it out

Let's test out our shiny new GraphQL API! Go to http://localhost:3000/shop-api and paste the following query into the left-hand pane of the GraphQL Playground app:

{
  products(options: { take: 5 }) {
    totalItems
    items {
      id
      name
      featuredAsset {
        preview
      }
    }
  }
}

Play around with the API - because it's GraphQL, you'll get rich code-completion so you don't need to try to guess what fields are available. Press ctrl/cmd + space to get a list of available fields at any location.

Next, you can head to http://localhost:3000/admin where you can login with the credentials superadmin, superadmin. This will grant you access to the Vendure Admin UI - a full-featured interface for managing every aspect of your store.

Storefront

Vendure only provides the backend part. What about the storefront? You'll need one of those if you want anybody to be able to buy your stuff.

Building a custom storefront from scratch can be a big task, but luckily we've got a couple of great options for you to get you up-and-running in no time:

Vue Storefront is an industry-leading storefront library built on Vue & Nuxt.js. The official Vue Storefront / Vendure integration allows you to set up a slick, modern and performant store-front in minutes.
Next.js Commerce is a starter kit that gets you set up with a modern storefront built by the Vercel team. The project also comes with a Vendure integration, and you can see a live demo of it at vendure.vercel.store.
Build your own! Vendure is an excellent back-end to use when learning a new framework. It runs everywhere, uses few resources, and exposes a full, production-grade API to build against. Why not test out that latest framework by building a minimal e-commerce storefront?

Next Steps

While Vendure is simple to set up, it is by no means a "light" or "toy" solution. In fact, it is one of the most extensible and feature-rich of all the e-commerce frameworks out there, and is used in production by Fortune 500 companies, billion-dollar start-ups and solo-developed boutique shop projects alike!

To dive into the possibilities offered by Vendure, check out our extensive developer documentation, and if you run into any trouble, please join our Slack community where you'll find the help you need.

Finally, here's a presentation I gave at a recent conference which covers more of the background and goals of the Vendure project. Thanks for reading!