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

[INFO]: Architecture Overview #14

Open
21Bruce opened this issue Sep 1, 2023 · 0 comments
Open

[INFO]: Architecture Overview #14

21Bruce opened this issue Sep 1, 2023 · 0 comments
Labels
information This issue is a note describing general information

Comments

@21Bruce
Copy link
Owner

21Bruce commented Sep 1, 2023

Information to share

This is a general note where I'll go over the overhead view of the architecture the codebase uses for new developers.

The codebase consists of three logical "layers".

The basest layer is the API layer. This layer is found in the api/ directory. At the top level is a package called the api package which provides the api interface. This interface specifies the functions each go api to an external reservation service (resy, opentable, etc.) should have in order to plug in to the rest of the codebase. This layer has sublayers representing the implementations of each external api. These can be found in the api/resy/ and api/opentable/ directories on the develop branch. These packages are where the network requests to resy and opentable are made.

One level higher, we have the App or Backend layer, located in the app/ directory. This layer provides a struct called the AppCtx struct, which takes in an(soon to be multiple) api type and uses it to provide the core functionality of the app. This includes scheduling reservation requests to be sent to servers at specific times and monitoring services on an interval to see if reservations have freed up. This layer is where all the concurrency happens.

The top level layer is dubbed the Runnable or Frontend layer located in the runnable/ directory. It acts as a namespace and common interface to front-end wrappers to the App layer. This is where the CLI application lives as a subpackage, and where the HTTP server will eventually live as subpackage.

There are also a few packages that don't fit anywhere into the architecture but just provide some domain-specific functionality. For example, the CLI application uses a cli tokenizer and parser implemented in the cli/ directory / cli top level package.

@21Bruce 21Bruce added good first issue Good for newcomers information This issue is a note describing general information labels Sep 1, 2023
@21Bruce 21Bruce pinned this issue Sep 1, 2023
Repository owner locked as resolved and limited conversation to collaborators Sep 1, 2023
@21Bruce 21Bruce unpinned this issue Sep 3, 2023
@21Bruce 21Bruce removed the good first issue Good for newcomers label Sep 4, 2023
@21Bruce 21Bruce pinned this issue Nov 14, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
information This issue is a note describing general information
Projects
None yet
Development

No branches or pull requests

1 participant