Wszystko

Najnowsze

Archiwum

mirunek
mirunek
  • 0
Jak najlepiej zaimplementować płatności?
Np. Stripe pozwala na przelewy, płatność kartą, subskrypcję itd. Użytkownik może opłacić coś raz przelewem, raz karta, a później aktywować subskrypcję.

Myślałem o czymś takim (encje, tabele itd.):
- plans, gdzie jest lista planów (kwota, dni, okres testowy),
- payment - gdzie każda rozpoczętą płatność jest przechowywana w tej tabeli, przypisana do uzytkownika jej status itd.
  • 5
  • Odpowiedz

  • Otrzymuj powiadomienia
    o nowych komentarzach
Serghio
  • 0
@mirunek: imo wszystko zależy jakiej konkretnie logiki biznesowej potrzebujesz,

nie napisałeś wprost o co chodzi, ale między wierszami rozumiem, że masz jakiś serwis, który oferuje jakąś treść w ramach subskrypcji czasowej

jak widziałbym to tak, że to w zasadzie sklep internetowy, którym produktem jest przedłużenie, aktywacji subskrypcji na określoną ilość dni, czy jakiegoś planu dostępności do różnej głębokości
  • Odpowiedz
mirunek
mirunek
mirunek
via Android
  • 0
@Serghio

teraz trzeba tylko jakaś nową encje z polami (user, endtime, plan) oraz mechanizm, który zaktualizuje te encje, np opartą na jakiś eventach, workflow, czy coś, tutaj rozwiązań jest multum


Właśnie to chodziło mi pp głowie. Czyli jakaś tabela "pomocnicza", która będzie trzymała informacje do kędy jest opłacone konto.

Sądzisz ze to powinien być jeden rekord per user, któremu będę co płatność przedłużał date?
  • Odpowiedz
Sparrowekk
  • 0
Hej,
Właśnie próbuje sobie postawić API w symfony za pomocą ApiPlatform. Przy instalacji wyskoczyła mi informacja aby stworzyć swoje pierwsze ApiResource w src/ApiResource. Czy teraz jest jakiś inny sposób wskazywania źródła API niż wcześniej (#[ApiResource] w modelach)?

#symfony #php #programowanie #apiplatform
  • 1
  • Odpowiedz

  • Otrzymuj powiadomienia
    o nowych komentarzach
mirunek
mirunek
  • 1
Luźne pytanie z rana do mirków z #php #symfony.

Czy używacie produkcyjnie #apiplatform ? Wiem, że np. #sylius z tego korzysta żeby wystawić API ale... czy to powszeche? Czy to może overkill?

API platform sporo załatwia out of the box (np. paginacja, filtrowanie) ale też sporo dorzuca od siebie. Jakieś "magiczne" definicje dla endpointów, które leżą na encji. Chcesz symfony messenger? Dodaj tylko
  • 9
  • Odpowiedz

  • Otrzymuj powiadomienia
    o nowych komentarzach
dodo_
dodo_
  • 3
@mirunek:

> definicje dla endpointów, które leżą na encji


U amatorów tak ( ͡° ͜ʖ ͡°) Należy mieć tu dwie klasy w praktyce (co najmniej). Jedna reprezentuje Response Object / DTO pod kontrakt api, gdzie ją kolorujesz tymi magicznymi Adnotacjami/Atrybutami/yml/xml. A Encja domenowa to co całkiem co innego i ona nie wie o istnieniu api-platform.

@JackBauer: trochę jak wyżej, jak się traktuje to jako
  • Odpowiedz
n.....i
n.....i
  • 4
@mirunek: z początku #apiplatform wydaje się fajne, ale im więcej skomplikowanych, niestandardowych rzeczy tym bardziej będziesz przeklinać to narzędzie. Zresztą popatrz sobie do symfonycasts jakie czasem cuda trzeba wyczyniać w contextbuilderach, dekoratorach, na różnych etapach de/serializacji żeby osiągnąć coś co w klasycznym API zajęłoby 5 minut w prostej warstwie abstrakcji.
  • Odpowiedz
croppz
  • 3
@pitu120: pewnie ilu programistów tyle opinii, ja na ogół przyjmuję takie założenia:
* logika związana bezpośrednio z endpointem, rzeczy potrzebne żeby zwrócić response - controller
* inna struktura danych w api, inna w bazie - dto + transformer
* zadania "poboczne", takie jak np. wysyłanie maili albo innych powiadomień - listener
* niestandardowe źródło danych, np. redis albo zewnętrzne api - provider/persister

Ale ostatecznie i tak zależy to od konkretnego
  • Odpowiedz

Powiązane tagi