Add tonic boilerplate

[graysonguarino]

Issue Number:
Reference the issue this PR fixes.

N/A

Description of Changes:
Provide a clear and concise explanation of what changes you made and why.

• Add tonic gRPC boilerplate.
• Add more CLI arguments for starting servers.

Testing Done:
How did you test your changes? Share details like steps, tools used, or results.

N/A (business logic incoming).

Terms of contribution:

By submitting this pull request, I agree that this contribution is licensed under the terms of the Apache License, Version 2.0.

---

Thanks for submitting your pull request! We will review it as soon as possible.

[graysonguarino]

This PR builds upon #13 and adds some more boilerplate, this time for the gRPC service handlers. Much of this code follows the same structure as the PoC's, except this is more modularized and, imo, easier to grok.

Some comments:

• .cargo/config.toml was added so we can retrieve the root of the workspace. This is necessary as I feel all API definitions should be at proto/ for discoverability reasons, and because I want to conceptualize the definitions and their Rust implementations as separate entities. (In other words, I don't think they should be defined somewhere like lib/proto/proto).
• I believe the generated Rust bindings for the Protobuf definitions should be generated at build time and not committed (hence the .gitignore files in lib/proto/generated/*.) If you're wondering why there are separate .gitignores in these directories rather than in the root directory, this is because the build sometimes fails if those directories don't exist, and I feel like introducing a Makefile to create those directories for us should be a last resort. We should try to use cargo build for everything unless we run out of options.
• Implementations for the service handlers and unit tests will be introduced in another PR as I'm trying to keep these as bite sized as I can.

[graysonguarino]

Drafting until #13 is ready. Looks like I'll have a lot of rebasing to do :)

EDIT: Fixed and reopened.

[graysonguarino]

One more thing:

I'm currently building this without a database connection pool to make things easier to get it off the ground. In the future, it's likely that we'll want to prevent the gRPC service handlers from having to make a unique database connection every time they have a request to fulfill, but the consequences of this aren't benchmarked for our use case yet so I'm trying to avoid prematurely optimizing. diesel does provide a scheme for us to implement one (diesel::r2d2), so I'm not worried about it right now.

[graysonguarino]

Drafting for a second as I have decided that I shouldn't expose the generated models directly when working on the followup PR. I want to have the ability to extend the functionality of the models so we can define filters inside tuxtape-database-bridge.

[graysonguarino]

This change is due dependency-review-action requiring SPDX-compliant license names. matchit and ring both have their reasons for being AND instead of OR dual-licensed, and the former of those isn't recognized by SPDX. This removes the license check on these two.

[ecpullen]

Is tuxtape_database_bridge/grpc.rs intentionally empty?

[ecpullen]

Can we just walk the protos dir instead? That way any thing added is automatically picked up?

[graysonguarino]

Bah, forgot about this one. Will get that up soon.

[graysonguarino]

I think maybe we should avoid walking the directory for now for a few reasons:

There's a reason they didn't give you the ability to just include anything in the .proto folder:

1. you only want to include ones that define service functions (any .proto that gets included by those protos also gets included in the build process, as seen with tuxtape.common.v1.rs).

2. we need to add a dependency to do it, and it doesn't use an SPDX-compliant license title which is more cruft for our license check config

3. the solution is going to get ugly, and will get uglier if we need to bump the proto version

This doesn't exactly work, but it's similar to what would as far as i can tell:

    let v1_protos = WalkDir::new(&proto_tuxtape_dir)
        .into_iter()
        .filter_entry(|entry| {
            entry.path().extension().is_some_and(|ext| ext == ".proto")
                && entry
                    .path()
                    .components()
                    .any(|comp| comp == Component::Normal(OsStr::new("v1")))
        })
        .collect::<Result<Vec<_>, _>>()?;

    let v1_protos = v1_protos
        .iter()
        .map(|entry| entry.path())
        .collect::<Vec<&Path>>();

(btw, that's split up bc the Rust compiler says that first .collect vector needs a binding, and i'm not sure how to early return with an error when mapping as you can't return upwards from a closure)

I feel like doing this is going to cause more issues than it solves, and makes the code a lot harder to read. I'd only expect we need to add a handful of protos in the lifetime of TuxTape.

[ecpullen]

you only want to include ones that define service functions (any .proto that gets included by those protos also gets included in the build process, as seen with tuxtape.common.v1.rs).

We should be able to structure our protos in a way that still allows us to walk the directory.
i.e service protos in a service directory.

we need to add a dependency to do it, and it doesn't use an SPDX-compliant license title which is more cruft for our license check config

I don't think this is a valid reason not to do it.

the solution is going to get ugly, and will get uglier if we need to bump the proto version

Can we restructure the protos? What exactly would cause issues if proto versions needed to be bumped?

[graysonguarino]

I've got the protos structured as suggested by buf. I can restructure them if we really need to, but at that point we're going off script from how I've ever seen Protobuf files structured, so I'd rather keep the structure the same if possible.

What exactly would cause issues if proto versions needed to be bumped?

It would just complicate the filter rules for what gets included and excluded.

I can try to work on a cleaner solution than the one I posted tomorrow. I'm just trying to get this PR wrapped up as this has been open for almost two weeks and I keep rebasing in-development branches on these changes which gets cumbersome when we're frequently restructuring things.

[ecpullen]

This feels like something that could take ownership instead of adding complexity with Arc.

[graysonguarino]

I may be off base here, but there are a few reasons I think we shouldn't do this:

1. We call start_server() in a loop in main() in case it crashes and we need to log it and bring it back up. If it does crash, then that ownership goes away. Leaving it as Arc<DatabaseConnectionDetails> allows us to have one persistent instance of it across the lifetime of the program.

2. Further, there are multiple services spun up within start_server() that need an instance of a DatbaseConnectionDetails as well.

[ecpullen]

Is this the recommended way to do this? I'd worry about reading a file from the fs everytime we need to start a server.

[graysonguarino]

Ah, I have no memory why I did it this way. I'll get on reworking this.

[graysonguarino]

I remember now: we need to do this if we want to put the prost-generated Rust Protobuf bindings in a non-default location (which, at compile time, is in target/build/.... If we want the ability to commit our generated code, we need to do something like this. https://docs.rs/tonic/latest/tonic/macro.include_file_descriptor_set.html

(Also, this explains the include!() above this: https://docs.rs/tonic/latest/tonic/macro.include_proto.html)

[graysonguarino]

Is tuxtape_database_bridge/grpc.rs intentionally empty?

Yes, that's getting fleshed out in the following PR.