sponge
v1.12.1
La esponja es un poderoso marco de desarrollo Go . Su concepto central gira en torno a los archivos modulares de ingeniería inversa mediante la analización de archivos JSON , SQL o Protobuf . El código generado se puede ensamblar de manera flexible y perfecta en varios tipos de servicios completos de backend (similar a las características de las células de la esponja, donde las células de esponja desmontadas pueden recombinarse automáticamente en una nueva esponja). La esponja proporciona una solución todo en uno para el desarrollo de proyectos, que cubre la generación de códigos, el desarrollo, las pruebas, la documentación de API y la implementación, mejorando significativamente la eficiencia del desarrollo, la reducción de la complejidad y permitiendo proyectos de alta calidad con un "enfoque de bajo código".
La esponja es adecuada para desarrollar rápidamente varios servicios de backend de alto rendimiento, incluidos, entre otros,:
Web (GIN);gRPC ;HTTP+gRPC ;gRPC Gateway API Services.Además, los desarrolladores pueden usar plantillas personalizadas para generar varios tipos de código para satisfacer las necesidades comerciales específicas.
Generación de un solo clic de código de servicio de backend completo
Para los servicios Web o gRPC que solo requieren CRUD APIs , no se necesita escribir código Go . Simplemente conéctese a una base de datos (por ejemplo, MySQL , MongoDB , PostgreSQL , SQLite ) para generar un solo clic en el código de servicio completo de backend e implementarlo fácilmente en servidores Linux, Docker o Kubernetes.
Desarrollo eficiente de servicios de propósito general
Al desarrollar Web de uso general, gRPC , HTTP+gRPC o gRPC Gateway Services, solo necesita centrarse en tres aspectos:
El código de marco y el código API CRUD son generados automáticamente por Sponge.
Soporte para plantillas personalizadas, ofreciendo una extensibilidad flexible
La esponja admite la generación de varios tipos de código específico del proyecto utilizando plantillas personalizadas, no limitadas al idioma Go . Por ejemplo:
Instalar una esponja
La esponja admite la instalación en Windows, MacOS y Linux. Haga clic para ver la guía de instalación de la esponja .
Abra la interfaz de usuario de la generación de código
Después de la instalación, ejecute el siguiente comando para abrir la ui de la esponja:
sponge run Access http://localhost:24631 en un navegador local para generar código a través de la interfaz de UI, como se muestra a continuación:
Para acceder desde un navegador en un host diferente, especifique la IP o el dominio del host al iniciar la UI, por ejemplo,
sponge run -a http://your_host_ip:24631. Alternativamente, puede ejecutar el servicio UI en Docker para admitir el acceso a host cruzado. Haga clic para ver la guía sobre la ejecución del servicio de interfaz de usuario de la esponja en Docker.
La esponja admite la generación de código utilizando plantillas incorporadas y plantillas personalizadas, como se muestra en los diagramas a continuación.
Sponge admite la creación de seis tipos de servicios de backend, todos basados en la arquitectura de microservicio. El siguiente diagrama ilustra una estructura de microservicio en capas típica, con un alto rendimiento, escalabilidad y capacidades de gobernanza de servicios incorporadas.
Prueba de rendimiento del código de servicio HTTP y GRPC creado por el Marco de Microservices: 50 solicitudes concurrentes, 1 millón de total.
Haga clic para ver el código de prueba .
La estructura del directorio de código de proyecto creado por Sponge sigue el proyecto de proyecto.
Aquí está la estructura del directorio para el código de monolithic application single repository (monolith) o microservice multi-repository (multi-repo) :
.
├── api # Protobuf files and generated * pb.go directory
├── assets # Store various static resources, such as images, markdown files, etc.
├── cmd # Program entry directory
├── configs # Directory for configuration files
├── deployments # Bare metal, docker, k8s deployment script directory.
├── docs # Directory for API interface Swagger documentation.
├── internal # Directory for business logic code.
│ ├── cache # Cache directory wrapped around business logic.
│ ├── config # Directory for Go structure configuration files.
│ ├── dao # Data access directory.
│ ├── database # database directory.
│ ├── ecode # Directory for system error codes and custom business error codes.
│ ├── handler # Directory for implementing HTTP business functionality (specific to web services).
│ ├── model # Database model directory.
│ ├── routers # HTTP routing directory.
│ ├── rpcclient # Directory for client-side code that connects to grpc services.
│ ├── server # Directory for creating services, including HTTP and grpc.
│ ├── service # Directory for implementing grpc business functionality (specific to grpc services).
│ └── types # Directory for defining request and response parameter structures for HTTP.
├── pkg # Directory for shared libraries.
├── scripts # Directory for scripts.
├── test # Directory for scripts required for testing services and test SQL.
├── third_party # Directory for third-party protobuf files or external helper programs.
├── Makefile # Develop, test, deploy related command sets .
├── go.mod # Go module dependencies and version control file.
└── go.sum # Go module dependencies key and checksum file. Aquí está la estructura del directorio para el código de microservice monolithic repository (mono-repo) (también conocido como estructura de directorio de repositorio de gran):
.
├── api
│ ├── server1 # Protobuf files and generated *pb.go directory for service 1.
│ ├── server2 # Protobuf files and generated *pb.go directory for service 2.
│ ├── server3 # Protobuf files and generated *pb.go directory for service 3.
│ └── ...
├── server1 # Code directory for Service 1, it has a similar structure to the microservice multi repo directory.
├── server2 # Code directory for Service 2, it has a similar structure to the microservice multi repo directory.
├── server3 # Code directory for Service 3, it has a similar structure to the microservice multi repo directory.
├── ...
├── third_party # Third-party protobuf files.
├── go.mod # Go module dependencies and version control file.
└── go.sum # Go module dependencies' checksums and hash keys.Haga clic para ver la documentación detallada para el proyecto de desarrollo de la esponja, incluidas la generación de códigos, el desarrollo, la configuración y las instrucciones de implementación, y más.
Si es ayuda para ti, dale una estrella.
