-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Webhook, Signature verfication integration & refactored structure #5
Open
BigBr41n
wants to merge
24
commits into
Chargily:main
Choose a base branch
from
BigBr41n:main
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ced scalability and clarity - Refactored chargily.go by dividing it into separate files: params.go, responses.go, and types.go. - Moved these model files into a newly created models package to improve separation of concerns. - Enhanced maintainability and clarity by organizing related structures and defintions.
…he chargily objects types
…_errors.go) in one utils folder for more calrity and structure organization
Refactor/utils
Moved all methods into dedicated files to enhance organization. Refactored the Client struct to provide a unified interface for accessing all SDK functionalities, improving usability and maintainability.
Moved individual functions into separate files for better organization. Implemented a consistent interface across different entities, allowing unified access to functions such as customers.get(), products.get(), customers.create(), and prices.create(). This enhances usability and simplifies interaction with the SDK.
Refactor/client/services
…ocus. using the new updates made to the project
…ocus. using the new updates made to the project
…amples making it more easy to read and understand the logic flow.
Update/examples
…tData & webhook event type
…te & a public method the verify the signature sent by chargily
…ature verification
New/webhook/signature-verifier
…nts ...), params & returns explained. example for each function of the services
Update/docs/examples
Refactor/improve architecture
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This pull request introduces a significant refactor of the
chargily
client, aimed at enhancing the code's modularity, scalability, and maintainability. The architecture has been improved by dividing the client into multiple atomic files, which encapsulate functionalities more clearly. Additionally, the webhook integration and signature verification functionality has been implemented to ensure the integrity of webhook events. TheREADME.md
has been condensed for clarity, and a newdocs
directory has been created to provide detailed documentation for each service.Key Changes
Client Refactor:
The client code has been organized into multiple files, making it easier to navigate and maintain. This atomic structure helps to isolate different functionalities and adhere to the single responsibility principle.
Each service (e.g., Payment Links, Checkouts, Webhook) now resides in its own file, promoting better scalability and clearer architecture.
Webhook & Signature Verification:
Webhook now is supported with the signature verification functionality.
The verification logic implemented and uses HMAC with SHA-256, providing a robust method for signature validation as mentioned in Chargily Webhook documentation.
Updated README.md:
README.md
has been streamlined to focus on essential information, improving the onboarding experience for new developers and contributors.Documentation Improvements:
A new
docs
folder has been added, containing comprehensive documentation for each service within the client.Each service documentation includes details about available methods, parameters, return types, and examples where applicable. This change enhances the usability and understanding of the client for both current and future developers.
Unified Usage Pattern:
All services now use a unified usage pattern, developers use the functionalists directly after initialize the client :
client.Customers.GetAll()
,client.Products.GetAll()
,client.Checkouts.Create()
.....this implemented method makes the usage of the SDK more easy and remembering the function much easier.
Examples Refactor:
refactoring the examples folder to more clean and clear examples , implementing the new functionalities and the unified usage pattern.
This refactor make it more easy to navigate between the examples and understand the usage.
Models and Types:
Dividing chargily.go file (types file) into (params , responses, types) in separate folder with its own packages. This refactor allow for shared models across the SDK and enhance the developers experience.
More clean structure for future scaling and maintaining.
Benefits of the Refactor
Modularity: The atomic file structure allows developers to work on specific parts of the client and models files without impacting unrelated components.
Scalability: The clear organization of files and documentation will facilitate easier future enhancements and modifications.
Maintainability: Improved documentation and modularity reduce the cognitive load for developers, making it easier to understand and maintain the codebase.