Tell us about your tech stack!

Working as a SI I have worked with a different variety of techlogies, the ones that I most used are:

• Frontend: React + Next.js + Tailwind or Sass
• Backend: Node.js or Java
• Cloud: AWS or GCP
• IaC: Terraform
• Preference for serverless offerings (Functions, Databases, CI/CD) 

Easy question for us. Why? Because we could keep our tech stack super simple:
 

• Node.js → Typescript based AWS Lambdas
• Node.js → Typescript → Next.js + React Frontend

To elaborate a little more: We did not need a database, as we had all relevant data stored either in commercetools or in other systems around us. Everything was done cloud native in AWS, starting from the code hosting, CI/CD, Containers, API Routing, and so on.

And all that in a reasonably big project with a couple Million revenue yearly.

Being a big JS sceptic at first, I am now amazed how flexible and fast Node.js is for our use-cases.
Not having to think in different Structures, Konzepts and Languages helped us increase development speed, as backend devs could support frontend and vice versa. 

Typescript adds that layer of type safety on top that you don’t want to miss in a enterprise environment, and react really is a flavor and could probably be replaced by any of the other two (Vue/Angular). However we are very happy with Next.js & React as well.

I’m super happy with the simple yet modern stack. It really did bring us a lot of benefits along the way. And no, I am not the one who introduced it, nor a PO, nor an Architect. Just a regular Dev.

Thanks to those who have chimed in with their tech choices. @Patrick Burkart and @adzanette I’m curious if you have a layer between commercetools and the browser. What are you using? A NodeJS or Java Service? React Server Pages? Or is the browser connecting directly?

Multiple layers actually, but none of them designed as a proper backend for frontend.

However, that was a mistake!

At the beginning, there was no risk to expose the Cart endpoint of the commercetools REST API to the frontend. We added next.js api routes as a proxy, and then hid the commercetools API behind another proxy to verify requests with API keys (this second layer was our “Backend” and had other endpoints, not just the proxy to the CTP API). Therefore, the frontend had full access to the Cart API, but not e.g. to the Products/Customer/Inventory (and so on) API.

This meant, we didn’t have to implement layers inbetween for every API path. Everything was just proxied - the frontend implementation was done using the API of commercetools (e.g. for adding a lineItem). Great, because it is easy to implement something new or extend existing implementations. Little code changes did the trick. If we needed more complex logic, we could always add a microservice that served as layer between FE and commercetools (e.g. for creating an order, which was more complex for us than just transforming a cart to an order).

But, with time, new actions were added to the Cart endpoint. And this is the downside of versionless: Sometimes, changes slip by. As did a change, which enabled anybody with access to the Cart API, to set a 100% discount to the cart. 

Had we hidden the Cart API behind a “classical” Backend for Frontend, then this change would not have had any effect. 

Lesson learned / recommendation

BFF *can* be overkill in my opinion. However, if the underlying API changes without you being the one modifying it, at least put some whitelisting on top of it. Here with the Cart API, we introduced action whitelisting. Only certain actions can now be done from the frontend. Not 100% air tight, but so much tighter than before!

BTW: The docs indicate that a BFF is recommended. I believe that it is not needed, but can of course be helpful - always increases development efforts though.

One of our clients is having this tech stack:

• FE is Frontastic (nextJS + React)
• BE is Frontastic API Hub (TS and NodeJS)
• Extensions and Subscriptions at Cloud Functions at GCP with Nodejs  at Cloud Run
• GCP PubSub for Asynchronous integrations such as the Fulfillment or Notifications
• Terraform as Infra as Code

API Hub is a great middleware that we use con connect with all the third parties, on perm or in the cloud.

With API Hub we reduced the number of Extension like 95% since we can apply any business rule there, we are calling commercetools apis, external price micro services, real time inventory, anti fraud solutions, payment gateway and so on.