Case Studies

The Challenge

Lagonika runs on its members. People post deals from Greek and international shops, vote them up or down, and discuss whether an offer is real. The community already had tens of thousands of accounts from an earlier WordPress site. A theme-and-plugin CMS cannot hold the review queues, the permissions, and the live feed without bending the product around the CMS.

Our Solution

We split the product in two. Next.js is the site members use. Strapi is the API that owns offers, votes, comments, and the rules about who may publish. The public pages stay cached. Every write still has to pass the API.

How the community works

Anyone can read the feed and follow a discussion. An account is for taking part: post a deal, vote, reply, message someone, or get an alert when a kind of offer shows up.

What a person can do depends on how trusted the account is. A new offer can wait until someone has looked at it. People the community already trusts publish straight away. The people who look after the site can open deals that are not public yet, edit any of them, and decide what stays on the feed.

Posting and editing

Creating a deal and editing one use the same form. You describe the offer and add a photo. The API decides which parts of that you are allowed to change, and it records the post as yours.

People edit their own deals. The people who look after the community can edit any deal: when it goes live, where it sits in the feed, and whether the discussion and the outbound link stay open.

Comments and moderation

Comments sit on the deal, with replies, mentions, and votes. The person who posted it hears about new comments, and people can follow a thread they joined.

Publishing a comment is not something the writer chooses. Newer accounts start in review and earn the ability to comment live. An account can also be held back, or stopped from commenting, voting, or chatting. Offers and comments each have a queue, so something that should not be public can be held or removed.

Why a split system

The pages and the rules change for different reasons. The feed, the forms, and the chat ship as a Next.js app. Offers, votes, permissions, and moderation live in Strapi, on PostgreSQL. One API enforces the rules, so the website goes through the same checks as any other client.

That split fits a deals community. Voting, review, per-person limits, and real-time chat are the product. In a monolithic CMS they become plugins on a theme, and every page view carries them. Here they are the API. The site renders the result.

Speed

A classic CMS builds the page on every visit: the theme, the plugins, the post, the comments. Lagonika renders the public pages ahead of time. Anonymous visitors get a cached homepage, refreshed in the background so the next person is not waiting on the API. A deal page is regenerated about every 30 seconds. Logged-in traffic stays private, so one person's vote is never served from someone else's cache.

Search runs on Elasticsearch across the whole archive. Photos are stored on Amazon S3, served from the CDN, and resized by Next.js. The API only does the work that changes: a vote, a comment, a new offer, a moderation decision.

The Challenge

NOMA sells cooked food for dogs and cats on a repeating plan. The public site, the subscription, and the back office are different jobs. A standard shop keeps them in one place, and someone still has to re-enter the customer and the order in the ERP.

Our Solution

We split the product in three. Next.js is the site and the account. The API holds the content, the customers, the subscriptions, and the orders. The ERP receives those customers and orders, so the business runs on the same record the customer just confirmed.

How it is put together

Next.js serves two things. The public site — home, recipes, articles — and the logged-in app, where a customer builds a plan, checks out, and manages it. The site is in Greek and English.

The API, on Strapi, owns the records. Content for the public pages. Customers, pets, subscriptions, and orders for the app. The website reads and writes through that API. It does not keep its own copy of the business data.

Subscriptions

A subscription belongs to the customer and lives on the API. Each delivery is an order on that subscription. The app creates the plan, and from the account the customer can change it, pause it, or cancel it.

A change can apply to the next order only, or to the subscription, so the orders after it follow. Payment is recurring: the card stays with the customer, and each order is what gets charged.

The ERP

Customers and orders sync to the ERP. A new account is a customer there. A new or updated order is the same order there. Production and invoicing start from that sync, so the plan is not typed in a second time.

Speed

Public pages are rendered ahead of time and refreshed on a schedule. A visit to the homepage, a recipe, or an article is served from cache, and the CMS is not in the path of every request. Drafts in Strapi skip that cache, so editors see unpublished content.

The account is private. Subscriptions and orders are cached per customer and cleared when they save, pause, or cancel, so the dashboard shows the plan they just changed. Photos are stored on Amazon S3, served from the CDN, and resized by Next.js.