SAP Spartacus Guide. Part 4

// SAP SPARTACUS GUIDE PART 4. ARCHITECTURE EXPLAINED AND HOW TO BUILD SPARTACUS HEADLESS FRONTENDS

Published on 7/20/2021


Mirek Bartnik

Mirosław Bartnik, CHIEF TECHNOLOGY OFFICER


If you are running a SAP Commerce Cloud platform you must have already come across Spartacus - SAP’s new, modern shop storefront that is said to provide unique customer experience, modern technology stacks and fast, decoupled frontend development.

It seems inevitable for legacy frontends to be replaced as SAP’s accelerators are not a match for modern customer experience anymore. Modern reactive and progressive web applications are spreading over the world and your commerce platform needs to keep up with the pace.

But what is the best way to proceed with the transition to those modern frontend paradigms? Is Spartacus the way to go? Does it provide a long-term strategy or are there strings attached?

In this article series we provide strategical, technical and practical information about SAP Spartacus derived from our 12 years experience with SAP Commerce Cloud, completed Spartacus implementation projects as well as work on alternative storefronts.

In the 5 parts of the series we discuss general questions, impacts on strategy, technology and project delivery aspects and provide our overall assessment supporting your decision making and helping out to craft your architectural strategy.

Read below about
What is Spartacus' architecture?
What technologies are used in Spartacus?
Is the Spartacus technology a top-notch?
How to start developing with Spartacus?
Is Spartacus a solid application and framework?

What is Spartacus' architecture?

Spartacus' architecture follows the modern way of building web applications; it decouples frontend from backend connecting those two key parts with a clear API. The application focuses mainly on the frontend layer which runs in browser as Angular PWA.

It uses REST-API built into the OCC layer to connect backend to frontend. JSON payloads are well structured along internal guidelines, although they don’t follow any more general standards like, for instance, JSON:API. Some extensions to the OCC layer may be necessary in the backend where standard interfaces are not available but, altogether, there is only little work required in the SAP Commerce backend to run vanilla Spartacus.

As is the case for any single page application the SSR component (server side rendering) constitutes the key element of the architecture. In order to speed up page rendering the first request from a client device is served with a pre-rendered page structure (html). This pre-rendering occurs on the server through a node.js process which mimics browser behaviour. After the initial page load most subsequent communication with the server would only utilize the pure OCC API.

So far, the architecture can be considered modern and pretty standard. What makes Spartacus different from other modern frontend solutions is its proprietary dependency on SAP Commerce SmartEdit - effectively the SAP CMS module. Every page is initially composed in SmartEdit and each query has to retrieve the structure first before processing anything else.

Unfortunately, this dependency tends to become onerous with time as developers complain about spending more time with SmartEdit than with actual coding. SmartEdit is also considered not to be the brightest piece of SAP technology and, to say the least, is not loved by the delivery teams.

What technologies are used in Spartacus?

Spartacus makes use of some finest frameworks and technologies of the modern day. Since its 3.0 version Angular 10 is in use - one of the most popular open source web application frameworks built by Google. Like many Angular applications nowadays Spartacus makes use of RxJS and NgRx for eventing and asynchronous processing.

The fact that Spartacus also makes extensive use of TypeScript, a statically typed language and a superset of JavaScript is a true game changer. TypeScript was created by Microsoft as an open source project with the goal of allowing for high development quality and maintainability of even largest code bases. Think of it as JavaScript for the enterprise.

On the visual side of things Spartacus relies on industry-proven standards embodied by SASS and Bootstrap so that most developers are able to jump straight into coding with just little ramp-up.

Building Spartacus applications is done with webpack and it’s conveniently transparent for the developers. The application is ready to run at any time by just kicking off a node.js server. Deploying to an external server is as straightforward - you just have to obtain the code and run the node.js instance. That is, of course, if you don’t use CCV2 (we’ll have more coming on that topic soon).

Is the Spartacus technology a top-notch?

Spartacus manages to a large extent to make use of current frontends building de facto standards. There is obviously no comparison to accelerators as they seem to come from a different programming era if put side-by-side with Spartacus.

It’s as advanced as you can expect of a good, modern SAP product. It is solid, based on current technologies and built in a way that is appealing to hard core java developers. It may lead to such profits as highly efficient teams, solid code bases and maintainable code.

But, as true cloud and frontend enthusiasts, we’d shy away from calling it a top notch. Firstly, there is this legacy old stack in the backend that bleeds through to the frontend and prevents it from unfolding its whole potential. GraphQL is a simple example - elsewhere, in true headless systems, it is a standard feature and developers love it. It is not available in Spartacus and this won’t change as long as there is this dark and heavy monolith in the backend.

Then, we can’t overlook the fact that we live in times of true cloud and it affects infrastructure and architecture alike. We’d love to see this frontend layer in a real serverless deployment scheme where there is almost no need to worry about scaling your SSR at all. With Spartacus you have a node.js process that you can put into your Kubernetes pods and that’s decent. But one might consider going a few steps further with true cloud infrastructure leveraging advantages in operating cost, scalability and maturity of delivery processes.

Still, this is solid, safe, enterprise software and while you shouldn’t probably aim for the stars with it, it will let you safely land on the moon. Not too bad for SAP.

How to start developing with Spartacus?

Kicking off a Spartacus project is fairly straightforward - you’ll need the code and a SAP Commerce backend. You can basically checkout the GitHub repository, configure it to use your backend and the new frontend should be able to start right away. Once you set up your API and have the backend processes running, it’s just about executing a node.js server and your SSR pages are flying.

As for the backend, there isn’t much to be done for starters. Only if you want to get into verticals and more specialized modules will you need to install additional extensions providing respective APIs through OCC.

Now, if you want to attach Spartacus to your existing codebase, there are a few more things to consider. First and foremost, make sure you are on a supported version o SAP Commerce. In most cases you’ll have to upgrade to a current version required by the newest Spartacus. Remember that officially only the current Spartacus version is supported in terms of patches and updates so you probably don’t want to work with an older version of it.

When running frontend with your customized backend you are likely to come across some (probably dozens) of errors. The amount of which will mostly depend on the extent of your customizations. And their quality.

After you cleaned those, please accept our congratulations! You have just entered the new era of building SAP storefronts. From now on you will be coding mainly in TypeScript, deploying within seconds (at least locally) and enjoying hot code replacement on a running local server. Provided that you are already familiar with Angular and TypeScript (which may take a while to get), your productivity will soar. Well, you’ll have to handle SmartEdit too but let’s stick to the positives.

Interested in maximizing your output? Find out more about our SAP Commerce Delivery

Is Spartacus a solid application and framework?

Let’s finally ask this ultimate question - is it a solid application and is it a solid framework? From developer's perspective one would consider some key aspects here like structure, extensibility, flexibility, stringency, quality and a few others.

In our opinion it is decent. It is well designed in terms of structure, division into modules and utilization of proven design patterns. It uses state-of-the-art technologies and truly facilitates achieving highest levels of customer experience. The team behind it is energetic and the community is decent so any possible teething problems are solved fast and you may expect it to be moving forward at a fair pace.

It is inherently constrained by the underlying services, their legacy nature and fixation on the single backend technology. It’s not really flexible as it’s extendability is only good as long as you decide to stay within the SAP realm. There is too little attention to supporting other backends.

On the tech side of things, it’s solid but, as already said, it’s not a top notch. It goes as far as it can taking into consideration the constraints imposed by legacy backend, and it does not make the attempt to push the boundaries. If you move from Accelerators it will surely be a huge leap in terms of technology and customer experience, although it will also need time for the team to adapt to the new tech stack.

CHECK OUT OUR WHITE PAPERS

Be prepared for your transition
to composable commerce.

Carefree and smooth

GO TO OUR BLOG

OUR CLIENTS

Ivoclar Vivadent
TUI Logo
Nikon logo
TX Group logo
Play Logo
Vision Express Logo
GrandVison Logo
Trendy Opticians Logo

How can we help?

Talk to Mirosław Bartnik, our CHIEF TECHNOLOGY OFFICER

If you’re in doubt whether Spartacus is your best or only option, we can help. Our team has 12+ years of experience in working with SAP Hybris. We have a unique knowledge of decomposing frontends and backends for SAP Commerce customers.
This includes successful takeover of launched projects that other agencies failed.

We demonstrated the quality of our work in numerous successful projects for customers with revenues of 500M to over 1B EUR where commerce is the key to generating sales.
We can help. Drop me a line.

Thank you for the message. I will contact you within one business day.
This site uses cookies and other tracking technologies to improve user experience. For details please see our PRIVACY POLICY