Sys-account: We need the GRPC JWT to now work

[joe-getcouragenow]

Now we add grpc with JWT.

Reference example if you need it: https://dev.to/techschoolguru/use-grpc-interceptor-for-authorization-with-jwt-1c5h

Logic all here: https://github.com/getcouragenow/packages/blob/master/sys-core/DEV.md

• dont forget sys-account has its own DB Table prefix.

maintemplate2

maintemplate loads up NATS etc and other things that we dont want for V2. So make a maintemplate2 - Just copy maintemplate

• strip out the NATS crap and anything else.
• Copy the "ci.yaml" in github actions and make a "ci-maintemplate2". Make sure it builds on a PR and that is calls the make file "this-build" in maintemplate2

sys-account

Make a sys-account. Just take mod-account and find / replace.

Make sure we have a golang CLI, so that we know native GRPC works also. There is a nice CLI generator that works off the GRPC. See: https://github.com/getcouragenow/packages/tree/master/sys-core/dev/grpc-gen/ex/cmd/NathanBaulch__protoc-gen-cobra

• From GRPC it can gen the cobra CLI stuff. Will save a ton of time.
• Evans also might be useful, but if the golang CLI works its probably enough i think.

Dont forget that the GRPCWeb and GRPC have different URLS. You can see it here: https://maintemplate.ci.getcouragenow.org/#/settings

• I cant remember why, but we know it works so lets stick with it.

Client Config

Which leads on to the client config .

We have that sed thing to make the client config at CI time. It gave use trouble last sprint. I think we will just use a simple golang and Json approach to replace it. So if the make build works locally the same works in CI also.

Its used the env.json if i recall.

sys-messenger

gomessanger

• How about we put it in sys-messenger ? Sure the import paths will change but that minor.
• We can use it as a nice way to test that sys-account and sys-core work, and its independent of maintemplate and mod-main.

Data generator

I think that its worthwhile that since we are building the domain model for this, that we should add the data generator. Its worth it because in order to really play with and know sys-accounts works you want to have 10 Orgs and 10 projects in each org i feel.

See here: https://github.com/getcouragenow/packages/tree/master/sys-core/dev/grpc-gen/ex/data/sayboras__zds Its faker working off a Domain model with a CLI. Looks perfect for us. Just copy his code and put where it makes sense for you.

For now the CLI it generates is fine, and you locally run it to pump data into the DB. I can then get Rosie to make a new folder for data and make test data that conforms to the Customer data. So what i am intending is to use this data generator to make the developers test data and then it shows rosie how she needs to make her real data. SO then we can use this for the /sys/data boostrapper also later. Make sense ?

[WinWisely268]

starting

[WinWisely268]

Data Models

As specified in the #633, the User data models can contain many fields that cannot be determined during design / compile time. As such the data model for the User will and should be as flexible as it could.

Protobuf schema for the User record then should be using map<string,any> which would be translated as map[string]interface{} on golang side of things.

TODO

Schemaless data/seed generator

[WinWisely268]

see comment on PR #652

[ops-amplifycms]

@WinWisely268 thanks