я вижу разницу между net/http, на котором на коленке можно реализовать базовую бизнес-логику плагинами, и здоровенной либой, реализующей какой-то навязанный стандарт и от которой польза для бизнес-логики довольно сомнительная

я не следил за всей вашей дискуссией, я может не в тему совсем, но мне ваш пост немного напоминает ситуацию которую я уже наблюдал: все рассказывают "net/http хватит всем", потом тащат к себе в апишку половину gorilla и еще парочку-другую утилит каких-нибудь, testify какой, то есть получается такой себе handmade framework все равно, но все потом довольно урчат, что им стдлибы хватает :) возможно я не прав и мне просто не везло с апишками которые я видел. в целом же я не совсем против такого подхода, скорее наоборот это лучше чем если бы все сами велосипедили. но немного пахнет лицемерием. готов выслушать почему я мудак и вообще не прав.

Никто не спорит, но позволяет быстро связать в кучу сервис А с сервисом Б

как и куча любых других протоколов прикладного уровня, grpc, например. Просто так уж повелось, что его легче интегрировать с другими проектами.

ну, я кого спрашивал - все соглашались, мол, тяжелое наследие, отходим потихоньку

Подобная выборка нерепрезентативна

как и куча любых других протоколов прикладного уровня, grpc, например. Просто так уж повелось, что его легче интегрировать с другими проектами.

Это экономия времени

Почему билинг билайна — легаси, а graphql — нет? Не знаю, ты мне запретил сравнивать несравнимое

ну, это оба протоколы прикладного уровня, которые позволяют делать вложенные запросы и варианты RPC

всю жизнь в банках работаю, не видел)

Попадаются регулярно, если мне не изменяет память компас по нему только в путь ездит

ну, это оба протоколы прикладного уровня, которые позволяют делать вложенные запросы и варианты RPC

биллинг-система == протокол?

Да и сентри тоже

давно хочу на раст посмотреть, видимо, не зря

Заходи к нам в чатик

Попадаются регулярно, если мне не изменяет память компас по нему только в путь ездит

сочувствую

я не следил за всей вашей дискуссией, я может не в тему совсем, но мне ваш пост немного напоминает ситуацию которую я уже наблюдал: все рассказывают "net/http хватит всем", потом тащат к себе в апишку половину gorilla и еще парочку-другую утилит каких-нибудь, testify какой, то есть получается такой себе handmade framework все равно, но все потом довольно урчат, что им стдлибы хватает :) возможно я не прав и мне просто не везло с апишками которые я видел. в целом же я не совсем против такого подхода, скорее наоборот это лучше чем если бы все сами велосипедили. но немного пахнет лицемерием. готов выслушать почему я мудак и вообще не прав.

я нигде не говорил, что net/http всем хватит обязательно, и я полностью с тобой согласен :) мой пойнт был в том, что я не вижу смысла променивать готовый фреймворк, в котором большинство бизнес-задач решено уже либами, на дополнительную прослойку с навязанным стандартом и дополнительными сложностями

сочувствую

Я завязал с банками)

биллинг-система == протокол?

soap - протокол. Причем тут биллинг вообще?

Заходи к нам в чатик

а я там есть. Просто не засел еще основательно за изучение

soap - протокол. Причем тут биллинг вообще?

Перечитай ветку плес, можешь просто покликать на реплаи

Перечитай ветку плес, можешь просто покликать на реплаи

перечитал. И?

соап - легаси, да, но его до сих пор используют

перечитал. И?

Я тебе говорю что биллинг билайна легаси — по этому там и соап

Я тебе говорю что биллинг билайна легаси — по этому там и соап

но в интерпрайзе соап и сейчас используют, вот в чем штука

и даже необязательно в легаси-проектах

Потому что в энтерпрайзе много легаси и разработчиков перешедших с поддержки легаси?

Потому что в энтерпрайзе много легаси и разработчиков перешедших с поддержки легаси?

да, логично

я с этим и не спорил

а в чем тезис?

Проблема уровня "зачем до сих пор пишут на Си, когда есть C++"

а в чем тезис?

Забей, мы друг друга дважды не поняли за последние 10 минут

Проблема уровня "зачем до сих пор пишут на Си, когда есть C++"

вот именно! выше Ник так и писал - зачем ваш REST, когда уже есть GraphQL

поэтому и началось

Ну я не отрицаю что рест нужен. Но если есть возможность, почему бы не попробовать GraphQL?

Ну я не отрицаю что рест нужен. Но если есть возможность, почему бы не попробовать GraphQL?

да я не против, можно, я даже назвал несколько кейсов, где он может выстрелить, типа того же гитхаба

я не говорю, что он в принципе не нужен

вот именно! выше Ник так и писал - зачем ваш REST, когда уже есть GraphQL

ебанулся? я так не писал

но я не вижу его никак заменой реста и не вижу его применимость за крайне узкой областью

ебанулся? я так не писал

было-было. Сейчас наскроллю, если не удалил

Я лишь спросил, почему он не нужен и привел кейс когда он вполне себе ок

Я лишь спросил, почему он не нужен и привел кейс когда он вполне себе ок

а, сорян, это не ты писал, это Александр

ну ты и Толстой

REST - прошлое

json-rpc v2.0 хотя бы уж

ну ты и Толстой

да кто вас, спорщиков, разберет

@mersinvald скок хелоу ворлд весит кстати?)

А часто ты деплоишь хелловорлды?)

Тут уж было бы правильнее сравнивать вес рестапи реализации с базой

А часто ты деплоишь хелловорлды?)

не, мне интерсно именно хелоу ворлд)

Тут уж было бы правильнее сравнивать вес рестапи реализации с базой

мне вот интересно посмотреть на реализацию graphql поверх базы и тесты для всего этого

а то абстрактная либа в вакууме - как-то неинтересно

не, мне интерсно именно хелоу ворлд)

С дебагинфо 4.8мб Стрипнутый 452кб

я тебе скидывал ссылку, замени data класс на базу и радуйся

С дебагинфо 4.8мб Стрипнутый 452кб

Это на линуксе

На других осях в зависимости от реализации бектрейса может быть иначе

Это на линуксе

а ключи какие?

--release

в 2 раза меньше хаскеля)

Минус рантайм)

Ну да

вот кстати продукт, который юзает графкуэль https://demo.databaseflow.com

graphql мб и хорошая штука, но большого смысла в нем не вижу... для фронта мб и удобно))) Мне пока хватает простого Rest...

https://medium.com/kokster/writing-a-jit-compiler-in-golang-964b61295f

ребят, GORM должен сам создавать fk?

У вас у списка файлов зависимость от топика?

да, File.TopicID

у топика может быть множество файлов

fk только при необходимости создается. Если зависимость именно такая останется, как у вас сейчас, то больше не обязательно ничего указывать.

не совсем понимаю что значит при необходимости

внешний ключ и есть внешний ключ

Ну не везде же делается внешний ключ. В Горм можно только указать, если внешний ключ является по имени каким-то другим по моему.

ERROR: S client not available

Удалось решить добавлением TopicID uint sql:"type:integer REFERENCES topics(id)"

что не совсем прозрачно описано в документации ?

Прозрачно. Там написано, что зависимость, это имя структуры + ID.

У вас так и получилось. Что вы имя структуры описали Topic + ID.

да но по факту в базе не был создан внешний ключ, вот я о чем

да но по факту в базе не был создан внешний ключ, вот я о чем

Здесь больше для удобного поиска зависимостей это делается. Не более того. topic.ID = 8 db.Model(topic).Related(&Files)

ну т.е. сама ORM не предполагает создание самих внешний ключей

значит в этом предположении я ошибся

Создание, нет. Я вручную создаю в базе и то, только для удаления по каскаду.

Честно говоря я вобще не понял для чего нужен внешний ключ в самой базе, кроме как для удаления, либо обновления по каскаду. ?

Честно говоря я вобще не понял для чего нужен внешний ключ в самой базе, кроме как для удаления, либо обновления по каскаду. ?

Целостность связности данных.

Чтобы не было orphaned данных нигде.

Все равно не понял. По русски можете сказать?

По-моему справа от TopicID ещё пишется что-то вроде gorm:index

Все равно не понял. По русски можете сказать?

Кривых данных чтобы не было.

Когда например БД позволяет вставить строчку, где related запись несуществует. Или удалить related запись, на которую ссылаются из другой таблички.

Ааа, понятно.

Спасибо.

А возможно ли в ассоциативном массиве делать поиск по ключам? Верней, проще говоря, так: if есть ключ "такой-то"{ Экшен ) }

if _, ok := your_map[key]; ok { // ключ есть }

Второй аргумент

Это основы Go

Это основы Go

Знаю. Но в голанг бук не было именно про поиск в ассоциативном массиве. Там был пример только со списком.

if _, ok := your_map[key]; ok { // ключ есть }

Почти тоже самое что и с простым списком )

Знаю. Но в голанг бук не было именно про поиск в ассоциативном массиве. Там был пример только со списком.

https://gobyexample.com/maps

Тоже хороший ресурс

Спасибо.

А вобще это хорошая практика? Искать наличие ключа в словаре? Или лучше просто сразу вызвать значение по этому ключу и отловить ошибку?

А вобще это хорошая практика? Искать наличие ключа в словаре? Или лучше просто сразу вызвать значение по этому ключу и отловить ошибку?

ok и есть отлов ошибки по сути

ok и есть отлов ошибки по сути

Смотрите, у меня вот это все внутри запроса инициализируется.