The Management Products API is a Laravel-based web application that allows users to manage products in a database.
To get started with the Management Products API, follow these steps:
- Clone the repository:
git clone https://github.com/codingcab/ShipTown.git - Navigate to the project directory:
cd ShipTown - Install dependencies:
composer install - Copy the
.env.examplefile to.env:cp .env.example .env - Generate a new application key:
php artisan key:generate - Create a new MySQL database for the application and update the
.envfile with your database credentials - Run database migrations:
php artisan migrate - Start the application:
php artisan serve
The Management Products API uses token-based authentication to secure API endpoints. To authenticate, send a POST request to the /api/auth/login endpoint with your email and password in the request body. The API will return a JSON response containing your authentication token. To access authenticated endpoints, include your token in the Authorization header of your requests.
The Management Products API uses HTTP status codes to indicate the success or failure of requests. Successful requests will return a 200 OK status code, while unsuccessful requests will return an appropriate error code (e.g. 400 Bad Request, 401 Unauthorized, 404 Not Found, etc.). In addition, error messages will be included in the response body.
Contributions to the Management Products API are welcome! To contribute, please follow these steps:
- Fork the repository.
- Create a new branch for your changes:
git checkout -b my-new-branch - Make your changes and commit them:
git commit -am 'Add some feature' - Push to the branch:
git push origin my-new-branch - Submit a pull request.
Please ensure that your code follows the existing coding style and includes tests for any new functionality.
The Management Products API is open source software licensed under the MIT license. Please see the LICENSE file for more details.
If you have any questions or issues with the Management Products API, please contact the project owner at [email protected].
- Core functionality it's Inventory Management of stock
- Each product should have a unique SKU (products.sku)
- Each product might have multiple barcodes (products_aliases)
- We can have multiple locations (warehouses)
- Each product can be in multiple locations (inventory)
- Each inventory can have multiple reservations (inventory_reservations)
- We import orders from multiple sources (orders)
- Each order can have multiple products (orders_products)
- We automatically group orders by order_status to help with the most efficient shipment and delivery process
- We help with stock management, restocking, reordering, and stock taking
- User logs in
- User connects Magento2 API or other sources
- Orders are fetched from eCommerce Store or other sources
- Orders are grouped by order_status for most efficient shipment and delivery process
- Users pick and pack the products
- Courier labels are automatically printed and attached to the packages
- AutoPilot suggest the next best order to the user, based on the most efficient route
- Clients are notified of the shipment and tracking number
- User logs in
- User connects CLIENTS Magento2 API (multiple allowed)
- User connects Couriers API (multiple allowed)
- Orders are fetched from CLIENTS eCommerce Store
- Order Automations group orders by order_status for most efficient shipment and delivery process ensuring that standards required are met
- Order are picked in batches for efficiency
- AutoPilot suggest the next best order to the user, based on the most efficient route and request for packing
- Courier labels are automatically printed and attached to the packages
- Clients are notified of the shipment and tracking number
- User logs in
- User connects ePOS API
- Sales are fetched from ePOS
- Inventory can be managed by the user (goods in, goods out, stock take, stock checks, sales, damages...)
- AutoPilot suggest restock level and reorder points
- Store staff updates inventory restocking levels and reorder points to their needs
- Stock gets delivered based on the reorder points and restocking levels
- Stock is automatically requested from fulfillment center
- AutoPilot monitors the stock for possible stock issues and suggests actions to the user
- Buying department can see the sales and stock levels and make decisions based on the accurate data
- User logs in
- User connects eCommerce Store API
- Customer places an order requesting collection in specific location
- Orders are fetched from eCommerce Store
- Orders are Automatically dispatched to the specific location
- Orders Automations group orders by order_status for most efficient shipment and delivery process
- Users pick and pack the products
- Courier labels are automatically printed and attached to the packages
- AutoPilot suggest the next best order to the user, based on the most efficient route
- Clients are notified of the shipment and tracking number
- User logs in
- User connects retail store ePOS API
- Orders are created and managed on the ePOS system
- Orders are marked for shipment on the ePOS system
- Orders are fetched from ePOS
- Orders are grouped by order_status for most efficient shipment and delivery process
- Users pick and pack the products
- Courier labels are automatically printed and attached to the packages
- AutoPilot suggest the next best order to the user, based on the most efficient route
- Clients are notified of the shipment and tracking number
Models are used to interact with the database. They are used to read and write data to the database using eloquent
Observers are used to listen for database record changes (Model) and dispatch events when they occur.
Example: OrderObserver listens for changes in the Order model and dispatches OrderUpdatedEvent when changes happen.
Event are dispatched throughout the application to notify other parts of the application that something has happened and they should take action.
For example, when an order is created, an event is dispatched to notify the shipping department that they should take action.
Example: OrderUpdatedEvent is dispatched when an order is updated. InventoryReservations module listens for this event and takes action to ensure stock is not oversold.
Modules are used to group related functionality together.
- modules should listen to events and take action when they occur
- modules should be ideally maintaining their own data
- modules data tables should prefix with module_ and module name (e.g. modules_inventory_reservations_configuration)
- deleting a module should not affect functionality of other parts of the application
Each module has its own folder and might contains the following:
- ModuleServiceProvider (App\Modules\InventoryReservations\src\ModuleServiceProvider.php)
- Controllers (App\Modules\InventoryReservations\src\Controllers)
- Models (App\Modules\InventoryReservations\src\Models)
- Observers (App\Modules\InventoryReservations\src\Observers)
- Events (App\Modules\InventoryReservations\src\Events)
- Listeners (App\Modules\InventoryReservations\src\Listeners)
- Migrations (App\Modules\InventoryReservations\Database\src\Migrations)
- Seeders (App\Modules\InventoryReservations\Database\src\Seeders)
- Views (App\Modules\InventoryReservations\src\Views)
- Resources (App\Modules\InventoryReservations\src\Resources)
- Requests (App\Modules\InventoryReservations\src\Requests)
Modules Service Providers are used to register the module with the application and to load the module configuration.
<?php
namespace App\Modules\Magento2MSI\src;
use App\Events\EveryFiveMinutesEvent;
use App\Events\Product\ProductTagAttachedEvent;
use App\Modules\BaseModuleServiceProvider;
class Magento2MsiServiceProvider extends BaseModuleServiceProvider
{
public static string $module_name = 'eCommerce - Magento 2 MSI';
public static string $module_description = 'Module provides connectivity to Magento 2 API - Multi Source Inventory';
public static string $settings_link = '/settings/modules/magento2msi';
public static bool $autoEnable = false;
protected $listen = [
EveryFiveMinutesEvent::class => [
Listeners\EveryFiveMinutesEventListener::class
],
ProductTagAttachedEvent::class => [
Listeners\ProductTagAttachedEventListener::class,
],
];
public static function enabling(): bool
{
// Add your logic here
return parent::enabling();
}
}Modules are installed using migrations
<?php
use App\Modules\Magento2MSI\src\Magento2MsiServiceProvider;
use Illuminate\Database\Migrations\Migration;
return new class extends Migration
{
public function up(): void
{
Magento2MsiServiceProvider::installModule();
}
};Helps us to make sure we didn't break anything accidentally
Dusk Tests sof what user would do, not what the code does
Write simple but meaningful, easy to understand tests (e.g. test if api route response success if given some data)
Write tests for each module to ensure it works as expected
- User experience and efficiency is the important thing, this is the ultimate problem we are solving
- Make the code clear and simple so we can understand it and maintain it for years
We design for the size of the database:
- 20 locations (warehouses, stores, etc)
- 30 users
- 100 000 orders fulfilled per year
- 500 000 products
- 10 000 000 inventory records
Server size: 4 core, 16gb ram, 500gb ssd, 1gbps
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent