Add app-proto service with submission proto, helpers

[haworku]

Summary

Adds app-proto service and a submission.proto definition. Also includes utilities to encode/decode from Typescript domain model.

Related issues

https://qmacbis.atlassian.net/browse/OY2-12158

.proto file general notes

• not using required at all
• repeated means this is an array
• field numbers 1-15 are for the most accessed fields (see docs on field numbers)

.proto file styles and formatting

See styling guide - we are linting on this with protolint. It is in the precommit config, also can be added as vscode extension.

• repeated fields are pluralized (have an s)
• enums use prefix specific to their field name. Use UNSPECIFIED as default value. Field names are CamelCase (with an initial capital)and values are CAPITALS_WITH_UNDERSCORES. see docs
• order at top of file matters.

To Do:

• add support for the date mm/dd/yyyy format we use for certain dates
• consider if pulling out separate proto files is helpful - if so, on what boundaries
• figure out helpers and tests

[macrael]

Great job laying out the submission in proto form, I put some questions inline but it looks like it’s all there, to me.

Generation:

• to match app-graphql, I think that there should be a command that installs the generated files inside of app-api/gen/
• Also, we should have a watching version of that command, I forget what that npm tool you used to do that with the proto/avero exploration project but that would work here. That way we can call that from ./dev like we do with the graphql compiler
• I think the conversion methods (+ tests) between domain model and proto could live here or could live in app-api which is where we’re going to call them.

Coding

• I don’t really like “helpers” as a name here, the functions are going to pretty specifically be involved in encoding / decoding so some kind of name that matches that would be better

Testing

• There’s a couple different ways we could do some tests. The easiest way to start is to get some sample valid domain models (do we have some of those for the api tests already?) and write tests that just take that, serialize it, deserialize that, and confirm that what came out is the same as what went in.
• After we’ve got the basics working, we could write some tests that confirm that we can read serailized versions of the data. We can generate a bunch of serialized DraftSubmissions and save them as test files, then we can write tests where we deserialize them and check that we get what we expect out.

[macrael]

Re: optional stuff. I also dont’ totally understand what the tradeoffs are. It seems like from reading that article that without “optional” it’s not possible to query the proto message to see if a field even exists in that message as compared to it just being unset. I’m not sure how that plays out in our usecase though, so if it’s not getting in your way I’d say ignore it and move on. We can add it back later if we decide we need it.

[macrael]

I believe this is ready for review. Changes since @haworku put it down:

• I moved all the code into /common-code, I think that keeping the package there with tests inside makes the most sense for its future use
• I picked a strategy for dealing with the types of our different things. Since every single field in the proto can be null or undefined, when we are constructing our domain models where that is not the case, we instead construct at RecursivePartial. That way we get types at least for all the fields, and then after we have that we validate that everything that is required is present
• Fundamentally, we are converting between two different types at runtime. That sounds like we need a runtime validator, like yup.
• That validation is being done with Zod for now. Zod is very much like yup, so I'd like for us to standardize on one rather than the other. For now I'm trialing zod b/c it's more typescript aware, just to compare them. The likely move is to just use yup everywhere since we're already relying on it in our forms. Might lose a little type safety but that's probably alright.

[haworku]

Should we export and unit test these types of functions? feels like there significant branching logic here

[haworku]

Can we pull out something like calculateRateInfo as a function instead of everything happening inline. There's a lot going on here. That way cleanedRateInfo = calculateRateInfo(rateInfos)

[haworku]

Tests look good. Tried to add more descriptive test assertions - feels free to change or ignore. I cannot approve this since it is my branch so @macrael will have to approve and merge.

[haworku]

I like this listing of the reasons why transform functions are needed. That especially feels like something we could quickly forget

[macrael]

Approving this per @haworku