Podsumowanie<\/a><\/li><\/ol><\/nav><\/div>\n\n\n\nPr\u00f3g wej\u015bcia<\/h2>\n\n\n\n Pr\u00f3g wej\u015bcia dla nowych programist\u00f3w jest bardzo niski. Mamy \u015bwietn\u0105 dokumentacj\u0119, dobre CLI (Command Line Interface<\/em> – innymi s\u0142owy wiele wiele podstawowych czynno\u015bci jak tworzenie nowego controllera, czy modelu mo\u017cna wykona\u0107 przy pomocy jednej komendy), proste do zrozumienia ORM, kt\u00f3re u\u0142atwia prac\u0119 z baz\u0105 danych, wiele gotowych rozwi\u0105za\u0144, jak Starter Kity, a to tylko cz\u0119\u015b\u0107 u\u0142atwie\u0144 kt\u00f3re serwuje nam Laravel.<\/p>\n\n\n\n\u017beby nie by\u0107 go\u0142os\u0142ownym, wyobra\u017amy sobie, \u017ce chcemy wybra\u0107 wszystkich aktywnych u\u017cytkownik\u00f3w z bazy danych (User, to oczywi\u015bcie nasz model):<\/p>\n\n\n\n
$user = User::where('active', 1)->get();<\/code><\/pre>\n\n\n\nMamy te\u017c \u015bwietny Tinker, kt\u00f3ry umo\u017cliwia nam operowanie na bazie danych w podobny spos\u00f3b, jak w konsoli mySQL, ale przy wykorzystaniu Laravela, w tym ORM. <\/p>\n\n\n\n
Bez w\u0105tpienia bardzo istotne jest te\u017c to, \u017ce Laravel ma w zasadzie wi\u0119kszo\u015b\u0107 potrzebnych rzeczy dost\u0119pnych od razu po uruchomieniu – od systemu szablon\u00f3w (w tym przypadku jest to blade) po seedery, tworzenie w\u0142asnych polece\u0144, itp. Dzi\u0119ki temu krzywa nauki jest prostu przyjemniejsza. Nie musimy gdzie\u015b po YouTube szuka\u0107 informacji o ekosystemie frameworka, co bez w\u0105tpienia mo\u017ce by\u0107 du\u017cym u\u0142atwieniem.<\/p>\n\n\n\n
Niestety niski pr\u00f3g wej\u015bcia niesie ze sob\u0105 pewne konsekwencje – \u0142atwo jest nabra\u0107 wra\u017cenia, \u017ce po przerobieniu jednego kursu na Udemy jeste\u015bmy w stanie tworzy\u0107 zaawansowane systemy. A Laravel oferuje du\u017c\u0105 elastyczno\u015b\u0107, co akurat wed\u0142ug mnie jest pewn\u0105 wad\u0105, ale jednocze\u015bnie dzi\u0119ki temu jest \u0142atwiejszy. Efektem cz\u0119sto jest kod spaghetti, kt\u00f3ry bardzo ci\u0119\u017cko jest p\u00f3\u017aniej rozwija\u0107.<\/p>\n\n\n\n
Podsumowuj\u0105c – Laravel jest prosty w nauce, przyjemnie si\u0119 w nim programuje, ale tworzenie jako\u015bciowych rozwi\u0105za\u0144, to ju\u017c zupe\u0142nie inna bajka.<\/p>\n\n\n\n
Model – View – Controller<\/h2>\n\n\n\n Laravel operuje na modelu MVC, kt\u00f3ry jest raczej standardem, i mo\u017cesz go spotka\u0107 w wi\u0119kszo\u015bci innych framework\u00f3w. Warto sobie jednak powiedzie\u0107, czym on w zasadzie jest. \u017beby sobie to lepiej zobrazowa\u0107, sp\u00f3jrz na poni\u017csz\u0105 grafik\u0119.<\/p>\n\n\n
\n
\n\t\t\t\n\t\t\t\tWidok – <\/strong>m\u00f3wi\u0105c najog\u00f3lniej jest to warstwa wizualna strony – to co widzisz po wej\u015bciu na dan\u0105 witryn\u0119. Laravel. Jako programista mo\u017cesz wewn\u0105trz widok\u00f3w wy\u015bwietla\u0107 warto\u015bci zmiennych, u\u017cywa\u0107 p\u0119tli do wy\u015bwietlania post\u00f3w z bazy danych, itp. Laravel jako, tzw. blade do budowy widok\u00f3w, kt\u00f3re znacznie upraszczaj\u0105 ten proces. W mojej ocenie s\u0105 one bardzo wygodne. Zobaczmy na fragment przyk\u0142adowego blade (jest to tylko kod pokazowy, kt\u00f3ry mniej wi\u0119cej pokazuje jak wygl\u0105da tworzenie widok\u00f3w):<\/p>\n\n\n\n @if(isset($comments) && $comments->count > 0)\n @foreach($comments as $comment)\n <div class=\"comment\">\n <div>{{$comment->description}}<\/div>\n <\/div>\n @endforeach\n\n @else\n <div class=\"error\">Brak komentarzy do wy\u015bwietlenia<\/div>\n @endif<\/code><\/pre>\n\n\n\nOczywi\u015bcie nie ma te\u017c problemu z dzieleniem widok\u00f3w na mniejsze cz\u0119\u015bci.<\/p>\n\n\n\n
Controller<\/strong> – controllery s\u0142u\u017c\u0105 do kontrolowania r\u00f3\u017cnych proces\u00f3w wewn\u0105trz aplikacji. Mo\u017ce to by\u0107 wy\u015bwietlenie widoku, zapisanie czego\u015b do bazy danych, itp. M\u00f3wi\u0105c najpro\u015bciej – wchodz\u0105c pod jaki\u015b adres url, uruchamiana jest odpowiednia metoda controllera, kt\u00f3ra odpala widok z odpowiednimi zmiennymi. Je\u015bli chcemy zapisa\u0107 jak\u0105\u015b informacj\u0119 do bazy danych, uruchamiamy kolejn\u0105 metod\u0119 controllera, kt\u00f3ra przy wykorzystaniu modelu (o czym za chwil\u0119), zapisuje dane w bazie danych. To w controllerze mo\u017cemy przeprowadza\u0107 te\u017c proces validacji danych, i mo\u017cemy w nim umie\u015bci\u0107 logik\u0119 biznesow\u0105. Tylko, \u017ce – to, \u017ce mo\u017cemy, nie oznacza, \u017ce powinni\u015bmy. Validacj\u0119 mo\u017cemy przenie\u015b\u0107 na zewn\u0105trz do request<\/em>, a logik\u0119 biznesow\u0105 do servic\u00f3w. <\/em>Sam controller powinien raczej zajmowa\u0107 si\u0119 kontrolowaniem tego co jest uruchamiane, albo jakie operacje b\u0119d\u0105 wykonywane na bazie danych.<\/p>\n\n\n\nModel – <\/strong>modele reprezentuj\u0105 baz\u0119 danych. S\u0105 odpowiedzialne za interakcje z baz\u0105 danych i wykonywaniem na niej r\u00f3\u017cnych operacji. Pos\u0142uguj\u0105c si\u0119 modelami mo\u017cemy stworzy\u0107 nowy record w bazie danych, usun\u0105\u0107 go, albo wy\u015bwietli\u0107 wszystkie recordy spe\u0142niaj\u0105ce okre\u015blone kryteria. To w\u0142a\u015bnie w modelach mo\u017cemy te\u017c definiowa\u0107 relacje, ale mo\u017cemy te\u017c sterowa\u0107 tym, kt\u00f3re kolumny b\u0119d\u0105 wy\u015bwietlane, dzi\u0119ki czemu nasza praca b\u0119dzie du\u017co \u0142atwiejsza.<\/p>\n\n\n\nTaki podzia\u0142 rozdziela aplikacj\u0119 na warstwy, co jest ogromnym u\u0142atwieniem i pozwala zachowa\u0107 wzgl\u0119dny porz\u0105dek w kodzie.<\/p>\n\n\n\n
Laravel pozwala b\u0142yskawicznie rozpocz\u0105\u0107 prac\u0119 nad nowym projektem<\/h2>\n\n\n\n Spo\u015br\u00f3d wszystkich technologii, z kt\u00f3rymi pracowa\u0142em, to w\u0142a\u015bnie Laravel pozwala najszybciej zacz\u0105\u0107 pracowa\u0107 nad nowym projektem. Mam tutaj na my\u015bli g\u0142\u00f3wnie prac\u0119 w \u015brodowisku Dockera. Po \u015bci\u0105gni\u0119ciu projektu, wpisujesz tylko jedno polecenie, kt\u00f3re w zasadzie buduje ca\u0142e Twoje \u015brodowisko:<\/p>\n\n\n\n
.\/vendor\/bin\/sail up \/\/ewentualnie sail up, je\u015bli stworzysz odpowiedni alias<\/code><\/pre>\n\n\n\nJest to w zasadzie pe\u0142ne \u015brodowisko, kt\u00f3re ma wszystko, co jest Ci potrzebne do pracy, \u0142\u0105cznie chocia\u017cby z obs\u0142ug\u0105 maila. Oczywi\u015bcie faktycznie nie wysy\u0142amy nigdzie maila, a jedynie korzystamy z MailHug, kt\u00f3ry jest narz\u0119dziem wykorzystywanym do testowania wysy\u0142ania maili. Dodatkowo Laravel posiada fajne Starter Kity, takie jak chocia\u017cby Breeze, kt\u00f3ra pozwalaj\u0105 tworzy\u0107 aplikacje full-stack przy u\u017cyciu Laravela, i np. Reacta, albo Vue. Od razu dostajesz ca\u0142y system logowania i rejestracji, a dzi\u0119ki Inertia du\u017co \u0142atwiej jest tak\u0105 aplikacj\u0119 tworzy\u0107… albo przynajmniej szybciej.<\/p>\n\n\n\n
Ma on swoje wady, poniewa\u017c tworzymy wtedy monolit, wi\u0119c je\u015bli chcemy stworzy\u0107 API z kt\u00f3rego b\u0119dzie korzysta\u0107, np. aplikacja napisana w React i dodatkowo jeszcze aplikacja mobilna, to raczej nie jest to technologia dla nas. <\/p>\n\n\n\n
Z drugiej jednak strony, je\u015bli tworzymy aplikacj\u0119 pokazow\u0105, albo jak\u0105\u015b ma\u0142\u0105 aplikacj\u0119 na w\u0142asne potrzeby, albo MVP, to jest to rozwi\u0105zanie wr\u0119cz idealne.<\/p>\n\n\n\n
I oczywi\u015bcie mo\u017cna powiedzie\u0107, \u017ce chocia\u017cby Django te\u017c umo\u017cliwia szybkie rozpocz\u0119cie pracy, bo nie do\u015b\u0107, \u017ce aplikacj\u0119 uruchomimy r\u00f3wnie \u0142atwo, to jeszcze dostajemy bardzo wygodny panel admina, kt\u00f3ry oszcz\u0119dza nam mas\u0119 pracy. I oczywi\u015bcie to jest prawda, ale gdybym chcia\u0142 na szybko stworzy\u0107 aplikacj\u0119 z wykorzystaniem Reacta, jeszcze jak\u0105\u015b tam obs\u0142ug\u0105 maili, to wydaje mi si\u0119, \u017ce to w\u0142a\u015bnie Laravel pozwoli\u0142by mi oszcz\u0119dzi\u0107 najwi\u0119cej czasu. Tym bardziej, \u017ce Django te\u017c zazwyczaj trzeba lekko dokonfigurowa\u0107.<\/p>\n\n\n\n
Struktura projektu Laravela vs inne frameworki<\/h2>\n\n\n\n Niestety tutaj mam pewne zastrze\u017cenia odno\u015bnie Laravela. Niestety projekty zazwyczaj s\u0105 brudne ju\u017c na samym starcie, zw\u0142aszcza je\u015bli por\u00f3wnamy struktur\u0119 tego frameworka, chocia\u017cby z Django, czy NestJS. Owszem, to s\u0105 inne j\u0119zyki programowania, ale w tym momencie patrz\u0119 na nie pod k\u0105tem dobrania technologii backendowej. W Laravelu mamy logiczny podzia\u0142 na controllery, modele, migracje, seedery, itp. co sprawdza si\u0119 ca\u0142kiem fajnie przy mniejszych projektach. Przy wi\u0119kszych, trzeba odpowiednio zaplanowa\u0107 tworzenie aplikacji, \u017ceby nie zrobi\u0107 ba\u0142aganu.<\/p>\n\n\n\n
A jak to wygl\u0105da w innych frameworkach? Przyk\u0142adowo – tworz\u0105c aplikacj\u0119 w Django, mog\u0119 stworzy\u0107 wewn\u0105trz projektu oddzielny modu\u0142 (aplikacj\u0119) dotycz\u0105cy zam\u00f3wie\u0144, danych klient\u00f3w, itp. Ka\u017cdy z tych modu\u0142\u00f3w posiada w\u0142asny controller, czy model (ma\u0142a uwaga – wiem, \u017ce Django operuje innym nazewnictwem, ale jest to artyku\u0142 dla os\u00f3b pocz\u0105tkuj\u0105cych i nie chc\u0119 tutaj miesza\u0107 tym, \u017ce widok w Laravelu i Django to dwie zupe\u0142nie r\u00f3\u017cne rzeczy. Dlatego pos\u0142uguj\u0119 si\u0119 wy\u0142\u0105cznie nomenklatur\u0105 Laravela<\/strong>). Takie podej\u015bcie wymaga co prawda pocz\u0105tkowego zastanowienia si\u0119 jak podzieli\u0107 aplikacj\u0119, ale w d\u0142u\u017cszej perspektywie daje bardziej schludny kod. Podobnie jest z NestJS, kt\u00f3ry nie tylko proponuje nam podobny podzia\u0142 aplikacji, ale zach\u0119ca nas do przenoszenia logiki biznesowej poza controller – do servic\u00f3w. Co prawda Laravel te\u017c to umo\u017cliwia, i zach\u0119cam trzymanie porz\u0105dku w controllerach, ale z do\u015bwiadczenia wiem, \u017ce wi\u0119kszo\u015b\u0107 programist\u00f3w Laravela \u0142aduje ca\u0142\u0105 logik\u0119 biznesow\u0105 do metod controllera i w ten spos\u00f3b powstaj\u0105 potworki, cz\u0119sto na kilkaset linii kodu. W\u0142a\u015bnie przez inn\u0105 struktur\u0119 aplikacji, w mojej ocenie nieco trudniej jest utrzyma\u0107 schludny kod.<\/p>\n\n\n\nPraca z baz\u0105 danych – ORM i relacje<\/h2>\n\n\n\n Praca z baz\u0105 danych jest dosy\u0107 prosta. Chc\u0105c utworzy\u0107 now\u0105 tabel\u0119, mo\u017cemy wyda\u0107 polecenie<\/p>\n\n\n\n
php artisan make:model Customer -m<\/code><\/pre>\n\n\n\nI tutaj zatrzymajmy si\u0119 na chwil\u0119. Powy\u017csze polecenie stworzy model o nazwie Customer, oraz odpowiedni\u0105 migracj\u0119, k\u00f3ra mo\u017ce wygl\u0105da\u0107 nast\u0119puj\u0105co<\/p>\n\n\n\n
public function up(): void\n {\n Schema::create('customers', function (Blueprint $table) {\n $table->id();\n $table->string('firstname');\n $table->string('lastname');\n $table->boolean('active')->default(1);\n $table->text('description')->nullable();\n $table->timestamps();\n });\n }<\/code><\/pre>\n\n\n\nJak wida\u0107, migracja pozwala stworzy\u0107 tabel\u0119 w bazie danych w bez por\u00f3wnania prostszy spos\u00f3b. Chc\u0105c doda\u0107 nowy record do bazy danych, albo chc\u0105c wypisa\u0107 recordy, odwo\u0142ujemy si\u0119 do modelu, np.<\/p>\n\n\n\n
\/\/ Wy\u015bwietl pierwszy record\n$customer = Customer::first();\n\n\/\/ wy\u015bwietl wszystkie recordy\n$customers = Customer::all();\n\n\/\/ wy\u015bwietl aktywnych klient\u00f3w\n$activeCustomers = Customer::where('active', 1)->get();\n\n\/*\nwy\u015bwietl aktywnych klient\u00f3w,\nkt\u00f3rzy zostali dodani do bazy w 2023 roku\n*\/\n$newCustomers = Customer::where('active', 1)\n ->whereYear('created_at', 2023)\n ->get();\n\n\/\/ wybierz klienta o konkretnym id\n$myCustomer = Customer::find(1);<\/code><\/pre>\n\n\n\njak wida\u0107 tworzenia prostych zapyta\u0144 jest wr\u0119cz bajecznie proste. R\u00f3wnie prosto wypada tworzenie relacji pomi\u0119dzy tabelami jest r\u00f3wnie proste, i robi si\u0119 to bezpo\u015brednio w modelu. Cz\u0119sto wymaga to te\u017c odpowiedniego przygotowania tabel, co jest oczywiste. Nie chc\u0119 tutaj jednak uczy\u0107 Ciebie samego Laravela, a jedynie pokaza\u0107 z czym to si\u0119 je.<\/p>\n\n\n\n
PHP Artisan<\/h2>\n\n\n\n Jak pisa\u0142em wy\u017cej, Laravel udost\u0119pnia fajne CLI, za pomoc\u0105 kt\u00f3rego mo\u017cemy wykona\u0107 wiele podstawowych, i powtarzalnych czynno\u015bci – stworzenie controllera, modelu, seedera, czy zmigrowanie bazy danych. O ile wi\u0119kszo\u015b\u0107 wsp\u00f3\u0142czesnych framework\u00f3w udost\u0119pnia jakie\u015b CLI, to uwa\u017cam, \u017ce to od Laravela zosta\u0142o ca\u0142kiem fajnie pomy\u015blane. Dodatkowo mo\u017cemy tworzy\u0107 w\u0142asne polecenia, kt\u00f3re wykonuj\u0105 okre\u015blone czynno\u015bci. S\u0105 te\u017c bardzo \u0142atwe do zapami\u0119tania. Zaczynaj\u0105 si\u0119 od php artisan<\/em>, albo od sail artisan<\/em>, je\u015bli korzystamy z Dockera.<\/p>\n\n\n\nTinker – pomocnik do pracy z bazami danych<\/h2>\n\n\n\n Innym tematem jest te\u017c Tinker<\/strong>. Jest to konsolowe narz\u0119dzie do pracy z baz\u0105 danych w \u015brodowisku Laravela. Oczywi\u015bcie \u017ceby sobie co\u015b na szybko podejrze\u0107 w bazie danych, mo\u017cemy skorzysta\u0107 z MYSQL WorkBrench,<\/em> czy innego, alternatywnego narz\u0119dzia. Tinker ma jednak t\u0119 zalet\u0119, \u017ce dzia\u0142a w \u015brodowisku Laravela, wi\u0119c operacje wykonujesz dok\u0142adnie tak samo jak w Laravelu – odwo\u0142uj\u0105c si\u0119 do modeli, a je\u015bli mamy jak\u0105\u015b relacj\u0119, to tak\u017ce bez problemu mo\u017cemy j\u0105 wy\u015bwietli\u0107.<\/p>\n\n\n\nWeso\u0142a tw\u00f3rczo\u015b\u0107 w Laravelu<\/h2>\n\n\n\n Laravel posiada ca\u0142kiem du\u017c\u0105 elastyczno\u015b\u0107, co mo\u017ce by\u0107 zalet\u0105, ale wed\u0142ug mnie jest pewn\u0105 wad\u0105. Pisa\u0142em ju\u017c o tym, \u017ce programista sam musi zatroszczy\u0107 si\u0119 o to, \u017ceby struktura jego projektu by\u0142a klarowna, oraz o to, \u017ceby zachowa\u0107 porz\u0105dek w controllerze, a jest du\u017ca pokusa, \u017ceby narobi\u0107 tam ba\u0142aganu. Przyk\u0142ad\u00f3w mo\u017cemy poda\u0107 jednak wi\u0119cej.<\/p>\n\n\n\n
We\u017amy za przyk\u0142ad validacj\u0119 danych, czyli jedn\u0105 z podstawowych funkcjonalno\u015bci backendowego frameworka. Mo\u017cemy to zrobi\u0107 na kilka sposob\u00f3w. Mo\u017cemy chocia\u017cby validowa\u0107 pola za pomoc\u0105 $request:<\/p>\n\n\n\n
$validated = $request->validate([\n 'title' => 'required|unique:posts|max:255',\n 'description' => 'required|min:100',\n ]);<\/code><\/pre>\n\n\n\nAlternatywnie mo\u017cemy chocia\u017cby stworzy\u0107 w\u0142asn\u0105 instancj\u0119, np. w takie spos\u00f3b:<\/p>\n\n\n\n
$validator = Validator::make($request->all(), [\n 'title' => 'required|unique:posts|max:255',\n 'description' => 'required|min:100',\n]);<\/code><\/pre>\n\n\n\nAlbo skorzysta\u0107 z mojej ulubionej metody, czyli przeniesienie ca\u0142ej validacji do osobnego pliku M\u00f3g\u0142by on wygl\u0105da\u0107 nast\u0119puj\u0105co<\/p>\n\n\n\n
class PostStoreRequest extends FormRequest\n{\n \/**\n * Determine if the user is authorized to make this request.\n *\/\n public function authorize(): bool\n {\n return true;\n }\n\n \/**\n * Get the validation rules that apply to the request.\n *\n * @return array<string, \\Illuminate\\Contracts\\Validation\\Rule|array|string>\n *\/\n public function rules(): array\n {\n return [\n 'title' => 'required|unique:posts|max:255',\n 'description' => 'required|min:100',\n ];\n }\n}<\/code><\/pre>\n\n\n\nI zanim powiedzie, \u017ce ostatnia metoda jest najbardziej skomplikowana, to powiem tylko, \u017ce ca\u0142y ten plik jest generowany za pomoc\u0105 omawianego wcze\u015bniej CLI, a w tym konkretnym przypadku edytuj\u0119 tylko rules().<\/p>\n\n\n\n
No ale w czym problem, mo\u017cesz zapyta\u0107? Ka\u017cdy sobie wybierze metod\u0119, kt\u00f3ra b\u0119dzie dla niego najlepsza i wszyscy b\u0119d\u0105 zadowoleni. Niestety tak si\u0119 sk\u0142ada, \u017ce mia\u0142em okazj\u0119 wchodzi\u0107 do projekt\u00f3w, nad kt\u00f3rymi pracowa\u0142o ju\u017c wcze\u015bniej kilku programist\u00f3w, a te projekty nie by\u0142y mocno nadzorowane od strony technicznej, wi\u0119c ka\u017cdy to robi\u0142 troch\u0119 po swojemu. Uwierzcie mi – odnalezienie si\u0119 w taki projekcie nie jest \u0142atwe, a czym wi\u0119cej opcji mamy na stole, tym potencjalnie wi\u0119ksze ryzyko narobienia syfu.<\/p>\n\n\n\n
Jest jeszcze jedno ryzyko – osoby dopiero zaczynaj\u0105ce mog\u0105 czu\u0107 si\u0119 zagubione. Bo kt\u00f3ra opcja jest najlepsza? Ja z do\u015bwiadczenia wiem, \u017ce najbardziej wol\u0119 opcj\u0119 ostatni\u0105, ale osoba pocz\u0105tkuj\u0105ca takiego rozeznania nie ma i mo\u017ce czu\u0107 si\u0119 zagubiona.<\/p>\n\n\n\n
Zwr\u00f3\u0107 uwag\u0119, \u017ce m\u00f3wili\u015bmy tylko o validacji – a takich rzeczy jest na prawd\u0119 du\u017co!<\/strong><\/p>\n\n\n\nInny przyk\u0142ad, to gdzie zastosowa\u0107 middleware, jak ogarn\u0105 logik\u0119 biznesow\u0105, jak uporz\u0105dkowa\u0107 routing.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Wdra\u017canie aplikacji<\/h2>\n\n\n\n Laravel jest napisany w PHP, wi\u0119c w zasadzie mo\u017cesz tak\u0105 aplikacj\u0119 wdro\u017cy\u0107 na ka\u017cdym hostingu wsp\u00f3\u0142dzielonym. O ile coraz wi\u0119cej hosting\u00f3w umo\u017cliwia hostowanie aplikacji napisanych w JavaScript, czy Python, o tyle dalej j\u0119zyk PHP jest najpopularniejszym j\u0119zykiem tworzenia backendu stron internetowych. Dlatego tworz\u0105c stron\u0119 dla klienta, albo tworz\u0105c oprogramowanie open source, mniej zaawansowanym u\u017cytkownikom \u0142atwiej b\u0119dzie wdro\u017cy\u0107 aplikacj\u0119 napisan\u0105 w PHP.<\/p>\n\n\n\n
W jakich projektach Laravel sprawdzi si\u0119 najlepiej?<\/h2>\n\n\n\n Wachlarz zastosowa\u0144 Laravela jest bardzo szeroki. Z pewno\u015bci\u0105 by\u0142by jednym z pierwszych wybor\u00f3w przy tworzeniu CMSa, zw\u0142aszcza gdybym chcia\u0142 go udost\u0119pni\u0107 innym u\u017cytkownikom, tak\u017ce mniej technicznym. Poza tym – wszelkiej ma\u015bci narz\u0119dzia do wewn\u0119trznego u\u017cytku firmy, szybkie i ma\u0142e projekty, MVP, mo\u017ce nawet rozwa\u017cy\u0142bym budow\u0119 niewielkiego sklepu internetowego. <\/p>\n\n\n\n
Sprawdzi si\u0119 te\u017c do tworzenia API dla innych aplikacji, np. mobilnych, a prywatnie tworz\u0119 w nim co\u015b w rodzaju portalu spo\u0142eczno\u015bciowego, ale jest to projekt poboczny. W gruncie rzeczy wi\u0119kszo\u015b\u0107 projekt\u00f3w mo\u017cna stworzy\u0107 w Laravel. Prawdopodobnie zastanowi\u0142bym si\u0119 przy bardzo du\u017cych projektach. Gdybym musia\u0142 u\u017cy\u0107 baz noSQL to te\u017c wybra\u0142bym inn\u0105 opcj\u0119.<\/p>\n\n\n\n
Podsumowanie<\/h2>\n\n\n\n Laravel do \u015bwietny framework, kt\u00f3rego na prawd\u0119 warto si\u0119 uczy\u0107. Ma niski pr\u00f3g wej\u015bcia, oferuje pe\u0142ne \u015brodowisko do pracy, dzi\u0119ki czemu mo\u017cna bardzo szybko rozpocz\u0105\u0107 prace nad nowym projektem. Sprawdzi si\u0119 przy wi\u0119kszo\u015bci projekt\u00f3w, ale niestety czasami ci\u0119\u017cko jest utrzyma\u0107 kod w dobrej kondycji. Dlatego nie jestem przekonany, czy jest to najlepsze rozwi\u0105zanie do pracy w du\u017cych zespo\u0142ach programist\u00f3w.<\/p>\n","protected":false},"excerpt":{"rendered":"
Laravel by\u0142 drugim, po Code Igniter, frameworkiem PHP, kt\u00f3ry opanowa\u0142em. To w nim jednak zacz\u0105\u0142em programowa\u0107 zawodowo, oraz robi\u0107 projekty poboczne i hobbystyczne. Pomimo, \u017ce pracuj\u0119 te\u017c z innymi technologiami, do tej pory jest to framework backendowy, kt\u00f3rego u\u017cywam najcz\u0119\u015bciej. W niniejszym artykule postaram si\u0119 co nieco powiedzie\u0107 o jego wadach i zaletach. Nie b\u0119d\u0119 […]<\/p>\n","protected":false},"author":1,"featured_media":77,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-72","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-programowanie"],"_links":{"self":[{"href":"https:\/\/webowyswiat.pl\/wp-json\/wp\/v2\/posts\/72","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webowyswiat.pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webowyswiat.pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webowyswiat.pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webowyswiat.pl\/wp-json\/wp\/v2\/comments?post=72"}],"version-history":[{"count":28,"href":"https:\/\/webowyswiat.pl\/wp-json\/wp\/v2\/posts\/72\/revisions"}],"predecessor-version":[{"id":364,"href":"https:\/\/webowyswiat.pl\/wp-json\/wp\/v2\/posts\/72\/revisions\/364"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webowyswiat.pl\/wp-json\/wp\/v2\/media\/77"}],"wp:attachment":[{"href":"https:\/\/webowyswiat.pl\/wp-json\/wp\/v2\/media?parent=72"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webowyswiat.pl\/wp-json\/wp\/v2\/categories?post=72"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webowyswiat.pl\/wp-json\/wp\/v2\/tags?post=72"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}