0

Let's say I have a simple bookstore CRUD api with gRPC. It consists of a book protobuf message

message Book {
  string id = 1;
  string title = 2;
  Author author = 3;
} 

message Author {
  string name = 1;
}

I want to persist the books in a database. The records should be searchable and hence I cannot store them as bytes. As I see there are two ways to do it

  1. Convert to JSON and store: This works well for document databases. But in my applications, I always work with drivers/ORMs which impose some language-specific restrictions (like for mongo bson:"_id" tag for primary key in golang, @Document annotation for spring-data-mongo). This requires modifying the message and custom conversion logic

  2. Create a corresponding struct/class: I can create a wrapper struct/class for the message and then write a mapper to map messages to these structs. The good thing here is you can pull all of your custom logic add more fields in these struct/classes. But we have to maintain these mappers

type BookWrapper struct{
  ID string // remove this from book message and add here
  Book
  createdAt int64 //extra props 
}

Wanted to validate and check what is the correct/idiomatic way (personally inclined towards second) to achieve persistence.

ptwo
  • 461
  • 4
  • 13
  • 1
    There are a lot of different ways of solving this, so I don't think it has an answer, as such; you could normalize the entire data to RDBMS table/s layout, for storage and search. You could make it the problem of an index service such as elastic/lucene. Or anything in between. – Marc Gravell Oct 23 '21 at 08:47
  • 1
    There are many ways but generally you'll want to create app-specific types and map these to|from Protobuf on-the-wire messages and map these to|from your favorite storage mechanism. This way, there's more to|from but you more loosely coupled. – DazWilkin Oct 24 '21 at 00:44

0 Answers0