Invoicewave_back NPM

Invoice.ge

სარჩევი

სამუშაო პროცესის გაიდლაინები (მითითებები)
მოდულები
ინვოისები

Scripts

npm run start:local Runs backend services with development credentials & configuration

npm run start:testing Runs backend services with staging credentials

npm run socket Runs socket service in local environment

npm run start:devDocker Start project with docker, with development credentials & configuration

npm run agenda:local Runs agenda jobs, workers in local development environment with dev credentials

Generate API documentation

npm run apidoc Generates or modifies API documentation

npm run swagger Generates or modifies Swagger API documentation

Other commands:

npm run lint Eslint error check

npm run seed:users Runs seeder for test users in test database

npm run seed:plans Runs seeder for plans in test database

npm run load:test უშვებს ლოკალურად სტრეს ტესტებს

npm run set:admin Makes user superadmin or removes superadmin from user with development credentials & configuration. (Example: Makes superadmin npm run set:admin test@gmail.com true) (Example: Removes superadmin npm run set:admin test@gmail.com false)

Docker

docker-compose up Project start with docker

GrapHQL API endpoints & Interface

GraphQL Interface for development environment https://api-dev.invoice.ge/graphql For each query and mutations there are descriptions. You can search and find any models.

API endpoints & Swagger Interface

Invoice.ge supports GrapQL and REST interface For rest interfces you can visit https://api-dev.invoice.ge/api-docs/ At this time we only using GrapQL interface for communication. Swagger documentation generates automaticaly based from api endpoints we have in backend

Google infostructure, Scalability & Data flow

Guidlines and development processes

To avoid the versioning and dependency problems we need to freeze node.js version for project by creating .nvmrc file in the root folder for each project.

For this, we need to use NVM (Node Version Manager) You can see how to set up in this link How to setup NVM

It’s recommended to set up “Deep shell integration“ while using NVM on your workstation.

Deep shell integration

.EditorConfig

EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable and they work nicely with version control systems.

Our setup for .editorconfig looks like this.

# http://editorconfig.org

# top-most EditorConfig file
root = true

[*]
charset = utf-8
indent_style = spaces
indent_size = 2
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

.ESLint

ESLint is an open-source JavaScript linting utility. Code linting is a type of static analysis that is frequently used to find problematic patterns or code that doesn’t adhere to certain style guidelines. Many problems ESLint finds can be automatically fixed. ESLint fixes are syntax-aware so you won't experience errors introduced by traditional find-and-replace algorithms. ESLint statically analyzes your code to quickly find problems. ESLint is built into most text editors and you can run ESLint as part of your continuous integration pipeline.

You can find eslint rules in .eslintrc.json file in project root directory

Git Guidlines

GitFlow is that it makes parallel development very easy, by isolating new development from finished work. New development (such as features and non-emergency bug fixes) is done in feature branches, and is only merged back into main body of code when the developer(s) is happy that the code is ready for release.

New feature branches feature/new-feature
Hotfix branch hotfix/bug-name
Release branch release/new_release_name

Semantic commits

It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

The commit message should be structured as follows:

chore: add Oyster build script
docs: explain hat wobble
feat: add beta sequence
fix: remove broken confirmation message
refactor: share logic between 4d3d3d3 and flarhgunnstow
style: convert tabs to spaces
test: ensure Tayne retains clothing

Git flight rules

CI Process how it looks like

Continuous Integration

For CI we are using Google cloud build-ს https://cloud.google.com/cloud-build/

When something will be committed to the “develop” branch on repository it will go automatically to http://dev.invoice.ge/ After that it will run automatization tests we are checking if something is going wrong or not. If everything is ok and our Cypress tells that it’s ok. “develop“ branch will be merged to the “staging“ branch and it will go automatically to https://staging.invoice.ge/ This host is for product owners and testers to check applications on how it looks like.

If everything is ok we are triggering deployment process on a production https://invoice.ge/

Process looks like this

CI flow

Technical components

IWFront - Frontend application
IWBack - Backend application
Worker jobs. Agents - Background workers runs on certain of time
- notifyInvoicePaymentWithSMS - If client has turned on SMS's this worker sends sms to clients about unpaid invoices
- checkInvoiceTransactionInTBC Checks the amount of bank transfers and maps to current invoices if they are paid or not
- createInvoicesFromRecurring - Send recurring invoices
- notifySubscriptionPayments - Notify clients for payments
- paySubscriptionStandingOrders - subscribe payment autoamtization for invociewave clients
MicroServices (Google functions)
- PDF rendering for invoices
Socket service
MongoDatabase on Cloud Atlas

Architecture & Models

Database schemas

Database shemas located in src/modules/<ModelName.js>