English | 简体中文
Sponge is a powerful development framework that integrates code generation, Gin, and gRPC. It offers a rich set of code generation commands, allowing flexible creation of various functional modules that can be combined into complete services (similar to how scattered sponge cells can reorganize into a new sponge). Sponge provides an all-in-one solution for project development, covering code generation, development, testing, API documentation, and deployment, significantly enhancing development efficiency, reducing complexity, and enabling high-quality projects with a "low-code approach".
Sponge is used to quickly and efficiently develop high-performance back-end services for various application scenarios and requirements, including web services, gRPC services, http+gRPC hybrid services, gRPC gateway API services. Sponge not only supports code generation based on its built-in templates but also allows you to generate the necessary code for your project using custom templates and related parameters.
Sponge's core design concept is to reversely generate modular code through SQL or Protobuf files. These codes can be flexibly and seamlessly combined into various types of backend services, thus greatly improving development efficiency and simplifies the backend service development process:
- If you develop a web or gRPC service with only CRUD API, you don't need to write any go code to compile and deploy it to Linux servers, dockers, k8s, and you just need to connect to the database (e.g.,
mysql,mongodb,postgresql,sqlite) to automatically generate the complete backend service go code by sponge. - If you develop general web, gRPC, http+gRPC, gRPC gateway services, you only need to focus on the three parts of
define tables in the database,define API description information in the protobuf file, andfill in business logic code in the generated template file, and other go codes (including CRUD api) are generated by sponge. - Generate the necessary code for your project (not limited to Go language) through custom templates and parameters (such as JSON, SQL, Protobuf), such as backend code, frontend code, configuration files, test code, build and deployment scripts, etc.
The code generation framework based on Sponge's built-in templates is shown below. There are two approaches: SQL and Protobuf.
The code generation framework based on custom templates is shown below. There are three approaches: JSON, SQL, and Protobuf.
The service code generated by sponge is itself a microservice, the framework diagram is shown below, which is a typical microservice hierarchical structure, with high performance, high scalability, contains commonly used service governance features, you can easily replace or add their own service governance features.
Performance testing of http and grpc service code created by the microservices framework: 50 concurrent, 1 million total requests.
Click to view the test code.
- Web framework gin
- RPC framework grpc
- Configuration parsing viper
- Logging component zap
- Database ORM component gorm, mongo-go-driver
- Cache component go-redis, ristretto
- Automated API documentation swagger, protoc-gen-openapiv2
- Authentication jwt
- Websocket gorilla/websocket
- Crontab cron
- Message Queue rabbitmq, kafka
- Distributed Transaction Manager dtm
- Distributed lock dlock
- Parameter validation validator
- Adaptive rate limiting ratelimit
- Adaptive circuit breaking circuitbreaker
- Distributed Tracing opentelemetry
- Metrics monitoring prometheus, grafana
- Service registration and discovery etcd, consul, nacos
- Adaptive collecting profile
- Resource statistics gopsutil
- Configuration center nacos
- Code quality checking golangci-lint
- Continuous integration and deployment jenkins, docker, kubernetes
- Generate project business architecture diagram spograph
- Custom template generation code go template
The project code directory structure created by sponge follows the project-layout.
Here is the directory structure for the generated monolithic application single repository (monolith) or microservice multi-repository (multi-repo) code:
.
├── 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.Here is the directory structure for the generated microservice monolithic repository (mono-repo) code (also known as large repository directory structure):
.
├── 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.Sponge can be installed on Windows, macOS, Linux and Docker environments. Click here for instructions on installing sponge.
After installing the sponge, start the UI service:
sponge runAccess http://localhost:24631 in a local browser and manipulate the generated code on the UI page.
If you want to access it on a cross-host browser, you need to specify the host ip or domain name when starting the UI, example
sponge run -a http://your_host_ip:24631. It is also possible to start the UI service on docker to support cross-host access, Click for instructions on starting the sponge UI service in docker.
Click to view the detailed documentation for Sponge development project, including code generation, development, configuration, and deployment instructions, and more.
- Create web service based on sql (including CRUD)
- Create grpc service based on sql (including CRUD)
- Create web service based on protobuf
- Create grpc service based on protobuf
- Create grpc gateway service based on protobuf
- Create grpc+http service based on protobuf
If it's help to you, give it a star ⭐.