Platforma API do integracji pomiędzy sprzedawcami i programistami

0

Cześć. Zbieramy się do nowego projektu, który będzie polegał na stworzeniu narzędzia pośredniczącego w integracji programistów oraz sprzedawców. Naszej platformy będą więc używać dwa typy użytkowników:

  1. Programiści tworzący nowe, interesujące apki e-commerce, takie jak shoppable tv, wearable technologies, AR/VR experiences with e-commecre functionality, in-app shopping i oczywiście nowości tego typu, które jeszcze nie powstały. ;) Rozwój szeroko pojętego web3 również może stworzyć nowe możliwości w tym zakresie. Programiści mogliby poprzez nasze API integrować swoje apki ze sprzedawcami.

  2. Sprzedawcy mający już swoje klasyczne platformy e-commerce, ale nie mogący w łatwy sposób wdrożyć nowości tworzonych przez wcześniej stworzonych programistów.

Nasze API umożliwiałoby więc firmom e-commerce w jednym miejscu dodawać poprzez jedno API nowe możliwości sprzedaży. Programistom natomiast ułatwiłoby to bolesną integrację, inną dla każdej platformy. Zamiast tego oba typy tych użytkowników zawsze w ten sam sposób integrowali swoje apki ze sobą.

Nie mamy jeszcze w zespole backendowca/fullstacka i zastanawiamy się jakiej osoby mamy szukać i jakiego stacka użyć do budowy tej apki.

Mikroserwisy czy monolit?
REST czy GraphQL? A może gRPC?
Jaki język na backend?
Czy widzicie tu miejsce dla nierelacyjnej bazy danych?

Szukamy do naszego małego teamu senior/lead backendowca/fullstacka/CTO, ale to ta osoba musiałaby nam powiedzieć jak zbudować tę apkę. Dlatego pomyśleliśmy, że najpierw spytamy na forum z jakim stackiem programisty mamy szukać. :) Będziemy też wdzięczni za inne wskazówki, może ktoś z Was coś wie, o czym warto byłoby wspomnieć, a my o tym nie pomyśleliśmy.

Pozdrawiam

@Edit Tutaj jest ogłoszenie o pracę, które dotychczas opracowaliśmy.

1
Marek2000 napisał(a):

Mikroserwisy czy monolit?

Zawsze mikroserwisy. Ja np mam w projekcie jeden mikroserwis

REST czy GraphQL? A może gRPC?

REST, bo reszty nie znam /nie używałem

Jaki język na backend?

Scala, Haskell, Rust

Czy widzicie tu miejsce dla nierelacyjnej bazy danych?

Zawsze

4
KamilAdam napisał(a):
Marek2000 napisał(a):

Mikroserwisy czy monolit?

Zawsze mikroserwisy. Ja np mam w projekcie jeden mikroserwis

Baco, macie wrzątek? Mom, ino zimny ...

Marek2000 napisał(a):

, ale to ta osoba musiałaby nam powiedzieć jak zbudować tę apkę.

Jak na mój gust na tym etapie koncepcji to on nic takiego nie powie. Idea może na dziś jest dojrzała do poziomu marketingu / naciągaczy ze startupów, ale nie na tyle, aby z niej nie wytworzyć techniczne założenia.

Marek2000 napisał(a):

Jaki język na backend?

Tez nie macie nikogo ?

Marek2000 napisał(a):

Cześć. Zbieramy się do nowego projektu, który będzie polegał na stworzeniu narzędzia pośredniczącego w integracji programistów oraz sprzedawców.

Z chudej marży handlowej - ile milionów/milardów transakcji musiało być sfinalizowanych w platformie, aby wam to sfinansować?
Że Google Play żyje z groszowej marży, to nie znaczy ze każdemu się słupki zepną.

0
ZrobieDobrze napisał(a):
Marek2000 napisał(a):

Cześć. Zbieramy się do nowego projektu, który będzie polegał na stworzeniu narzędzia pośredniczącego w integracji programistów oraz sprzedawców.

Z chudej marży handlowej - ile milionów/milardów transakcji musiało być sfinalizowanych w platformie, aby wam to sfinansować?
Że Google Play żyje z groszowej marży, to nie znaczy ze każdemu się słupki zepną.

Mamy inny model biznesowy niż Google Play. Z tego co widzę, to jesteś bardzo aktywny na forum. Może akurat znasz osobiście kogoś kto byłby zainteresowany wzięciem udziału w takim projekcie? Albo znasz jakieś miejsce, oprócz oczywiście stron z ogłoszeniami o pracę, w którym moglibyśmy kogoś takiego znaleźć? Bylibyśmy wdzięczni. ;)

3
Marek2000 napisał(a):

Mikroserwisy czy monolit?
REST czy GraphQL? A może gRPC?
Jaki język na backend?
Czy widzicie tu miejsce dla nierelacyjnej bazy danych?

Szukamy do naszego małego teamu senior/lead backendowca/fullstacka/CTO, ale to ta osoba musiałaby nam powiedzieć jak zbudować tę apkę. Dlatego pomyśleliśmy, że najpierw spytamy na forum z jakim stackiem programisty mamy szukać. :) Będziemy też wdzięczni za inne wskazówki, może ktoś z Was coś wie, o czym warto byłoby wspomnieć, a my o tym nie pomyśleliśmy.

To nie są właściwe pytania, które należy zadać na tym etapie. Proponuję zacząć od innych i sobie na nie odpowiedzieć:

  1. Jakie są konsekwencje padnięcia serwisu (lub jego części) na 1 minutę / 1 godzinę / 1 dzień / 1 tydzień.... Ile może trwać przerwa w świadczeniu usług, zanim pociągnie za sobą konsekwencje biznesowe/wizerunkowe/bezpośrednie konsekwencje finansowe?
  2. Jakie są konsekwencje utraty danych z ostatniej minuty/godziny....?
  3. Jaki duży ruch ma zostać obsłużony. Jakie są szanse na gwałtowny skok tego ruchu w przyszłości?
  4. Czy usługa ma być obsługiwana w PL/EU/globalnie...?
  5. Jakie będą konsekwencje wycieku danych (np. osobowych) biznesowe/finansowe/prawne?
  6. Jaki ma być zakres biznesowy usługi? Jedynie obsługa płatności i dostarczanie kluczy, czy również dostarczanie samych aplikacji (klikam i instaluje mi się saper)
  7. Ma być tanio i szybko z założeniem, że połowa (albo cały) MVP poleci do kosza, czy zakładacie, że pierwsze rozwiązanie ma być rozwijalne w przyszłości?
  8. Na jakie koszty utrzymania całości jesteście gotowi? Bo wiele rzeczy da się zrobić, ale ich utrzymanie (np. zapasowe serwery, backupy...) kosztuje, czasami bardzo dużo.

Pewnie jeszcze z 10 razy tyle, to akurat mi przyszło do głowy na szybko, w trakcie pisania tego postu. Od udzielonych odpowiedzi zależy, czy rozwiązaniem docelowym będzie napisany na kolanie "skrypt" w PHP+ MySQL utrzymywany na jakimś wirtualnym serwerze od wirtualnego dostawcy za 100zł/ na rok, system złożony z mikroserwisów i usług zarządzalnych za dużo więcej.

Bez patrzenia na stronę biznesową całej imprezy, dostaniecie przypadkowe odpowiedzi od przypadkowych osób.

1 użytkowników online, w tym zalogowanych: 0, gości: 1