для меня наступил интересный момент развития как программиста, мне поставили задачу написать новый АПИ для нашего проекта. есть старый апи, и есть опытный человек который поможет. но пока задача была поставлена так - думай... я хз в какую сторону думать, какие паттерны и какие технологии мне пригодится Нужен совет сообщества Fella, какие паттерны какие технологии, куда смотреть что читать и куда бежать, на чем сделать акцент, может сперва подготовить документацию. прозвучал как то graphql - мне оно нужно? Буду благодарен любой информации
API пишется не для того чтобы было, а под конкретную цель... Узнай - для чего писать новый API, чем не устраивает старый... на основе этого делай выводы и делай...
Сразу закладывайся на документацию. Без неё считай нету у тебя API. Есть разные реализации для генерации страничек с описанием. Лично мне по вкусу когда она генерится из атрибутов phpdocs, Паттерны? Принципы RestfulAPI graphql? тебе не нужно. )
лару взял и погнал ) там под любой апи всё есть да всё то же самое что с html, только без html вываливаешь чистые данные в JSON и всё ) неужели не приходилось реализовывать AJAX-ы какие то с JSON ответами? принцип же простой как палка
приходилось конечно. у нас есть старый апи, но у меня нет понимания что с ним не так, он(о) работает, оно было написано давно. Сейчас цели и функционал выросли, и нужно переделать, 80% урлов останется, 80% БД таблиц останется. а саму структуру нужно переписать. Видимо пока я не чисто не пойму проблематику старого апи, не смогу написать новый. graphql - мне предложили для более быстрого взаимодействия с БД. кстати laravel api, интересная идея. Но что то мне подсказывает что ларавель будет отвергнул ввижу потециально низкой скорости работы
просто так и спрашиваешь - что не так со старым API, что должно измениться с появлением нового нормальная у лары скорость работы всё торможение почти всегда возникает при работе с БД и с внешними API сам PHP работает достаточно быстро, чтобы о нём можно было не думать
1. Для начала нужно понять - для чего будет использоваться API (для моб приложений, для фронта, общедоступный для клиентов, партнеров). Кароче- кто, как и зачем будет забирать данные. 2. ... надеюсь предыдущая версия api поддерживает версионность?))) ну когда например /api/v1/... отдает данные по старому, а api/v2/... уже отдает новый api. Даже если нет - советую заложить в новой версии. Кроме того непонятно - неужели для api будут введено 20% новых таблиц? ... странно... api обычно работает с уже существующей структурой БД. 3. Ну и возвращаемся к началу - без понимания, зачем надо это делать - лучше этого не делать )))
а что конкретно там есть "все"? Что по сути мне нужно? ну роутинг понятное дело. валидация? что еще? --- Добавлено --- почему не нужно? можешь попробовать развернуть мысль? мне нужны аргументы. Насколько я понял что графюл возврвщает данные более структурированно. Мне не нужно гонять туда сюда огромные jsonы, я буду получать ровно то что я прошу... Ну это как я понимаю его работу. А как на самом деле?
валидация роли разрешения/доступы response json structure REST свои правила response status-success action-false response status-success action-update-container ... обновить часть страницы с указанным контейнером response status-success action-message-container ... логин пуст... пароль пуст... все пучком response status-success action-message-alert ... логин пуст... пароль пуст... все пучком response status-success action-redirect response status-failed .... 404... 500... могу в дисе показать как выглядит это. Если строить систему управления клиентами, подписками, с различными/безумными хотелками (CRM) -- придется писать с нуля, юзая лишь компоненты.
повышенная сложность реализации. для любого усложнения должна быть стопудово веская причина. а не просто "было бы здорово, модно, красиво". почаще задавай вопрос "зачем?". половина запросов сама отпадёт за ненадобностью, а вторая половина будет изложена так, что решение окажется на поверхности. --- Добавлено --- вот зачем захотелось переписать API? наверное затем, что старый стало трудно поддерживать. так вот, стремись к простоте и постоянству в выборе решений. тогда твой API будет расти без загнивания.
вот развернул я свой laravel 8 проект в контейнере. накидал самые простые методы возвращения данных из БД. Теперь мне нужно продать идею использования laravel для написания апи. Но у меня самый простой запрос через get к контроллеру работает минимум 5 секунд... так я идею не продам ))) чего так долго? так должно быть? если я создаю пустой index.php в паблике, он отработает мгновенно, значит контейнер настроен правильно.
это только значит, что у тебя php настроен. а ларавель может тормозить по множеству причин. он использует базу, возможно пытается обратиться к другим серверам за redis или ещё какими ресурсами. возможно файловая система медленная, ведь фреймворк читает сотни файлов. возможно твой комп дохлый, памяти не хватает - он свопит на диск, который тормозной. главное, Женя, не валить задачи в кучу. каждая проблема стоит отдельной темы ))) как программист в команде ты должен это знать. --- Добавлено --- составь чеклист версий и отмечай какие пункты проверены и как.
сферический конь в ваккуме... нужно смотреть что и как ты накидал.... а чего бы пустому индексу не работать моментально.. он же пустой, ты запрос на чистом php реализуй, и на ларке и сравни, после этого громкие заявления делай....
какия громкие заявления ты имеешь виду? пока не ясно booting - 5sec application - 2-3 sec.. прямое подключение к БД работает быстро, что то в bootstrap долго грузиться... ща разберемся ) сложность в том что ларка установленная из коробки, что бы проверить что увеличивает вермя загрузки, придется все подряд отключать, а отключать вообще не хочется с учетом того что мне кжется, что все что работает из коробки отключать нельзя )