Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding a new service documentation #73

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

jadudm
Copy link
Contributor

@jadudm jadudm commented Jan 5, 2025

PRs at this point do not yet have a full guide template, and are against a system that is not yet production-ready.

This commit is documentation only. It moves some pieces around, and most importantly, adds a document that describes how to add a new service. It is reasonably complete, having been guided by the bringing together of a new service (e2e), which could provide a starting point for a local/in-stack, repeatable path to end-to-end tests. That service is not complete, but standing up the shell/boilerplate guided this documentation.

Adding a story about how to add new services. This will help guide the
devs as we add new services to Jemison.
@jadudm jadudm changed the title Adding a new service Adding a new service documentation Jan 5, 2025
Copy link

@selfdanielj selfdanielj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doc moves make sense... started trying to follow the directions to setup a new service and left a few comments. Didn't quite finish but thought id post what i have so far.

@@ -44,3 +44,6 @@ flowchart LR
At this point, further services clean, process, and prepare the text for search.

Read more about the [data processing pipeline](processing.md).

## administration via API

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was there meant to be something else here? this is a heading without anything.

Comment on lines +153 to +165
```
var ThisServiceName = "searchapi"

func main() {
env.InitGlobalEnv(ThisServiceName)
engine := common.InitializeAPI()

zap.L().Info("listening to the music of the spheres",
zap.String("port", env.Env.Port))
// Local and Cloud should both get this from the environment.
http.ListenAndServe(":"+env.Env.Port, engine)
}
```

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add an In main.go like in add job_creator section?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this code meant to replace the WaitGroup boilerplate from above or add to it?


We may want to consider having some global constants for service names, instead of strings. However, there's no way to make that constant work across the config files and the applications, so... :shrug:. We use strings for the moment.

It should now be possible to stand up the stack with the new service, and have it respond to healthchecks. The common API initialization establishes a basic healthcheck for every single service. We need this so that Cloud.gov will be able to tell if our services are alive/responding.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if running through make docker macup don't we need a run.sh or similar entrypoint?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

2 participants