Вы на стороне сервера и вас волнует компетенция человека, описывающего вручную доку. Меня одновременно волнуют компетенции бэкендщика, который решил сам придумать АПИ, и фронтендщика, с фантазиями как бы хорошо было бы… Поэтому и хочу сервис, где согласовывались бы обе стороны. Если бэкенд опережает на месяц и супер адекват — его вариация доки примется в большей степени. И наоборот. Или отдельный адекватный, который найдет компромисс :)
Детализируя требования, получаем документацию. Сделать это могут не все, и не ставится вопрос о практичности детализировать на 100%. Сгенерированная по коду документация будет полнее (хотя не факт). Но содержать будет только то, за что взялись разработчики. Когда как для пользователей (разработчиков фронта, приложений...) можно вручную описать будущее API, для разработчиков сервера оно снимет лишние вопросы. И разве это плохо или не правильно? Я бы хотел инструмент, где сосуществовали оба подхода к документированию, дополняли друг друга.
Не видно аргументации. Если вас пугает количество колонок, то знайте — это цена за скорость выборки, изменений и сравнительно простой реализации. Реализация может незначительно усложняться, чтобы нивелировать ограничение по глубине, сделать оптимальную индексацию.
Чаще чем никогда :) API — это не только результат творчества разработчика сервера. Требования пользователей API нужно учитывать. По моему, задокументировать эти требования лучше всего.
Для разработчика сервера все равно пишется некое ТЗ по АПИ. У нас это фактически дока. Конечно писать её сразу правильно в формате сваггера лениво и мы реальную доку генерируем по коду. Но может визуальные редакторы бы облегчили задачу. А в купе с заглушками, пока сервер не готов, было бы совсем здорово. Я поэтому в ветке выше и подумал о сервисе, который бы автоматизировал рутинные процессы для двух сторон разработки.
Соглашусь, что кто-то из сторон в этом случаи полениться делать доку, если она уже есть. Хм, хотя если бэкенд предоставляет апи вперед ручного описания, то можно её принять. А для бэкенда можно предложить аннотацию для копипаста…
Не понимаю к чему ваши вопросы. Разбивая путь по колонкам имеем целочисленные колонки под идентификаторы родителей. Нужно выбрать всех детей какого-то объекта — делаем условие равенства на соответствующую колонку. Ограничение связано с максимальным количеством колонок у таблицы.
Путь можно по колонкам разбить. С такой реализацией и быстро и довольно дешево редактировать. Ограничение по глубине можно обходить используя дополнительные таблицы.
Хочу сервис, в котором с одной стороны вручную пишешь документацию к апи с примерами ответов (заглушки) и тем самым сразу можно применять в приложении. С другой стороны бэкенд генерирует доку к апи. Две доки сервисом соединяются, проверяются расхождения. И получается АПИ с уже реализованными методами, методы на заглушках и методы, сделанные вперед ручного описания. В документации как-то помечается статус реализации метода.
Есть ли такие?
Может быть присваивать описание класса в переменную и ими манипулировать? =) Сейчас это скорее одноразовые классы нежели анонимные. Для функций ведь сделали closures. Надо для классов что-то подобное.
Существенным недостатком для меня оказалась невозможность динамически добавить компоненты в страницу или просто поменять шаблон у компонента (получить его с сервера и скомпилировать). В приложении изначально должна быть определена иерархия компонентов, можно управлять только видимостью компонентов. Подгружать с сервера компоненты идеологически нельзя и автор не намерен это делать или принимать пул. реквесты по этой теме.
Тогда к чему возможность столько колонок иметь?
Водолаза — охраника
А что касательно обеспечения безопасности?
Что если на все 1600 колонок целого типа повесить b-tree не уникальные индексы?
Для прописывания сваггер аннотации к методу, чтобы с генерированная потом дока соответствовала требуемой.
Вы на стороне сервера и вас волнует компетенция человека, описывающего вручную доку. Меня одновременно волнуют компетенции бэкендщика, который решил сам придумать АПИ, и фронтендщика, с фантазиями как бы хорошо было бы… Поэтому и хочу сервис, где согласовывались бы обе стороны. Если бэкенд опережает на месяц и супер адекват — его вариация доки примется в большей степени. И наоборот. Или отдельный адекватный, который найдет компромисс :)
Детализируя требования, получаем документацию. Сделать это могут не все, и не ставится вопрос о практичности детализировать на 100%. Сгенерированная по коду документация будет полнее (хотя не факт). Но содержать будет только то, за что взялись разработчики. Когда как для пользователей (разработчиков фронта, приложений...) можно вручную описать будущее API, для разработчиков сервера оно снимет лишние вопросы. И разве это плохо или не правильно? Я бы хотел инструмент, где сосуществовали оба подхода к документированию, дополняли друг друга.
Не видно аргументации. Если вас пугает количество колонок, то знайте — это цена за скорость выборки, изменений и сравнительно простой реализации. Реализация может незначительно усложняться, чтобы нивелировать ограничение по глубине, сделать оптимальную индексацию.
Чаще чем никогда :) API — это не только результат творчества разработчика сервера. Требования пользователей API нужно учитывать. По моему, задокументировать эти требования лучше всего.
Для разработчика сервера все равно пишется некое ТЗ по АПИ. У нас это фактически дока. Конечно писать её сразу правильно в формате сваггера лениво и мы реальную доку генерируем по коду. Но может визуальные редакторы бы облегчили задачу. А в купе с заглушками, пока сервер не готов, было бы совсем здорово. Я поэтому в ветке выше и подумал о сервисе, который бы автоматизировал рутинные процессы для двух сторон разработки.
Соглашусь, что кто-то из сторон в этом случаи полениться делать доку, если она уже есть. Хм, хотя если бэкенд предоставляет апи вперед ручного описания, то можно её принять. А для бэкенда можно предложить аннотацию для копипаста…
Не понимаю к чему ваши вопросы. Разбивая путь по колонкам имеем целочисленные колонки под идентификаторы родителей. Нужно выбрать всех детей какого-то объекта — делаем условие равенства на соответствующую колонку. Ограничение связано с максимальным количеством колонок у таблицы.
Путь можно по колонкам разбить. С такой реализацией и быстро и довольно дешево редактировать. Ограничение по глубине можно обходить используя дополнительные таблицы.
Хочу сервис, в котором с одной стороны вручную пишешь документацию к апи с примерами ответов (заглушки) и тем самым сразу можно применять в приложении. С другой стороны бэкенд генерирует доку к апи. Две доки сервисом соединяются, проверяются расхождения. И получается АПИ с уже реализованными методами, методы на заглушках и методы, сделанные вперед ручного описания. В документации как-то помечается статус реализации метода.
Есть ли такие?