greeting-service

This is a ridiculously overengineered greeting service! Its sole purpose is to create a greeting composed of a name and a message. The name will be one of the 10 most popular baby names in the USA in a particular year. The year will be chosen at random. The message will be chosen from a pre-canned list of 10 or so messages.

The system is composed of several services, each with a specific responsibility:

frontend - This service acts as an API aggregation layer. It depends on the name service and the message service.
name-service - This service returns a random name. It depends on the year service.
year-service - This service returns a random year.
message-service - This service returns a random message from a list.

Each service can be written in any language, and they should use a combination of instrumentation techniques. Some will be instrumented with a Honeycomb beeline and some with other standards, like OpenTelemetry. The idea is to use these to test compatibility between various types of services. The motivating use case is testing trace context header compatibility between Honeycomb and OpenTelemetry.

.NET

frontend using Honeycomb.OpenTelemetry
message-service using Honeycomb.OpenTelemetry
name-service using OpenTelemetry
year-service using OpenTelemetry

Elixir

frontend using opentelemetry-go
message-service using beeline-go
name-service using opentelemetry-go
year-service using honeycomb-opentelemetry-go

Java

frontend using opentelemetry-javaagent
message-service using honeycomb-opentelemetry-javaagent
name-service using honeycomb-opentelemetry-javaagent
year-service using honeycomb-opentelemetry-skd

Node

Python

frontend using beeline-python
message-service using opentelemetry-python
name-service using honeycomb-opentelemetry
year-service using beeline-python

Ruby

Web

A web app instrumented using opentelemetry-js

Caveats

Port and host names are hardcoded.

Frontend: Port 7777
Name: Port 8000
Year: Port 6001
Message: Port 9000

Setup

Check out DEVELOPING.md for some additional tips and language-specific details.

Each service reads its configuration from the environment. Specific environment variables:

HONEYCOMB_API_KEY - Your honeycomb API key
OTEL_EXPORTER_OTLP_ENDPOINT=https://api.honeycomb.io

Some services use vanilla OTEL:

OTEL_EXPORTER_OTLP_HEADERS='x-honeycomb-team=api-key'

If configuring non-prod API endpoint:

OTEL_EXPORTER_OTLP_ENDPOINT=https://api.some.place
HONEYCOMB_API_ENDPOINT=https://api.some.place

If using Classic Honeycomb, you'll also need a dataset and must include in the OTEL headers:

HONEYCOMB_DATASET - The name of the dataset you want to write to
OTEL_EXPORTER_OTLP_HEADERS='x-honeycomb-team=api-key,x-honeycomb-dataset=greetings'

Running with Tilt

Server apps

There is a Tiltfile to run these services on a local host using https://tilt.dev/. After installing Tilt, running tilt up should spin up all of the services.

NOTE: you need to use tilt version 0.32.2+ otherwise you will get an error

Docker Compose service "frontend-java" has a relative build path: "./frontend"

This tiltfile utilizes docker and docker compose. You can verify they are installed first by checking docker version and docker compose version

The default tilt setup runs the go services.

To run services in another supported language, add the language name after the tilt command:

tilt up node

When you're done:

tilt down

NOTE: if you only cancel the tilt up command, docker resources will remain running. If you then try to start up another set of services, you will get a port collision. tilt down removes any resources started by tilt previously.

List of supported languages

go
python
rb
java
dotnet
node
elixir

It's also possible to run a combination of services in different languages, for example the following command would run each specific service mentioned along with the required services (collector, redis, curl greeting)

tilt up frontend-node message-go name-python year-rb

To configure a common set of services that are specific to ongoing development, or to override the default option of running all services in go, add a file tilt_config.json and specify a group or set of services. This file is ignored by git so it can be developer specific and allows running tilt up without having to specify further arguments.

Example tilt_config.json to override go as the default service

{
  "to-run": ["node"]
}

Example tilt_config.json to override the default with multiple services

{
  "to-run": ["frontend-node", "message-go", "name-python", "year-rb"]
}

Once running, curl localhost:7777/greeting to get a greeting and a trace!

ctrl+c to kill the session, and tilt down to spin down all services.

Client apps

To run the browser app inside of /web run

tilt up web node

This will start up the browser app as well as all node backend services. The browser app makes requests to http://localhost:7777/greeting so there has to be a set of backend services running. It could also be any one of our other supported languages (e.g. py, go etc.)

Running with Docker

You can also run services without Tilt by running docker-compose with the base configuration file and a language-specific configuration file.

docker-compose -f docker-compose.yml -f docker-compose.java.yml up