[AvantaR]

Mam dylemat. Scenariusz – nowa wersja serwisu backoffice'owego. Chcemy zupełnie wyeliminować PHPowy backend. Całość będzie działać w oparciu o API RESTowe. I teraz pytanie – w co lepiej pójść. Angular? React /Vue+ jakiś backend w JS/TS? Z żadnym większego doświadczenia nie mamy. W aktualnej wersji jest AngularJS+PHP. Myślałem o Angularze, bo mimo, że inny to jednak pewne nawiązania ma do AngularaJS jeśli chodzi o nomenklaturę itd. Co Mireczki i Mirabelki myślą? W co się tu wpakować najlepiej?

#programowanie #javascript

[Jurigag]

Chcemy zupełnie wyeliminować PHPowy backend

@AvantaR: z ciekawości, czemu?

[pitu120]

@Jurigag: miałem zapytać o to samo :)

[Jurigag]

@AvantaR: jeśli zależy wam na wydajności np to jakby co to nie jest to argument, bo są rozwiązania do php przebijające backend w JS kilkanaście razy

[AvantaR]

@Jurigag: @pitu120: Ok, może nie chcemy, a rozważamy różne opcje i tak wydaje się sensowna. Dlaczego? Przede wszystkim, żeby używać jednego języka. Brak konieczności utrzymywania zależności dla JS i PHP. O wydajność tu nawet nie chodzi, bo cała logika biznesowa jest po stronie API. Ewentualnie jakiś mini framework PHPowy, który dostarczy routing i tego typu rzeczy.

Ja odwróciłbym może pytanie. Po co używać PHPa, kiedy cała aplikacja będzie działać w

[Jurigag]

@AvantaR: nadal nie jest to żaden argument, choćby po to że nie trzeba używać protezy którą jest TS aby normalnie pisać w tym języku? i nawet jeśli się z niego korzysta, to PHP sam jako język nadal jest bardziej rozbudowany i oferuje więcej możliwości

przecież pisanie frontu w JS, a pisanie backendu w TS, to też są dwie różne rzeczy na dobrą sprawę, nadal trzeba mieć oddzielnych ludzi od tego

tym

[AvantaR]

@Jurigag: Tylko co mi z tego PHPa jak będę używał jego zupełnej namiastki? Można też polemizować czy TS to proteza, bo jednak ma sporo rzeczy, których PHP nadal nie może się doczekać.

[Jurigag]

@AvantaR: między innymi jakich?

[Rst00]

@AvantaR: piszesz tak, jakbyś nie miał w ogóle pojęcia ani o jednym ani o drugim xD

[Jurigag]

@AvantaR: jeśli przykładem ma być np async await to couroutines z swoole jest całkiem niezłą alternatywą

[AvantaR]

@Rst00: Co takiego napisałem, że tak twierdzisz?

[pitu120]

@AvantaR: napisz co to api mniej więcej robisz bo pisząc:

Tylko co mi z tego PHPa jak będę używał jego zupełnej namiastki

wygląda jak to była apka praktycznie bez logiki

[AvantaR]

@Jurigag: Nie, nie chodziło mi nawet o asyns, jak o takie rzeczy jak nie wiem, generyki na przykład, których nadal w PHPie nie ma. Żeby nie było, ja jestem PHPowcem, ale po prostu sam nie wiem czy w przypadku takiej aplikacji jest sens utrzymywać backend w PHPie.

[MQs]

@AvantaR: Czyli obecny backend php tylko pośredniczy w żądaniach do jakiegoś API, czyli innego, prawdziwego backendu? W takim razie to od początku nie miało sensu poza server-side rendering w epoce "przedjavascriptowej".

[Jurigag]

@AvantaR: @pitu120: właśnie, skoro namiastka to może w ogóle backend zbędny to może pójść lepiej w jakieś rozwiązania gotowe? tj baas albo serverless i skupić się tylko na froncie

[AvantaR]

@pitu120: Cała logika biznesowa jest w API, także tak - żadnej logiki w nazwijmy to backoffice jako takiej nie będzie.

[pitu120]

@AvantaR: ale to api jakieś zewnętrzne, nie wasze? Jeżeli tak to po co Wam backend?

[AvantaR]

@MQs: Teraz niestety całość nie idzie przez API.

[Jurigag]

@AvantaR: generyki wiadomo brzmi to fajnie, są spoko, ale w praktyce aby znaleźć rzeczywiście dobre ich zastosowanie to nie jest takie proste, o ile język oferuje je prawie od samego początku jak c# czy java no to spoko, ale w takim TS to też jest tylko proteza i tworzenie naokoło

[AvantaR]

@pitu120: Nasze, wewnętrzne. Backend? Routing itd. Ale widzę, że koledzy ty innego pomysły podsuwają.

Ps. Panowie luźna rozmowa bez spiny. Pytam bo rozważam rożne opcje i nie jestem alfą i omegą.

[pitu120]

Routing itd.

@AvantaR: od tego jest front jak chcesz robić apkę headless api i reszta na froncie.