Skip to content

REST API for offer exchange SaaS with stripe subscriptions and modular architecture

Notifications You must be signed in to change notification settings

snax4a/offer-exchange-webapi

Repository files navigation

Features

  • Built on .NET 6.0
  • Follows Clean Architecture Principles
  • Domain Driven Design
  • Multi Tenancy Support with Finbuckle
    • Create Tenants with Multi Database / Shared Database Support
    • Activate / Deactivate Tenants on Demand
    • Upgrade Subscription of Tenants - Add More Validity Months to each tenant!
  • Supports MySQL, MSSQL, Oracle & PostgreSQL!
Click to See More!
  • Uses Entity Framework Core as DB Abstraction
  • Flexible Repository Pattern
  • Dapper Integration for Optimal Performance
  • Serilog Integration with various Sinks - File, SEQ, Kibana
  • OpenAPI - Supports Client Service Generation
  • Mapster Integration for Quicker Mapping
  • API Versioning
  • Response Caching - Distributed Caching + REDIS
  • Fluent Validations
  • Audit Logging
  • Advanced User & Role Based Permission Management
  • Code Analysis & StyleCop Integration with Rulesets
  • JSON Based Localization with Caching
  • Hangfire Support - Secured Dashboard
  • File Storage Service
  • Test Projects
  • JWT & Azure AD Authentication
  • MediatR - CQRS
  • SignalR Notifications
  • & Much More

Documentation

Read Documentation related to this Boilerplate here - https://docs.conetso.com/offer-exchange

Getting Started

Make sure that your DEV enviroment is setup, Read the Development Environment Guide

For further steps and details, Read the Getting Started Guide

Generate test data with the Stripe CLI

The Stripe CLI fixtures command executes a series of API requests defined in a JSON file. To speed up the setup, we have added a fixtures file to bootstrap test product and pricing data in your Stripe account.

Simply run: stripe fixtures src/Infrastructure/PaymentGateways/Stripe/Fixtures/create-products-fixtures.json.

Important Links & Documentations

Changelogs

View Complete Changelogs.

Commit Message Convention

This website follows Conventional Commits

Commit message will be checked using husky and commit lint, you can't commit if not using the proper convention below.

Format

<type>(optional scope): <description> Example: feat(pre-event): add speakers section

1. Type

Available types are:

  • feat → Changes about addition or removal of a feature. Ex: feat: add table on landing page, feat: remove table from landing page
  • fix → Bug fixing, followed by the bug. Ex: fix: illustration overflows in mobile view
  • docs → Update documentation (README.md)
  • style → Updating style, and not changing any logic in the code (reorder imports, fix whitespace, remove comments)
  • chore → Installing new dependencies, or bumping deps
  • refactor → Changes in code, same output, but different approach
  • ci → Update github workflows, husky
  • test → Update testing suite, cypress files
  • revert → when reverting commits
  • perf → Fixing something regarding performance (deriving state, using memo, callback)
  • vercel → Blank commit to trigger vercel deployment. Ex: vercel: trigger deployment

2. Optional Scope

Labels per page Ex: feat(pre-event): add date label

*If there is no scope needed, you don't need to write it

3. Description

Description must fully explain what is being done.

Add BREAKING CHANGE in the description if there is a significant change.

If there are multiple changes, then commit one by one

  • After colon, there are a single space Ex: feat: add something
  • When using fix type, state the issue Ex: fix: file size limiter not working
  • Use imperative, dan present tense: "change" not "changed" or "changes"
  • Don't use capitals in front of the sentence
  • Don't add full stop (.) at the end of the sentence

About

REST API for offer exchange SaaS with stripe subscriptions and modular architecture

Resources

Stars

Watchers

Forks

Packages

No packages published

Languages