English | 简体中文
Sponge is a powerful Go development framework. Its core concept revolves around reverse-engineering modular code by parsing SQL, Protobuf, and JSON files. The generated code can be flexibly and seamlessly assembled into various types of complete backend services (similar to the characteristics of sponge cells, where disassembled sponge cells can automatically recombine into a new sponge).
Sponge provides an all-in-one solution for project development with outstanding engineering capabilities, 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 suitable for quickly developing various high-performance backend services, including but not limited to:
Webservices (gin);gRPCservices;HTTP+gRPChybrid services;gRPC Gateway APIservices;- cloud-native microservices.
Additionally, developers can use custom templates to generate various types of code to meet specific business needs.
-
One-click generation of complete backend service code
ForWeborgRPCservices that only requireCRUD APIs, noGocode needs to be written. Simply connect to a database (e.g.,MySQL,MongoDB,PostgreSQL,SQLite) to one-click generate complete backend service code and easily deploy it to Linux servers, Docker, or Kubernetes. -
Efficient development of general-purpose services
When developing general-purposeWeb,gRPC,HTTP+gRPC, orgRPC Gatewayservices, you only need to focus on three aspects:- Defining database tables;
- Defining API descriptions in Protobuf files;
- Writing business logic code in the generated templates.
The framework code and CRUD API code are all automatically generated by sponge.
-
Support for custom templates, offering flexible extensibility
Sponge supports generating various types of project-specific code using custom templates, not limited to theGolanguage. For example:- Backend code;
- Frontend code;
- Configuration files;
- Test code;
- Build and deployment scripts, etc.
-
Generate code on the page, simple and easy to use
Sponge allows code generation directly on the page, making it simpler and more user-friendly than using the command line. You only need to fill in the relevant parameters on the page to generate code with one click. -
Built-in AI assistant generates business logic implementation code
Sponge comes with a built-in AI assistant (ChatGPT and DeepSeek), combining the strengths of both to form a comprehensive and efficient development solution:- Sponge: Handles infrastructure code generation (service framework, CRUD API interfaces, and custom API interfaces without business logic implementation).
- DeepSeek or ChatGPT: Focuses on business logic implementation (table structure DDL design, custom API interface definition, and business logic implementation code).
-
Install sponge
Sponge supports installation on Windows, macOS, and Linux. Click to view the sponge installation guide.
-
Open the code generation UI
After installation, run the following command to open the sponge UI:
sponge run
Access
http://localhost:24631in a local browser to generate code through the UI interface, as shown below:To access from a browser on a different host, specify the host IP or domain when starting the UI, e.g.,
sponge run -a http://your_host_ip:24631. Alternatively, you can run the UI service in Docker to support cross-host access. Click to view the guide on running the sponge UI service in Docker.
Sponge has built-in rich features and components (for on-demand use):
Sponge supports generating code using both built-in templates and custom templates, as shown in the diagrams below.
- 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.
Five of the six types of back-end services created by sponge are microservice architectures. The diagram below illustrates a typical layered microservice structure, featuring high performance, scalability, and built-in service governance capabilities.
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.
The project code directory structure created by sponge follows the project-layout.
Sponge supports creating three types of project code structures: Monolithic application monorepo (monolith), Microservices multi-repo (multi-repo), and Microservices monorepo (mono-repo).
-
The code directory structure for creating a
Monolithic application monorepo (monolith)orMicroservices multi-repo (multi-repo)is as follows:. ├── 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.
-
The code directory structure for creating a
Microservices monorepo (mono-repo)(large repository code directory structure) is as follows:. ├── 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.
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 ⭐.