How would we work without an API? If you were debugging something right now, you would surely say "much better" 😉 But let's face it, without an API, the modern e-commerce world wouldn't work at all. And what do we do to make sure our API works the way we expect it to? How do we test our API? How do we validate our schema?
The question is always where to fix a problem. For example, if data is missing from an API, you could fix that with a second request or change the response of the first request. So in a headless setup, you always want to have the minimum amount of data you need, but things will always change and you need more data or data in a different structured form. So you might find yourself talking to backend developers to optimize the API, or moving logic to the frontend that doesn't actually have anything to do with the frontend. So in this blog post, let's look at how we can add a layer between frontend and API to transform and optimize our data according to our needs. Plus we can add caching (if needed) very easily to make it blazing fast.
You already heard about the new Shopware Frontends? It uses the headless approach known from 😇 the administration area of Shopware. In general Shopware provides an admin API, the sync API and the store API. So basically the store API is for every action that a website visitor can do in your store. But to be honest Shopware Frontends is not a out-of-the-box solution. You need developers that can put every headless thing together for you. In this blog post I want to show how easy you can add your own Vue.js composable that will get additional data from another source into your Shopware Frontend. Let's look into some code 🚀
I really like short videos about different tech topics that just show what's out there. So there was a nice video, which I will also link later in this blog post, about 15 futuristic databases and what is possible with them. There are things like a Git-like version control for SQL tables. There is a database where you can write JavaScript in it. And of course, there is a database that uses AI. Because ChatGPT is everywhere at the moment, I also used it to create the table in this blog post. So be careful; what you read on the World Wide Web is not always true, and there can be errors. Enjoy the overview of these futuristic databases.
Sometimes it is maybe useful to get the defaultTaxRate that is defined via Admin in Shopware 6. For this we have this small php function below to get the UUID from the SystemConfig and then search with the tax.repository to get the curent value. The system path to get the default UUID is core.tax.defaultTaxRate.
When you start working with Shopware 6 it can be hard to know what to use for what. So this guide will explain you the different aspects of CustomFields, Properties and Entity Extensions in Shopware 6. Disclaimer: This definition is maybe not correct in all parts, it is more less a guide to give you a feeling what to use when. Because you can solve same tasks in very different ways and maybe both will work. So feel free to comment when you think something should be changed or written in another way. Let's checkout the differences between CustomFields, Properties and Entity Extensions.
You working on a customer project and you want to make sure that you write code like a Shopware 6 core developer? Then you need all the shiny linters that the core developers are using. This guide will explain how to setup PHPStan and easy-coding-standard as a pre-commit hook with CaptainHook in a docker container setup. That's it, enjoy. 🤯
