What about mail templates, localization files and sql files (migrations)?

[arzonus]

Hi, guys!

Thanks for repo, it's useful. But I confused about a place of templates, localization files, sql files in the project structure. What do you think about that?

[kcq]

It depends on your application design. Those files might be in the same directory with your corresponding packages and/or tools. The /configs directory is another option (e.g., /configs/sql/, /configs/templates, /configs/localization). This is what I usually do. Good option if you are ok with those files as separate dependencies you load at run time. You can also make them root level directories (e.g., /sql, /templates, /localization). This is a good option too because it follows the /api directory pattern especially if you intend to embed those resources in your binary.

[sturfee-petrl]

I keep email templates at /assets because I thought it was exact place where it should be(?)

[kcq]

That's definitely an option too! Logos, images and other generic assets usually go there, but there's nothing prevents you from putting other things there :-)

[taisph]

It would be useful with common guideline for sql init and migration files. There are too many options. :laughing:

[unkeep]

@taisph, @kcq might be: a) scripts/pg-migrations (not sure scripts is intended to contain sql) b) db/pg-migrations (a new db top-level dir) c) assets/pg-migrations (I afraid assets would become a "trash" dir, if so let it be named etc right away)

[taisph]

I'm leaning towards /db or /sql. The former to avoid assuming the database is always SQL.

[kcq]

A top level /db makes sense (or /sql if you don't care about keeping it generic :-)).

Just for the fun of it i'll add another option: /api/db. Those sql file represent the data model for your data store and the /api folder, in general, is a good place for the data model and interface descriptions (with swagger, protobufs, json schema, sql, etc) :-)

[taisph]

Just for the fun of it i'll add another option: /api/db. Those sql file represent the data model for your data store and the /api folder, in general, is a good place for the data model and interface descriptions (with swagger, protobufs, json schema, sql, etc) :-)

I don't like the idea of putting db in the /api folder. There are go-based projects that do not necessarily have anything to do with serving an API but still uses a database backend.

/db (and /db/migrations) seems more like the right fit to me.

[sfaujour]

Im also at the point that there should be a /db folder in the root for fixtures/migrations.