Platforma API do integracji pomiędzy sprzedawcami i programistami

pytanie zadane 12 grudnia 2022 w Inne języki przez Marek2000 Nowicjusz (120 p.)

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:

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.
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

1 odpowiedź

odpowiedź 12 grudnia 2022 przez Wiciorny Ekspert (277,460 p.)

Polecam zainwestować kase w architekta, bo zadajecie za bardzo "odrębne od siebie pytania" i wbrew pozorom to nie sa proste pytania, na zasadzie : a lepiej będzie monolit, a może lepiej będzie mikro serwis a może gRPC, a może REST to jest tak jakbyście pisali: no może weźmiemy tłumacza angielskiego, a może niemieckiego.

To nie tylko chodzi o kwalifikacje programistów, ale nie wszystko jest wstanie obejmować wszystko- czasami wybór monolitu spowoduje, że totalnie nie będzie sensu decydować się na rozwiązania grafowe, tym bardziej czy faktycznie potrzebny wam jest gRPC ? Czy macie specjalistów do tego, którzy będą wstanie z tym pracować i dostosować wasze API do gRPC, czy wszystko w obrębie mikro serwisu będzie miało opierać się dokładnie o tą samą baze danych, czy takie same api jeśli chodzi o transfer danych pomiędzy warstwami.

Skoro wy nawet nie wiecie jaki bekhendowy język chcecie. A to wszystko zależy i jednej dobrej odpowiedzi nie ma, bo nie ma tez "lepszego i gorszego" języka do tego typu rozwiązań, kwestia kfalifikacji i "PRIORYTETÓW" jakie spełniać ma aplikacja krótko i długofalowo, a też JAK POWINNA SIĘ ZACHOWYWAĆ -> np. czy w przyszłości lepiej będzie wykorzystać i dostosować aplikacje do skalowania (w szerz, a może wzdłuż).

Pytanie i kierowanie się opinią na forum bez jednoznacznych "wymagań" jest moim zdaniem strzałem w kolano i taniej - w kwesti czasu wyjdzie inwestycja w zaprojektowanie API w konsultacji z architektem nawet zewnętrznym.
I na koniec Czy widzicie tu miejsce dla nierelacyjnej bazy danych? No jeśli decydujecie się na protokoły grafowe to nie ma opcji efektywnej i optymalnej pracy na bazach relacyjnych, to tez kwestia potrzeb.

Jeden programista to nie jest "alfa i omega" i gość od wszystkiego, który będzie wam wstanie powiedzieć: jaka baza, jaki serwis, jaka architektura protokołu itd itp. do tego potrzebny jest nie jeden specjalista w kilku i to różnych.
Też nie oczekujcie od jednego człowieka wszystkiego, bo jeśli by ktoś zadeklarował się " że on się na tym wszystkim zna" i jeszcze jest DEVOPSEM ( o tym też pomyślcie) to znaczy że jego wiedza jest nikła, bo specjalista to specjalista i ma wąski zakres specjalizacji jeśli faktycznie nim jest.

komentarz 20 grudnia 2022 przez Marek2000 Nowicjusz (120 p.)

Dziękuję za odpowiedź. Po kilku dniach rozważań doszliśmy do wniosku, że chyba najważniejsze byłoby dla nas teraz wybrać język backendowy. Najpierw myśleliśmy o PHP, ale słyszałem, że nie jest super wydajny przy mikroserwisach, które prawdopodobnie będziemy wprowadzać. Ja osobiście rozważałem NodeJS, bo troszkę znam i lubię ten język (jako frontend dev). Myślałem też o Javie, ze względu na to, że chyba wszyscy (?) programują tam backend we frameworku Spring i w razie zmiany deva, nie musielibyśmy szukać kogoś ze znajomością takiego samego frameworka, tylko po prostu Java deva. Ciężko coś wybrać nie będąc backend developerem. Może masz jakiś pomysł?