What about mail templates, localization files and sql files (migrations)? about project-layout HOT 9 OPEN

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

from project-layout.

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.

from project-layout.

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

from project-layout.

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.

from project-layout.

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 :-)

from project-layout.

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

from project-layout.

@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)

from project-layout.

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

from project-layout.

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) :-)

from project-layout.