División de código cliente / servidor

Estoy desarrollando una aplicación cliente / servidor en golang, y existen ciertas entidades lógicas que existen tanto en el cliente como en el servidor (la lista es limitada)

Me gustaría asegurar que cierto código para estas entidades se incluya ÚNICAMENTE en la parte del servidor, pero NO en el cliente (lo opuesto es bueno, pero no tan importante).

El pensamiento ingenuo sería confiar en la eliminación del código muerto, pero a partir de mi breve investigación no es una forma confiable de manejar la tarea … go build simplemente no eliminará el código muerto del hecho de que puede haber sido usado a través de la reflexión ( a nadie le importa que no haya sido y no hay opción para ajustar esto)

Un enfoque más sólido parece ser dividir el código en diferentes paquetes e importarlo apropiadamente, esto parece confiable, pero complica demasiado el código que te obliga a dividir físicamente ciertas entidades entre diferentes paquetes y constantemente tener esto en cuenta …

Y finalmente hay tags de comstackción que permiten tener múltiples archivos bajo el mismo paquete construido condicionalmente para el cliente y el servidor

La motivación con el uso de tags de comstackción es que deseo mantener el código lo más limpio posible sin introducir ninguna entidad sintética

Caso de uso: hay ciertas rutinas de criptografía, el cliente trabaja con clave pública, el servidor opera con privado … El código lógicamente pertenece a la misma entidad

¿Qué opción elegirías y por qué?

Esta “eliminación del código muerto” ya está hecha, en parte, por la herramienta ir. La herramienta ir no incluye todo, desde paquetes importados, solo lo que se necesita (o más precisamente: excluye cosas que puede resultar inalcanzable).

Por ejemplo, esta aplicación

 package main; import _ "fmt"; func main() {} 

resultados en casi 300 KB de binario ejecutable más pequeño (en Windows amd64) en comparación con los siguientes:

 package main; import "fmt"; func main() {fmt.Println()} 

Las cosas excluibles incluyen funciones, tipos e incluso variables no exportadas y exportadas. Esto es posible porque incluso con la reflexión no puede llamar a una función o “instanciar” tipos o referirse a variables de paquete simplemente teniendo sus nombres como un valor de string . Entonces quizás no deberías preocuparte tanto por eso.

Editar: con Go 1.7 lanzado, es aún mejor: leer la publicación del blog: Smaller Go 1.7 binarios

Entonces, si diseñas bien tus tipos y funciones, y no creas registros “gigantes” en los que enumeras funciones y tipos (que explícitamente generan referencias sobre ellos y los hacen incomprensibles), los binarios comstackdos solo contendrán lo que realmente se usa desde paquetes importados.

No recomendaría usar tags de comstackción para este tipo de problema. Al usarlos, usted tendrá la responsabilidad adicional de mantener las dependencias de paquete / archivo usted mismo, que de lo contrario lo hace la herramienta ir.

No debe diseñar y separar el código en paquetes para hacer que los ejecutables de salida sean más pequeños. Debe diseñar y separar el código en paquetes basados ​​en la lógica.

Me gustaría separar las cosas en paquetes cuando realmente se necesita, e importarlas apropiadamente. Porque esto es realmente lo que quiere: algún código destinado solo para el cliente, y solo para el servidor. Puede que tenga que pensar un poco más durante su fase de diseño y encoding, pero al menos verá el resultado (lo que realmente pertenece / se comstack en el cliente y en el servidor).

Intereting Posts