Go to file
Sergey Yelin eaf68723c7
FF-116: Switch to shumpune proto (#126)
* Switch to shumpune proto

* Affected -> Clock

* Added shumpune_proto

* Add coverage config

* Add extra parameter with type clock() to ff_transaction:balance/1

* Update hellgate and dominant

* Add clock marshaling rules

* Upgrade fistful-proto

* Fix dialyzer errors

* Code review fixes

* Move currency reference creartion to ff_currency.

* Use standard function for conversion

* Revert "Use standard function for conversion"

This reverts commit 9ac5a94c55476400f425703192d48e8211b1b1dc.

* Use standard function - 2

* Replace clock records with ff_clock module

* Fix clock type

* More review fixes

* Revert "More review fixes"

This reverts commit a75707eace1fdc41668755d62d0130054beda7aa.

* More review fixes

* Add NOTE to deposite test

* Move clock selection to ff_postings_transfer

* Fix spec for clock/1
2019-10-14 14:16:30 +03:00
apps FF-116: Switch to shumpune proto (#126) 2019-10-14 14:16:30 +03:00
build-utils@ea4aa042f4 FF-116: Switch to shumpune proto (#126) 2019-10-14 14:16:30 +03:00
config FF-116: Switch to shumpune proto (#126) 2019-10-14 14:16:30 +03:00
schemes FF-116: Switch to shumpune proto (#126) 2019-10-14 14:16:30 +03:00
test FF-116: Switch to shumpune proto (#126) 2019-10-14 14:16:30 +03:00
.gitignore ignore tags 2019-09-13 12:46:23 +03:00
.gitmodules HG-392: check limits for wallet and withdrawal (#25) 2018-10-30 17:30:42 +03:00
docker-compose.sh FF-116: Switch to shumpune proto (#126) 2019-10-14 14:16:30 +03:00
Dockerfile.sh Nail wapi app here for a while 2018-07-06 16:49:30 +03:00
elvis.config FF-108: Webhooks (#100) 2019-08-12 13:58:18 +03:00
Jenkinsfile Upgrade Erlang and deps 2019-06-27 18:58:45 +03:00
LICENSE Let's make it opensource 2019-09-20 00:03:57 +03:00
Makefile Updated build_image and cowboy_access_log 2019-07-18 16:28:35 +03:00
README.md Handle transfers through noion of accounts (yeah, again) (#9) 2018-07-16 17:21:17 +03:00
rebar.config FF-116: Switch to shumpune proto (#126) 2019-10-14 14:16:30 +03:00
rebar.lock FF-116: Switch to shumpune proto (#126) 2019-10-14 14:16:30 +03:00

Fistful

Wallet Processing Service

Development plan

Бизнес-функционал

  • Минимальный тестсьют для кошельков
  • Реализовать честный identity challenge
  • Запилить payment provider interface
  • Запилить контактные данные личности
  • Запилить нормально трансферы
  • Заворачивать изменения в единственный ивент в рамках операции
  • [.] Компактизировать состояние сессий
  • Запилить контроль лимитов по кошелькам
  • Запилить авторизацию по активной идентификации
  • Запилить отмену identity challenge
  • Запускать выводы через оплату инвойса провайдеру выводов
  • Обслуживать выводы по факту оплаты инвойса

Корректность

Удобство поддержки

  • Добавить служебные лимиты в рамках одного party
  • Добавить ручную прополку для всех асинхронных процессов
  • Вынести ff_withdraw в отдельный сервис
  • Разделить development, release и test зависимости
  • Вынести части ff_core в genlib

Поддержка checkout

Каждая машина, на которую мы можем сослаться в рамках асинхронной операции, должно в идеале давать возможность зафиксировать версию своего состояния посредством некой ревизии. Получение состояния по ревизии осуществляется с помощью вызова операции checkout. В тривиальном случае ревизия может быть выражена меткой времени, в идеале номером ревизии.

Коммуналка

Сервис должен давать возможность работать нескольким клиентам, которые возможно не знают ничего друг о друге кроме того, что у них разные tenant id. В идеале tenant должен иметь возможность давать знать о себе динамически, в рантайме, однако это довольно трудоёмкая задача. Если приводить аналогию с Riak KV, клиенты к нему могут: создать новый bucket type с необходимыми характеристиками, создать новый bucket с требуемыми параметрами N/R/W и так далее.

Дегидратация

В итоге как будто бы не самая здравая идея. Есть ощущение, что проще и дешевле хранить и оперировать идентификаторами, и разыменовывать их каждый раз по необходимости.

Служебные лимиты

Нужно уметь ограничивать максимальное ожидаемое количество тех или иных объектов, превышение которого может негативно влиять на качество обслуживания системы. Например, мы можем считать количество выводов одним участником неограниченным, однако при этом неограниченное количество созданных личностей мы совершенно не ожидаем. В этом случае возможно будет разумно ограничить их количество сверху труднодостижимой для подавляющего большинства планкой, например, в 1000 объектов. В идеале подобное должно быть точечно конфигурируемым.