Convenciones de nomenclatura de repositorys para aplicaciones web

Tengo una aplicación web que, como de costumbre, se divide en dos partes: del lado del server y del lado del cliente.

Me gusta trabajar con convenciones internacionales de nombres para todo, y he estado tratando de encontrar algunas convenciones sobre cómo nombrar mis repositorys.

¿Qué debería nombrar mis repositorys en GitHub?

del lado del server – Para la aplicación del lado del cliente del lado del cliente – Para la aplicación del lado del cliente

También escuché a alguien decir que el repository del lado del server debería llamarse API.

¿Es eso correcto? ¿Qué harían ustedes chicos?

Supongo que estás desarrollando una aplicación que pertenece a todos. El server y el lado del cliente están relacionados entre sí. Esto significa para mí tener un único repository llamado "Aplicación" que contiene tanto el server como el lado del cliente.

"server-side" y "client-side" suenan genial para mí.

Con las convenciones de nombres, si tienes que pensar más de 1 minuto sobre ellos, ¡estás pensando demasiado! Solo asígnele un nombre para que se explique por sí mismo y sea claro, especialmente para usted: a nadie más le importará tanto como a usted. Además, los nombres siempre se pueden cambiar fácilmente más tarde.

Las convenciones de layout del proyecto varían entre idiomas y sistemas de compilation.

Por ejemplo, una aplicación web java simple podría verse así al usar el sistema de compilation Maven.

appname |-- pom.xml `-- src `-- main |-- java | `-- com | `-- company | `-- appname | `-- Controller.java `-- webapp `-- view.jsp 

view.jsp es la vista lateral del cliente y Controller.java es la lógica de negocios del lado del server.