Add Swate template storage based on validation package design

[Freymaurer]

@Freymaurer.

[kMutagene]

As discussed, coupling of Swate templates has not much short to mid-term value, therefore let's postpone this

[Freymaurer]

Uhm, i thought this issue was more reuse the validation package storage logic? Which i still like a lot @kMutagene

[kMutagene]

Uhm, i thought this issue was more reuse the validation package storage logic?

then i misunderstood, sorry. However to integrate in this repo we would still need to kind of merge validation packages and templates, which i think we opted against.

Do you think we should reopen here and discuss further or open an issue on the template repo to implement the same backend/api logic?

[Freymaurer]

of merge validation packages and templates,

I do not think this is required.

Do you think we should reopen here and discuss further or open an issue on the template repo to implement the same backend/api logic?

We absolutly can!

The idea i had is, to keep templates on their own repo but taget the same server, with similiar logic as you already implemented for validation packages.

[kMutagene]

but target the same server

this is what i mean with merging. If we target the same backend we need to develop the backend in the same repo, or how do you envision this?

[kMutagene]

Or do you mean we deploy to the same production instance? either way, at least the database for template storage would need to be in this repo i think. You could do the CI release pipeline in the template repo though, although it is way more convenient to have the datamodels in the same repo as the backend

[Freymaurer]

I would do all server/backende related stuff here but publish from a different repo. Because templates are not equally dangerous to publish as are scripts that will be downloaded.

[kMutagene]

Okay, sounds good, but i still think it means merging almost everything to be beneficial.

Here is my reasoning. Incorporating templates IMO would look like this:

DB & Backend

• Add a data model for templates.
  • Here is the ValidationPackage data model for reference. New models that will be their own table also need to be added as DbSet here
  • Note that this is basically a code-first approach using EFCore, so our database gets created based on the data model. This also means that we have to create migrations when we change the data model to have a safe way of updating the production DB. Here is an example for a migration that added a table. Note that these are usually auto-generated by the dotnet ef cli tool.
• Add endpoint groups and handlers
  • I currently group API endpoint here and their respective handlers (functions that are called when traffic comes in on the respective route) here, these should give pretty clear guidance e.g. on how to implement something like GetAllTemplates
  • Add OpenAPI annotation to these endpoints
• Add SSR for a browsing frontend (?)
  • do we want this? I think it would be cool
  • This is currently the most basic code in this repo, as it just does some string manipulation to render static sides server-side. I want to move this to RazorPages eventually (#25), which is basically typed html templates.

Client and Domains for consuming apps

Here it becomes a little bit tricky and also shows that the separation of the repos is not that clear anymore.

The Client library for the API is auto-generated from the OpenAPI spec, which would mean that the Client application for consuming templates would be generated in and released from this repo.

There is also a Domain model library that offers the types without the EFCore overhead and also some convenience (e.g. downloading the latest preview index from this repo's releases). I think this also only makes sense to do in this repo, because you really do not want to test this across repos (been there, hated it, moved stuff here).

Bottom line

At the end of the day this means everything code-wise would merge into this repo, leaving the templates repo simply as the staging area for developing and releasing templates. We can do that, but i do not see why not then also move the template staging area here (other than single-focus issues and potential bloated CI/CD)