Wpis z mikrobloga

@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
  • Odpowiedz
@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ę"
  • Odpowiedz
@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.
  • Odpowiedz
@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
  • Odpowiedz
@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.

Cała strona serwerowa może być deklaratywna.
  • Odpowiedz
back-end to pierwsza rzecz do eliminacji w następnej "rewolucji"/rewizji WWW

@patrolez: a gdzie w tym wszystkim logika biznesowa? Pracowałeś kiedyś z dużymi aplikacjiami z bogatą warstwą domeny?

to głównie patola z robieniem Dto, mappingiem na ORM, mappingiem na SQL, czy innymi Joinami i walidacją.

to, że tego nie rozumiesz, nie znaczy że nie ma zastosowania w konkretnych
  • Odpowiedz
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
  • Odpowiedz
@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ą,
  • Odpowiedz
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.
  • Odpowiedz