Resolved is a resy bot that assists in obtaining difficult or high-end reservations. Although it only works with resy, there is an opentable api in the tree.
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.
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
APIlayer. This layer is found in theapi/directory. At the top level is a package called theapipackage which provides theapiinterface. 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 theapi/resy/andapi/opentable/directories on thedevelopbranch. These packages are where the network requests to resy and opentable are made.One level higher, we have the
ApporBackendlayer, located in theapp/directory. This layer provides a struct called theAppCtxstruct, which takes in an(soon to be multiple)apitype 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
RunnableorFrontendlayer located in therunnable/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 /clitop level package.