YAS Microservices: Docker Compose setup for a Java shop

What YAS Models in a Java Shop

YAS, short for Yet Another Shop, is explicitly described as a pet project for practicing the construction of a typical microservice application in Java. It is aimed at developers who want to study a repository containing separate application modules instead of a single deployable program. Based on the repository layout, the shop includes catalog, cart, customer, inventory, order, payment, promotion, rating, search, delivery, location, tax, media, recommendation, and webhook concerns. There are also `storefront`, `storefront-bff`, `backoffice`, and `backoffice-bff` components, which separate browser-facing applications or backend-for-frontend layers from domain services.

This breadth makes YAS more useful as a structural reference than as a turnkey shop. A reader can inspect how an ecommerce domain is divided into many top-level modules, along with shared code, Kafka integration, identity configuration, databases, ingress configuration, and deployment resources. The README describes Java 25, Spring Boot 4.0, Testcontainers, Next.js, Keycloak, Kafka, Elasticsearch, Kubernetes, GitHub Actions, SonarCloud, OpenTelemetry, Grafana, Loki, Prometheus, and Tempo as tentative technologies and frameworks. That wording matters. The README does not claim that every listed component is required in every deployment profile.

YAS is therefore a study project for engineers exploring Java microservice organization and operational plumbing. It is a poor fit for someone expecting a narrowly packaged library, a single-command application, or a production commerce platform with documented support boundaries.

Service Boundaries and Request Paths in YAS

The repository presents YAS as a distributed system rather than one Spring Boot application. Its top-level directories include separate services such as `product`, `cart`, `customer`, `inventory`, `order`, `payment`, `search`, and `recommendation`. A `common-library` directory is also present, while `storefront-bff` and `backoffice-bff` provide distinct BFF projects for the customer and administration experiences. The exact internal calls between every service are not documented in the README, so the service names should not be mistaken for a complete request-level specification.

The local Compose setup supplies several infrastructure pieces that explain the intended architecture. Nginx publishes host port 80 and belongs to `yas-network`. Keycloak runs in development mode with `start-dev --import-realm`, stores its data in PostgreSQL, and imports `./identity/realm-export.json`. The BFF service waits for `identity:80` before starting its Java process. This startup gate shows that identity availability is treated as a prerequisite rather than an optional frontend concern.

The separate search and observability Compose files add optional layers. Search has its own `docker-compose.search.yml`, while observability is isolated in `docker-compose.o11y.yml`. The README associates the full system with messaging, search indexing, tracing, logs, and metrics, but does not publish event schemas or API contracts. Those details must be verified in the relevant service directories, Kafka configuration, and Swagger documentation before depending on any particular integration.

Starting YAS Core Services with Docker Compose

The documented local path requires host-name records because several interfaces are exposed through names such as `storefront`, `backoffice`, `identity`, and `api.yas.local`. Add these records to the host file named by the README:

127.0.0.1 identity
127.0.0.1 api.yas.local
127.0.0.1 pgadmin.yas.local
127.0.0.1 storefront
127.0.0.1 backoffice
127.0.0.1 loki
127.0.0.1 tempo
127.0.0.1 grafana
127.0.0.1 elasticsearch
127.0.0.1 kafka

After obtaining the source, change to the `yas` root directory and start the default Compose project. The README says to wait until the containers are up and running.

docker compose up

The complete container set is documented as requiring a minimum of 16GB of RAM. On a smaller machine, the README says only the core services can be started with this command:

docker compose -f docker-compose.yml up

This distinction is operationally significant. The default command may include more of the stack, while the explicit `docker-compose.yml` profile limits startup to the core services. YAS also provides `docker-compose.search.yml` and `docker-compose.o11y.yml`, but the README does not give a command that combines all three, so an exact full-stack invocation should not be inferred.

First Browser Session After Containers Start

Once the containers are running, the README instructs users to start source connectors from the repository root. The script must be run from a terminal opened at the YAS root folder.

./start-source-connectors.sh

The storefront is then available through the host-name entry configured earlier. The backoffice uses the same local host-name approach and the README lists `admin` and `password` as its login credentials.

http://storefront/
http://backoffice/

The administrator account belongs to this documented sample environment, not to a production identity policy. Other useful entry points include the aggregated REST documentation at `http://api.yas.local/swagger-ui/`, Keycloak at `http://identity/`, pgAdmin at `http://pgadmin.yas.local/`, Grafana at `http://grafana/`, and Elasticsearch at `http://elasticsearch/`.

There is an explicit first-run warning in the README: the storefront and backoffice may not work as expected. Its prescribed response is to stop the containers with `Ctrl + C` and run `docker compose up` again. This is a known setup condition, not something to disguise as a successful first launch. PostgreSQL is also documented as reachable from the host through `localhost` on port `5432`, using the sample `admin` credentials.

Resource, Security, and Customization Limits

The clearest limitation is the full environment's 16GB minimum-memory requirement. That makes YAS unsuitable for many developer laptops and for small CI runners. The reduced Compose file helps, but the README does not identify which optional service groups can be removed safely beyond that core command.

Security defaults are also plainly sample-oriented. Keycloak starts with `start-dev`, imports a checked-in realm export, and uses `admin` as both bootstrap username and password. The README separately lists `admin/admin` for the Keycloak console. The backoffice uses `admin/password`. PostgreSQL is exposed to the host, and pgAdmin credentials are published in the README. None of these defaults should be copied into an exposed or shared environment.

Customization documentation is limited. The repository links to `docs` and `docs/developer-guidelines.md`, and it supplies `.env`, Docker directories, Compose overlays, and Kubernetes resources, but the README does not document production secrets, rollback, database migration procedures, upgrade compatibility, or backup and restore. Those omissions make YAS unsuitable for direct production adoption without a separate review of the actual configuration and deployment files.

The listed Java and Spring versions are also marked tentative. An engineer adopting the example as a starting point should verify the actual parent `pom.xml`, module POMs, container images, and deployment manifests rather than assuming the README's technology list is a pinned compatibility statement.

YAS Compared with a Single Spring Boot Shop

The practical alternative is a modular monolith built around one Spring Boot deployment. Its approach differs in two immediate ways: domain code can remain in one build and runtime, while database changes and internal calls can avoid network and distributed-transaction boundaries. YAS instead gives the reader explicit service directories, a BFF split, Kafka and Elasticsearch topics, Keycloak integration, and independent service processes.

A modular monolith is the better starting point when the learning goal is shop domain modeling, transactional order handling, or rapid delivery without infrastructure overhead. YAS is the better reference when the goal is to inspect how those capabilities are separated across deployable services and connected through web clients, messaging, search, identity, and observability components.

The trade-off is operational complexity. YAS asks for host-name configuration, multiple containers, source connectors, and at least 16GB of RAM for the full set. It may also expose a documented restart requirement on first use. The repository provides a Kubernetes deployment directory, but the README does not define the effort, prerequisites, production readiness, or upgrade path for that deployment, so it should not be compared with a documented one-command Kubernetes installation.

Maintenance Signals, Releases, and MIT Usage

The repository is not archived, and its last push was on 2026-06-12. That is a recent code-change signal relative to the available release history, although recency alone does not establish production support. The three listed releases are `webhook-0.1.0`, `sampledata-0.1.0`, and `recommendation-0.1.0`, all dated 2024-11-11. Their `0.1.0` versions and limited release set suggest that YAS should be assessed primarily as a sample repository rather than as a conventionally versioned product with a long compatibility history.

The README includes CI workflow badges for many services, including storefront, backoffice, product, media, cart, order, inventory, payment, search, webhook, and observability-related components. Those files indicate defined build and secret-scanning workflows in the repository, but the badge images alone do not establish that every workflow currently passes.

YAS uses the MIT License. The README also states that contributions are licensed under MIT. That permissive license supports copying and modifying the code, subject to its notice and conditions, but engineers still need to review dependencies separately because the repository license does not automatically settle the terms of every included image or third-party component.

Editorial conclusion

Adopt YAS as a learning reference when your goal is to inspect a multi-service Java shop, run its web interfaces, and study Docker Compose, Keycloak, Kafka, Elasticsearch, and observability wiring. Do not treat it as production-ready commerce software without first reviewing its sample credentials, default authorization settings, Kubernetes manifests, service boundaries, and operational requirements. For a first decision, run only `docker-compose.yml` on a machine with adequate memory and verify that the documented storefront, backoffice, identity, and API endpoints become usable.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nashtech-garage/yas on GitHub
4. README
5. Releases