Vitsliputsli, Баги в программах появляются только потому, что мы люди. А чем больше всего программисту нужно держать в голове при написании программы, тем выше шансы внесения бага. Мы как LLM, можем держать в голове только определенное количество контекста. И если этот контекст переполняется, мы начинаем галлюцинировать багами в программе.
Задайте себе вопрос: зачем придумали Rust? Главная цель создания этого языка была в том, чтобы сделать работу с памятью безопасной. А почему это так сильно нужно было? Потому что программистам оказалось очень тяжело держать в голове информацию о том, где и когда они выделяли память, и где и когда надо её освобождать. Это чуть ли не главная проблема современности. Rust заставляет это делать при помощи своих механизмов, у человека теперь просто нет возможности внести такой баг.
Точно такая же логика касается языков с динамической типизацией. Человеку надо столько всего учитывать, что он просто иногда не справляется. Строгая типизация полностью исключает такие баги. Не зря потрачено столько времени и денег на создание Typescript. Этот язык чуть ли не стал стандартом в мире JavaScript на бэкенде.
PHP не пошёл таким радикальным путём, как Typescript, и я считаю это большой ошибкой. Совершенно понятно, что такое половинчатое решение было сделано ради совместимости. Но компромиссы редко приводят к чему-то толковому.
Совет на будущее: создавайте всегда для сайтов их собственные учётки.
Вот сейчас вы пытаетесь перепривязать капчу на свою учётку. А представьте, что наступят тяжёлые времена, и вам надо будет сайт продать. Это будет означать, что снова надо будет проводить работы на сайте.
Ваши личные учётки могут по разным причинам забанить, взломать и т.д.
Даже если вам удобно собирать email с сайта на свою личную почту, то лучше переадресовать все письма с ящика сайта на свой личный ящик, чем использовать свой аккаунт
В любой беседе всегда нужно сперва договориться о терминах. И если преподаватель бросается какими-то терминами, то их определение он либо объяснял ранее на занятиях, либо вы должны потребовать от него определение термина "утилита для автоматизированного проектирования".
Он должен перечислить вам критерии, по которым вы должны понимать, что перед вами именно эта хрень, а не что-то другое.
Например, я могу любую ORM, поддерживающую миграции, назвать такой утилитой. Ведь там ты описываешь классы, которые можно назвать проектом, а оно тебе автоматически создаёт нужные миграции для создания базы.
Ну не надо оно вам. Поверьте. Как часто на практике приходится менять имя модуля? А если приходится, то что-то вы не так делаете.
Если всё же для вас это критично, то купите себе Jetbrains Goland. Там очень мощный рефакторинг. Например, изменив имя пакета при помощи опции "Rename", он попытается не только изменить все импорты этого пакета в проекте, но даже название директории пакета изменит.
Steel_Balls, А я вам объясню, как это получилось.
Чтобы понять, почему от полного рендеринга на сервере перешли к созданию монструозных SPA, надо понять, что в те годы распространённость быстрого интернета была всё ещё крайне мала, а вот компьютеры стали уже достаточно быстры, да и памяти у них стало значительно больше. Поэтому, с ростом сложности проектов и динамики на страничках SSR начинал тормозить из-за того, что большое количество одновременных запросов не укладывалось в трафик. Решением этого стало кэширование данных в браузере, перенос значительной части функционала в SPA, а общение с сервером стало редким и передавалось мало данных. И это была революция для того времени, ведь можно было пользоваться сложным сайтом даже при наличии 3g модема на телефоне в глухой местности.
Но не будем забывать, что это привело к такому росту сложности браузерного фронтенда, что совсем скоро браузеры превратились в основного пожирателя памяти компьютера. Наличие двух образов данных в браузере и на бэкенде неминуемо привело к росту багов из-за их неверной синхронизации и из-за того, что данные иногда по-разному валидировались в браузере и на сервере. По этому поводу уже давно шло ворчание в соцсетях.
И вот... Случилось... Интернет стал быстрым почти везде, 4G и 5G сделали смартфоны иногда даже быстрее домашнего интернета. Серверы переехали в облака и стали невероятно быстрыми. В результате, уже классические SPA превратились в анахронизм, от которого вреда стало гораздо больше, чем пользы. И люди стали возвращаться к тому, что гораздо лучше и проще - к SSR. Вот и всё.
RadioC, Сайтик, конечно, имеет немножко устаревший дизайн, но вроде бы работает без тормозов, и если он приносит прибыль, то это не так критично. Конечно, мобильная версия далека от идеала, но если клиенты в основном смотрят на десктопе, то и так сойдёт. У меня вот прям слезы ностальгии выступили, я ведь в десятые года как раз такие клепал.
Если я верно понял, то там нет личного кабинета покупателя, а покупки - это просто формы, которые отправляет покупатель, и с ним потом связываются.
Т.е., в принципе, если не хочется переосмысливать дизайн, то можно не обновляться, но обязательно настроить у хостера как можно более частый бэкап, чтобы в случае взлома и шифровки базы было откуда быстро откатиться без потерь контента.
В общем, если затеивать обновление, то работы будет не намного меньше, чем при создании сайта с нуля, т.е. можно будет уже подумать и о новом дизайне, особенно в мобильной версии!
Поспрашивал знакомых, все говорят, что заняты, а может, не хотят возиться. Сам уже давно потерял компетенцию в Drupal, а какую-то студию рекомендовать не могу, так как живу не в РФ.
Ищите контору с хорошими отзывами и портфолио с сайтами, которые выглядит современно, лаконично, а, главное, молниеносно грузятся. Очень тщательно изучите как их сайты ведут себя в мобильной версии. Грехи в мобильной версии выдают неаккуратность исполнителя. Успехов!
Vitsliputsli, BFF - это про сессии, httponly secure cookies, правильный csfr.
Если бы вы знали, как безответственно некоторые фронтендеры относятся к безопасности, храня самые секретные токены где попало, то не говорили бы такое про BFF.
Второй пункт - SSR. Две первые буквы в HTTP обязываются Hyper Text. Разметка передаётся быстро, сразу вставляется в DOM без идиотского медленного парсинга километров JSON. Состояние сессии хранится только в одном месте - на бэке, таким образом не надо тратить нервы на затратную синхронизацию состояния при помощи монструозного пожирания памяти.
Третий пункт - это скорость разработки. Фронтендеру при разработке MVP иногда надо менять API по нескольку раз в день. Я, как бэкендер, послал бы его на три буквы и требовал бы тикетов от менеджера, потому что у меня и так делов полно. Это сильно замедляет разработку.
И т.д., и т.п.
Alex, Всё всегда зависит от проекта и сроков.
Если всё горит, фронтендер уже почти наклепал сайт на Реакте, манагер орёт, что проект должен был быть готов ещё вчера, то берём Symfony + Doctrine + API Platform, и за один день собираем CRUD, который на первых порах будет прекрасно работать.
Если же проект серьезный, время есть, или просто хочется изучить Go, то выбросьте из головы эту джаваскриптизёрскую парадигму о том, что надо ставить npm модуль даже для определения четности числа.
Пишите всё сами, у Go одна из лучших стандартных библиотек. Например, роутер я уже давно использую только стандартный, там есть всё. Строение библиотеки ставьте только тогда, когда вот совсем не знаете, как написать что-то. Для безопасности поставьте пакеты от gorilla (сессии, csrf и т.д.), для работы с базой sqlc. Тут вы пишете в специальных файлах SQL, а sqlc вам сам сгенерирует код для работы с базой в Go. Если хотите сами написать и фронтенд, то очень советую изучить подход, реализуемый HTMX, и тогда вам для написания динамического сайта даже не потребуется знать JavaScript.
Гошники не зря плюются от ООП, ORM, фреймворков, зависимостей и т.д. Это не потому, что мы какие-то заносчивые снобы, а потому, что мы знаем простую истину: чем программа проще, чем меньше в ней магии и зависимостей, тем меньше у нас седых волос и бессонных ночей.
Именно всяческие идиотские глюки и особенности этого костыля насильно заставили меня много лет назад полностью перейти на Linux на десктопе, а потом на Mac. Ни секунды не жалел об этом. Вспоминаю это чудовище как ночной кошмар, который активно мешал заниматься работой.
Вам бесплатный совет, который надо запомнить на всю жизнь: никогда не давайте никому root права. Даже сами не пользуйтесь root учёткой, а создайте себе самому пользователя, который может использовать sudo.
Это как мыть руки перед едой - вопрос гигиены. Да, 999 раз из 1000 ничего не случится, но в самый неподходящий момент подхватите какую-то такую болячку, которая 10 лет жизни заберёт.
Создайте группу, создайте права для этой группы, создайте пользователя для этой группы. Потратьте какое-то время, но обезопасьте себя.
Советы на будущее:
1. Goland часто тупит. Иногда помогает инвалидация кэша. File - Invalidate Caches
2. В связи с текущей ситуацией рекомендую включить вендоринг пакетов (go mod vendor). Таким образом ваши внешние пакеты будут храниться прямо в проекте в директории vendor. Вы можете их закоммитить в git, и тогда вы сможете спокойно собирать ваш проект всегда и везде: и на локалке, и на проде без пляски с VPN и прокси. А VPN вы будете включать только при установке новых пакетов у себя на компе. Больше VPN вам не нужен Дальше завендорите новый пакет, закоммитите его в git, и спокойно работаете.
Anna0802, Это очень правильно. Код пишите только сами. Иначе не научитесь. ИИ просто использовать вместо Гугла.
Совет: когда будете учить CSS, нет ничего лучше, чем изучать чужую работу. Находите что-то прикольное в интернете, и смотрите, как они это сделали. Там просто масса идей, которым вас никто не научит
Задайте себе вопрос: зачем придумали Rust? Главная цель создания этого языка была в том, чтобы сделать работу с памятью безопасной. А почему это так сильно нужно было? Потому что программистам оказалось очень тяжело держать в голове информацию о том, где и когда они выделяли память, и где и когда надо её освобождать. Это чуть ли не главная проблема современности. Rust заставляет это делать при помощи своих механизмов, у человека теперь просто нет возможности внести такой баг.
Точно такая же логика касается языков с динамической типизацией. Человеку надо столько всего учитывать, что он просто иногда не справляется. Строгая типизация полностью исключает такие баги. Не зря потрачено столько времени и денег на создание Typescript. Этот язык чуть ли не стал стандартом в мире JavaScript на бэкенде.
PHP не пошёл таким радикальным путём, как Typescript, и я считаю это большой ошибкой. Совершенно понятно, что такое половинчатое решение было сделано ради совместимости. Но компромиссы редко приводят к чему-то толковому.