
Sponge เป็นกรอบการพัฒนา Go ทรงพลัง แนวคิดหลักของมันหมุนรอบรหัสโมดูลาร์แบบย้อนกลับ-วิศวกรรมโดยแยกวิเคราะห์ไฟล์ JSON , SQL หรือ Protobuf รหัสที่สร้างขึ้นสามารถประกอบไปด้วยความยืดหยุ่นและราบรื่นในบริการแบ็กเอนด์ที่สมบูรณ์แบบ (คล้ายกับลักษณะของเซลล์ฟองน้ำที่เซลล์ฟองน้ำที่ถอดประกอบสามารถรวมตัวกันเป็นฟองน้ำใหม่โดยอัตโนมัติ) Sponge จัดหาโซลูชันแบบครบวงจรสำหรับการพัฒนาโครงการครอบคลุมการสร้างรหัสการพัฒนาการทดสอบเอกสาร API และการปรับใช้เพิ่มประสิทธิภาพการพัฒนาอย่างมีนัยสำคัญลดความซับซ้อนและการเปิดใช้งานโครงการคุณภาพสูงด้วย "วิธีการรหัสต่ำ"
Sponge เหมาะสำหรับการพัฒนาบริการแบ็กเอนด์ที่มีประสิทธิภาพสูงอย่างรวดเร็วรวมถึง แต่ไม่ จำกัด เพียง:
Web (จิน);gRPC ;HTTP+gRPC ;gRPC Gateway API Servicesนอกจากนี้นักพัฒนาสามารถใช้เทมเพลตที่กำหนดเองเพื่อสร้างรหัสประเภทต่าง ๆ เพื่อตอบสนองความต้องการทางธุรกิจที่เฉพาะเจาะจง
รหัสบริการแบ็กเอนด์ที่สมบูรณ์แบบคลิกเดียว
สำหรับบริการ Web หรือ gRPC ที่ต้องการเฉพาะ CRUD APIs ไม่จำเป็นต้องเขียนรหัส Go เพียงเชื่อมต่อกับฐานข้อมูล (เช่น MySQL , MongoDB , PostgreSQL , SQLite ) เพื่อคลิกหนึ่งคลิกรหัสบริการแบ็กเอนด์ที่สมบูรณ์และปรับใช้กับเซิร์ฟเวอร์ Linux, Docker หรือ Kubernetes ได้อย่างง่ายดาย
การพัฒนาที่มีประสิทธิภาพของบริการอเนกประสงค์
เมื่อพัฒนา Web อเนกประสงค์, gRPC , HTTP+gRPC หรือ gRPC Gateway Services คุณต้องมุ่งเน้นไปที่สามด้านเท่านั้น:
รหัสเฟรมเวิร์กและรหัส CRUD API ทั้งหมดถูกสร้างขึ้นโดยฟองน้ำโดยอัตโนมัติ
รองรับเทมเพลตที่กำหนดเองนำเสนอการขยายความยืดหยุ่น
Sponge รองรับการสร้างรหัสเฉพาะโครงการประเภทต่าง ๆ โดยใช้เทมเพลตที่กำหนดเองไม่ จำกัด เฉพาะภาษา Go ตัวอย่างเช่น:
ติดตั้งฟองน้ำ
Sponge รองรับการติดตั้งบน Windows, MacOS และ Linux คลิกเพื่อดู คู่มือการติดตั้งฟองน้ำ
เปิด UI การสร้างรหัส
หลังจากการติดตั้งให้เรียกใช้คำสั่งต่อไปนี้เพื่อเปิดฟองน้ำ UI:
sponge run เข้าถึง http://localhost:24631 ในเบราว์เซอร์ท้องถิ่นเพื่อสร้างรหัสผ่านอินเตอร์เฟส UI ดังที่แสดงด้านล่าง:
หากต้องการเข้าถึงจากเบราว์เซอร์บนโฮสต์อื่นให้ระบุ IP หรือโดเมนโฮสต์เมื่อเริ่มต้น UI เช่น
sponge run -a http://your_host_ip:24631หรือคุณสามารถเรียกใช้บริการ UI ใน Docker เพื่อรองรับการเข้าถึงข้ามโฮสต์ คลิกเพื่อดูคำแนะนำในการรันบริการ SPONGE UI ใน Docker
Sponge รองรับการสร้างรหัสโดยใช้ทั้งเทมเพลตในตัวและเทมเพลตที่กำหนดเองดังแสดงในไดอะแกรมด้านล่าง
Sponge รองรับการสร้างบริการแบ็กเอนด์หกประเภทโดยใช้สถาปัตยกรรม Microservice แผนภาพด้านล่างแสดงให้เห็นถึงโครงสร้าง microservice แบบเลเยอร์ทั่วไปที่มีประสิทธิภาพสูงความสามารถในการปรับขนาดและความสามารถในการกำกับดูแลการบริการในตัว
การทดสอบประสิทธิภาพของรหัสบริการ HTTP และ GRPC ที่สร้างขึ้นโดย Microservices Framework: 50 พร้อมกัน 1 ล้านคำขอทั้งหมด
คลิกเพื่อดู รหัสทดสอบ
โครงสร้างไดเรกทอรีรหัสโครงการที่สร้างโดย Sponge เป็นไปตามโครงการ Layout
นี่คือโครงสร้างไดเรกทอรีสำหรับ monolithic application single repository (monolith) หรือ 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. นี่คือโครงสร้างไดเรกทอรีสำหรับรหัสที่เก็บ microservice monolithic repository (mono-repo) (หรือที่เรียกว่าโครงสร้างไดเรกทอรีที่เก็บขนาดใหญ่):
.
├── 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.คลิกเพื่อดูเอกสารรายละเอียดสำหรับโครงการพัฒนาฟองน้ำรวมถึงการสร้างรหัสการพัฒนาการกำหนดค่าและคำแนะนำการปรับใช้และอื่น ๆ
ถ้ามันช่วยคุณได้ให้เป็นดารา