go - redirection - property $key does not exist on this collection instance laravel

División de código cliente/servidor

Question

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 asegurarme de que cierto código para estas entidades se incluya SOLO en la parte del servidor, pero NO en el cliente (por el contrario, es bueno, pero no tan importante).

La idea ingenua sería confiar en la eliminación del código muerto, pero de mi breve investigación no es una forma confiable de manejar la tarea ... go build simplemente no eliminará el código muerto por el hecho de que puede haber sido utilizado a través de la reflexión ( a nadie le importa que no lo sea y no hay opción para ajustar esto)

Un enfoque más sólido parece estar dividiendo el código en diferentes paquetes e importando adecuadamente, esto parece confiable pero complica demasiado el código que lo obliga a dividir físicamente ciertas entidades entre diferentes paquetes y tener esto siempre presente ...

Y, por último, hay etiquetas de compilación que permiten tener múltiples archivos bajo el mismo paquete creado condicionalmente para cliente y servidor

La motivación con el uso de etiquetas de compilación es que quiero mantener el código lo más limpio posible sin introducir entidades sintéticas

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

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

Answer 1

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

Por ejemplo esta aplicación

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

da como resultado un binario ejecutable casi 300 KB más pequeño (en Windows amd64) en comparación con lo siguiente:

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: lea la publicación de blog: binarios de Smaller Go 1.7

Entonces, si diseña bien sus tipos y funciones, y no crea registros "gigantes" donde enumera funciones y tipos (que explícitamente genera referencias a ellos y, por lo tanto, los convierte en no excluibles), los binarios compilados solo contendrán lo que realmente se utiliza paquetes importados

No sugeriría usar etiquetas de compilación para este tipo de problema. Al usarlos, tendrá la responsabilidad adicional de mantener las dependencias de paquete / archivo usted mismo, que de lo contrario se hace con la herramienta go.

No debe diseñar y separar el código en paquetes para hacer que sus 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 importar adecuadamente. Porque esto es realmente lo que quieres: algunos códigos destinados solo para el cliente, algunos solo para el servidor. Puede que tenga que pensar un poco más durante su fase de diseño y codificación, pero al menos verá el resultado (lo que realmente pertenece / se compila en el cliente y en el servidor).