@wpoldokomina: jedno żądanie odpowiada wysyłając ID oraz cenę, drugie ID oraz nazwę, a chcę mieć nazwę i cenę.
Oczywiście uprościłem, bo mam trochę bardziej skomplikowaną strukturę danych, przy projektowaniu systemu nie przewidziałem, że mogę potrzebować czegoś takiego
@Its-a-Me-Luigi: rozwiązaniem na te problemy ma być graphQL. Nie ma dobrej odpowiedzi tak naprawdę, oczywiście ze strony UX wolałbyś jednego geta, ale wtedy mógłbyś powiedzieć "co to za gówniane api, że zwraca mi cenę a chcę tylko nazwę"
@Its-a-Me-Luigi: back-end to pierwsza rzecz do eliminacji w następnej "rewolucji"/rewizji WWW - to głównie patola z robieniem Dto, mappingiem na ORM, mappingiem na SQL, czy innymi Joinami i walidacją.
W następnym WWW zostanie tylko warstwa Persistent zintegrowana z udostępnianiem API po HTTP i może walidacją po stronie serwera oraz Front-End.
Może i właśnie GraphQL jest kolejnym poziomem rozwoju WWW i eliminacją SQL-a.
@patrolez: jak na razie trend jest odwrotny tj. przez mikroserwisy używamy jeszcze więcej warstw/mapowań i infrastruktury takiej jak bazy danych i cache. Jak piszę nowe backendy to staram się używać podejścia YOLO tj. dużo testów funkcjonalnych trzymające wszystko w kupie i jak najmniej kodu w backendzie tj. 1 model do wszystkiego i jak najbardziej uproszczona persystencja np. poprzez wrzut json/protobufa do jednej kolumny w bazie. Czy to działa tak, że nie
@Saly: dodaj do zapytań SQL warstwę uprawnień i masz koniec z back-endem w sensie prawie dzisiejszym.
Jeżeli chodzi o formatkę danych, to relacyjność i silne typowanie + constraints na polach wystarcza do wszystkiego, co potwierdziłeś używaniem Protobuf.
@Its-a-Me-Luigi: tak, nazywa się "architektura mikroserwisów" i jest następnym fadem po agile. Jeszcze kilka lat i będzie szczyt fali, a za 10 będziemy się z tego śmiali. Oczywiście nie wszystcy.
gdzie w tym wszystkim logika biznesowa? Pracowałeś kiedyś z dużymi aplikacjiami z bogatą warstwą domeny?
@Ernest_: też sobie próbowałem na te pytania odpowiedzieć. Przy prostych Crudach z kilkunastoma endpointami może takie podejscie przejdzie, w czyms trochę wiekszym juz nie szans
@NieBendePrasowac: @Ernest_: zawsze na końcu jest Persistent, back-end to znowu klejenie struktur i rzeźbienie w Joinach i konfigurowanie za każdym mikro-serwisem warstwy dostępowej.
Więc definiując: * OpenAPI, * mapowanie między API, a Persistent, * model dla ORM/IDL, * role/uprawnienia użytkowników.
Załatwiasz jakieś 80% przypadków użycia dla WWW, nawiązując do zasady Pareto.
Teraz ludzie w back-end wykonują wciąż rutynowo punkt 2. i punkt 3., a punkt 1. jest
@NieBendePrasowac: @Ernest_: więc może faktycznie trochę przesadziłem z eliminacją back-end, jednak na podstawie moich doświadczeń uważam, że istnieje sposób na realizację strony serwerowej w podejściu deklaratywnym, w którym to w back-end więcej linijek zajmują re-używalne adnotacje i minimalne bloki kodu, a nie sam proceduralny kod.
jeżeli opanuje się sztukę nazewnictwa.
i silnego typowania.
===== Przecież dobrze wiemy, że programowanie to nic innego jak przetwarzanie wejściowej informacji w wyjściową, a najbardziej
Już bez wołania, ale no jeszcze pozostają inne dziedziny, gdzie np. musisz sterować/zarządzać jakimiś urządzeniami, czy komunikować się z zewnętrznym API, a nie tylko wykonywać operacje arytmetyczne - tam faktycznie będzie wciąż potrzebny back-end.
Jednak jeżeli jakaś firma stawia nową aplikację, która nie musi mieć żadnej komunikacji z zewnętrznym API i faktycznie jest CRUD-em, to dałoby się back-end opędzlować nawet w takim PostgREST.
API zwraca JSONa, w którym są ID i dane, później robię drugiego GETa, żeby zmatchować dane po ID. Czy to szkoła gównokodu?
Oczywiście uprościłem, bo mam trochę bardziej skomplikowaną strukturę danych, przy projektowaniu systemu nie przewidziałem, że mogę potrzebować czegoś takiego
Edit: ale jak nie ma wyjścia to rób dwa gety. Serwer ci się przez to nie spali xD
@Its-a-Me-Luigi: no to słabe api
W następnym WWW zostanie tylko warstwa Persistent zintegrowana z udostępnianiem API po HTTP i może walidacją po stronie serwera oraz Front-End.
Może i właśnie GraphQL jest kolejnym poziomem rozwoju WWW i eliminacją SQL-a.
Jeżeli chodzi o formatkę danych, to relacyjność i silne typowanie + constraints na polach wystarcza do wszystkiego, co potwierdziłeś używaniem Protobuf.
Cała strona serwerowa może być deklaratywna.
@Its-a-Me-Luigi: tak, nazywa się "architektura mikroserwisów" i jest następnym fadem po agile. Jeszcze kilka lat i będzie szczyt fali, a za 10 będziemy się z tego śmiali. Oczywiście nie wszystcy.
https://en.wikipedia.org/wiki/Web_application_firewall
@patrolez: a gdzie w tym wszystkim logika biznesowa? Pracowałeś kiedyś z dużymi aplikacjiami z bogatą warstwą domeny?
to, że tego nie rozumiesz, nie znaczy że nie ma zastosowania w konkretnych sytuacjach.
Przecież
@Ernest_: też sobie próbowałem na te pytania odpowiedzieć. Przy prostych Crudach z kilkunastoma endpointami może takie podejscie przejdzie, w czyms trochę wiekszym juz nie szans
Więc definiując:
* OpenAPI,
* mapowanie między API, a Persistent,
* model dla ORM/IDL,
* role/uprawnienia użytkowników.
Załatwiasz jakieś 80% przypadków użycia dla WWW, nawiązując do zasady Pareto.
Teraz ludzie w back-end wykonują wciąż rutynowo punkt 2. i punkt 3., a punkt 1. jest
i silnego typowania.
=====
Przecież dobrze wiemy, że programowanie to nic innego jak przetwarzanie wejściowej informacji w wyjściową, a najbardziej
Jednak jeżeli jakaś firma stawia nową aplikację, która nie musi mieć żadnej komunikacji z zewnętrznym API i faktycznie jest CRUD-em, to dałoby się back-end opędzlować nawet w takim PostgREST.