Задать вопрос
Ответы пользователя по тегу Go
  • Почему ошибка в SendMessageParams?

    А почему бы вам не установить курсор на "SendMessageParams" и не нажать правой кнопкой мыши на этом слове, да и не перейти к объявлению типа, чтобы просто посмотреть, а какие же там поля требуются в этой структуре?
    И, странное дело, нет такого поля ReplyToMessageID у типа SendMessageParams, о чём вам прямо и говорит компилятор.

    Документация и исходный код - вот источник правды, а не устаревшие туториалы школьников на ютубчике.

    // SendMessageParams - Represents parameters of sendMessage method.
    type SendMessageParams struct {
    	// BusinessConnectionID - Optional. Unique identifier of the business connection on behalf of which the
    	// message will be sent
    	BusinessConnectionID string `json:"business_connection_id,omitempty"`
    
    	// ChatID - Unique identifier for the target chat or username of the target channel (in the format
    	// @channel_username)
    	ChatID ChatID `json:"chat_id"`
    
    	// MessageThreadID - Optional. Unique identifier for the target message thread (topic) of the forum; for
    	// forum supergroups only
    	MessageThreadID int `json:"message_thread_id,omitempty"`
    
    	// Text - Text of the message to be sent, 1-4096 characters after entities parsing
    	Text string `json:"text"`
    
    	// ParseMode - Optional. Mode for parsing entities in the message text. See formatting options
    	// (https://core.telegram.org/bots/api#formatting-options) for more details.
    	ParseMode string `json:"parse_mode,omitempty"`
    
    	// Entities - Optional. A JSON-serialized list of special entities that appear in message text, which can be
    	// specified instead of parse_mode
    	Entities []MessageEntity `json:"entities,omitempty"`
    
    	// LinkPreviewOptions - Optional. Link preview generation options for the message
    	LinkPreviewOptions *LinkPreviewOptions `json:"link_preview_options,omitempty"`
    
    	// DisableNotification - Optional. Sends the message silently
    	// (https://telegram.org/blog/channels-2-0#silent-messages). Users will receive a notification with no sound.
    	DisableNotification bool `json:"disable_notification,omitempty"`
    
    	// ProtectContent - Optional. Protects the contents of the sent message from forwarding and saving
    	ProtectContent bool `json:"protect_content,omitempty"`
    
    	// MessageEffectID - Optional. Unique identifier of the message effect to be added to the message; for
    	// private chats only
    	MessageEffectID string `json:"message_effect_id,omitempty"`
    
    	// ReplyParameters - Optional. Description of the message to reply to
    	ReplyParameters *ReplyParameters `json:"reply_parameters,omitempty"`
    
    	// ReplyMarkup - Optional. Additional interface options. A JSON-serialized object for an inline keyboard
    	// (https://core.telegram.org/bots/features#inline-keyboards), custom reply keyboard
    	// (https://core.telegram.org/bots/features#keyboards), instructions to remove a reply keyboard or to force a
    	// reply from the user
    	ReplyMarkup ReplyMarkup `json:"reply_markup,omitempty"`
    }


    А если точно так же перейти к определению типа поля ReplyParameters, то можно увидеть как раз то самое искомое вами поле MessageID

    // ReplyParameters - Describes reply parameters for the message that is being sent.
    type ReplyParameters struct {
    	// MessageID - Identifier of the message that will be replied to in the current chat, or in the chat chat_id
    	// if it is specified
    	MessageID int `json:"message_id"`
    
    	// ChatID - Optional. If the message to be replied to is from a different chat, unique identifier for the
    	// chat or username of the channel (in the format @channel_username). Not supported for messages sent on behalf
    	// of a business account.
    	ChatID ChatID `json:"chat_id,omitempty"`
    
    	// AllowSendingWithoutReply - Optional. Pass True if the message should be sent even if the specified
    	// message to be replied to is not found. Always False for replies in another chat or forum topic. Always True
    	// for messages sent on behalf of a business account.
    	AllowSendingWithoutReply bool `json:"allow_sending_without_reply,omitempty"`
    
    	// Quote - Optional. Quoted part of the message to be replied to; 0-1024 characters after entities parsing.
    	// The quote must be an exact substring of the message to be replied to, including bold, italic, underline,
    	// strikethrough, spoiler, and custom_emoji entities. The message will fail to send if the quote isn't found in
    	// the original message.
    	Quote string `json:"quote,omitempty"`
    
    	// QuoteParseMode - Optional. Mode for parsing entities in the quote. See formatting options
    	// (https://core.telegram.org/bots/api#formatting-options) for more details.
    	QuoteParseMode string `json:"quote_parse_mode,omitempty"`
    
    	// QuoteEntities - Optional. A JSON-serialized list of special entities that appear in the quote. It can be
    	// specified instead of quote_parse_mode.
    	QuoteEntities []MessageEntity `json:"quote_entities,omitempty"`
    
    	// QuotePosition - Optional. Position of the quote in the original message in UTF-16 code units
    	QuotePosition int `json:"quote_position,omitempty"`
    }


    Итого, в вашем случае будет как-то так:

    id, ticket, reply_message := db.GetTicketAndMessage(message.ReplyToMessage.MessageID, user.ID)
    	if ticket == nil {
    		_, _ = bot.SendMessage(&telego.SendMessageParams{
    			ChatID:           telego.ChatID{ID: message.Chat.ID},
    			Text:             "This ticket or message does not exist.",
    			ReplyParameters:  &telego.ReplyParameters{
                                    MessageID: message.MessageID
                            },
    			ParseMode:        "HTML",
    		})
    		return
    	}
    Ответ написан
    4 комментария
  • Как организовать отправку сообщений в множество микросервисных нод?

    Берете какой-нибудь брокер сообщений.
    Например, Rabbitmq.
    Там создаёте exchange с типом fanout. Туда будете слать сообщения из сервиса-отправителя.
    Каждый сервис-получатель будет подключаться к этому exchange и для каждого будет создаваться своя очередь, куда будут попадать все сообщения. И каждый сервис спокойно сам вычитает свою очередь. И даже если он упадёт, то дочитает их после того, как подымется.
    https://youtu.be/P_EtQ-s-hiU?si=tavSDSzTnGpqQrAY
    Ответ написан
    2 комментария
  • Как получить группы, в которых состоит пользователь?

    Вот ответ для вашего конкретного случая в Windows.

    package main
    
    import (
    	"fmt"
    	"os/exec"
    	"strings"
    )
    
    func getGroups() ([]string, error) {
    	var groups []string
    
    	patch := "/groups"
    	cmd := exec.Command("whoami", patch)
    	output, err := cmd.Output()
    	if err != nil {
    		return nil, err
    	}
    
    	lines := strings.Split(string(output), "\n")
    	for _, line := range lines {
    		if strings.HasPrefix(line, "S-1-5-21") {
    			groups = append(groups, line)
    		}
    	}
    
    	return groups, nil
    }
    
    func main() {
    	groups, err := getGroups()
    	if err != nil {
    		fmt.Printf("Ошибка получения групп пользователя: %v\n", err)
    		return
    	}
    
    	fmt.Println("Группы пользователя:", groups)
    }
    Ответ написан
    21 комментарий
  • Как прописать путь к конфигу?

    Если есть какая-то определённая директория, в которой лежат конфиги (допустим /config/config.json), то самым простым и прямолинейным способом, без всяких зависимостей и ухищрений, будет создать в самой директории файл /config/config.go, который будет предоставлять простенький пакет config, и задачей которого будет тупо загружать конфиг из файла в своей директории в структурку с конфигом. И в остальных пакетах будете просто импортировать этот пакет и получать готовые данные.

    Или вот так

    package main
    
    import (
    	"encoding/json"
    	"fmt"
    	"log"
    	"os"
    	"path/filepath"
    )
    
    type Config struct {
    	Env string `json:"env"`
    }
    
    func main() {
    	// Получаем текущую директорию
    	currentDir, err := os.Getwd()
    	if err != nil {
    		panic(err)
    	}
    
    	// Получаем путь к файлу относительно текущей директории
    	filePath := filepath.Join(currentDir, "config/config.json")
    
    	file, err := os.ReadFile(filePath)
    	if err != nil {
    		log.Fatal(err)
    	}
    	var config Config
    	json.Unmarshal(file, &config)
    
    	fmt.Println(fmt.Sprintf("ENV: %s", config.Env))
    }
    Ответ написан
    Комментировать
  • Slog. Нужно ли предавать логгер через параметры или объявить его на уровне модуля и обращаться к нему?

    Насчёт параллельных обращений. slog очень гибкий и продуманный логгер. Не стоит беспокоиться насчёт параллельных обращений, там всё отлично с этим.

    Насчёт того, использовать ли логгер глобально...
    На этот вопрос трудно ответить, не зная, какой у вас проект.

    Лично я предпочитаю пользоваться принципом "Бритвы Оккама" и не вводить новых сущностей без необходимости.

    Сначала надо задаться вопросом: а нужны ли мне разные варианты логгера в одном и том же окружении? Что я такого буду логгировать в разные места и разным образом, чтобы мне надо было иметь кучу разных логгеров и передавать их как зависимость в каждую функцию или в каждый ваш синглтончик. И если не нужны, то зачем городить огород?

    Тем более, что даже для тестов вы можете написать для slog какой-то особый хэндлер, который будет работать так, как надо в тестах.

    Поэтому я последнее время всегда использую глобальный slog. В начале программы загружаю конфиг, переменные окружения, определяю, какой мне в этом окружении будет нужен логгер, и конфигурирую дефолтный slog с нужным мне хендлером.

    Вот вам крайне увлекательное и крайне полезное видео, как из глобального slog можно сделать просто монстра логгирования на все случаи жизни.
    https://www.youtube.com/watch?v=p9XiOOU52Qw

    Вот пример того, как я настраивал логгер в одном из маленьких проектов. Он определяет по конфигу, с какого уровня надо логгировать, в каком формате, и в какой поток (stdout, stderr, файл)

    package app
    
    import (
    	"fmt"
    	"io"
    	"log/slog"
    	"os"
    )
    
    // SetupLogger создаёт логгер на основании конфига
    // Конфигурируем дефолтный slog и возвращаем функцию закрытия файла логов, 
    // если был выбран файл как место логгирования.
    func SetupLogger(cfg config.Config) func() error {
    	closer := func() error { return nil }
    
    	level := cfg.LogLevel
    
    	var w io.Writer
    
    	switch cfg.LogOutput {
    	case config.LogOutputStderr:
    		w = os.Stderr
    	case config.LogOutputStdout:
    		w = os.Stdout
    	case config.LogOutputFile:
    		w, closer = getFileWriter(cfg)
    	}
    
    	var handler slog.Handler
    	switch cfg.LogFormat {
    	case config.LogFormatText:
    		handler = slog.Handler(slog.NewTextHandler(w, &slog.HandlerOptions{Level: level}))
    	case config.LogFormatJSON:
    		handler = slog.Handler(slog.NewJSONHandler(w, &slog.HandlerOptions{Level: level}))
    	}
    
    	slog.SetDefault(slog.New(handler))
    
    	return closer
    }
    
    // getFileWriter возвращает файл, куда писать логи и функцию закрытия этого файла
    func getFileWriter(cfg config.Config) (*os.File, func() error) {
    	logDir := fmt.Sprintf("%s/%s", cfg.VarDir, cfg.LogDir)
    	err := os.MkdirAll(logDir, 0755)
    	if err != nil {
    		panic(fmt.Sprintf("error creating directory: %s;  %v", logDir, err))
    	}
    
    	filename := fmt.Sprintf("%s/%s.log", logDir, cfg.AppEnv)
    	f, err := os.OpenFile(filename, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666)
    	if err != nil {
    		panic(fmt.Sprintf("error opening file: %s %v", filename, err))
    	}
    	return f, f.Close
    }


    package main
    
    import "app"
    
    func main() {
    
            // .....
    
    	closeLogFile := app.SetupLogger(cfg)
    	defer closeLogFile()
    
            // ...
    }
    Ответ написан
    5 комментариев
  • Как сделать импорт переменной из 1 пакета, когда она в другой?

    Go не любит лишних усложнений. У языка такая философия.
    Вы ведь всё равно все ошибки держите в одном пакете, т.е. они всё равно в одной куче с точки зрения программы. Почему бы тогда вместо папок не использовать просто файлы? Т.о. плоская структура с именами файлов вместо папок будет соответствовать вашим нуждам.

    err.go
    account.go
    auth.go
    json.go
    registation.go
    Ответ написан
    Комментировать
  • Где писать логику работы с БД?

    Вы, фактически, пытаетесь использовать паттерн проектирования Active Record. Почитайте про достоинства и недостатки этого паттерна, посмотрите как его лучше готовить, и можете смело применять, если это подходит вашей программе и вам это удобно.

    Однако, лично я считаю этот паттерн вредным, потому что он намешивает всё в одну кучу. Это моё субъективное мнение, и я вам его не навязываю. Я бы отделил мух от котлет, и оставил бы структуру чистой, т.е. только данные и какие-то методы, которые работают конкретно с этими данными из структуры, а взаимодействие с базой данных организовал бы через паттерн проектирования Repository. Т.е. мы делаем уже отдельную структуру ProductRepository, которая содержит в себе методы, принимающие и отдающие структуру Product, и уже в этих методах реализуем вызов базы данных.

    Я набросаю вам простенький интерфейс для использования этого паттерна, а конкретную структуру, реализующую этот интерфейс вы уже напишете сами. Интерфейсы использовать в таких случаях считаю вообще обязательным условием. Например, так нам будет гораздо проще тестировать код, всё становится гораздо гибче. Ведь структурку Product вы сможете без проблем использовать не только при работе с базой, но и при передаче данных в другие системы, не волнуясь о лишних методах, висящих на ней. Так же вы сможете легко менять реализации репозитория, не меняя бизнес-логику проекта. (Это позволит, например, легко заменить базу данных)

    package models
    
    type Product struct {
    	ID    int    `json:"id"`
    	Title string `json:"title"` //Название
    	Price int    `json:"price"` //Цена
    }
    
    type ProductGetter interface {
        GetAll() ([]Product, error)
        GetByID(id int) (Product, error)
    }
    
    type ProductCreator interface {
        Create(product Product) (Product, error)   
    }
    
    type ProductUpdater interface {
        Update(product Product) (Product, error)
    }
    
    type ProductDeleter interface {
        Delete(id int) error
    }
    
    type ProductRepository interface {
        ProductGetter
        ProductCreator
        ProductUpdater
    }
    Ответ написан
    4 комментария
  • Как маппить результат запроса бд в структуры со вложенностями Golang?

    - Я считаю, что свой кастомный маппер - это отличное решение. Чтобы быть уверенней, обязательно напишите тесты. Как unit, так и интеграционные, например, с помощью testcontainers.

    - Можете вместо pgx посмотреть в сторону sqlc. У него совершенно другой подход. Вы пишете запрос со всеми джойнами, а он вам автоматически генерирует код со всеми структурами и функциями. Правда, там по джойнам практически отсутствует документация, но уж погуглите.

    - Ну, и если совсем сложно... то... может одним глазком глянуть в сторону ORM? Я никому не расскажу...
    Ответ написан
    5 комментариев
  • Как устранить утечку памяти при множественных соединениях в net/http Golang?

    Скорей всего, проблема в том, что вы возвращаете ошибку, не закрывая http соединение.
    Для этого была специально введена одна из самых привлекательных конструкций языка - defer.

    var client = &http.Client{
        Timeout: time.Millisecond * 100,
    }
    
    func scan(ip string) (error, string, string, string) {
        resp, err := client.Get("http://" + ip)
        // Здесь сразу желательно обработать ошибку ...
        
        // Закрываем соединение в конце выполнения
        // функции в любом случае,
        // даже если где-то возникнет ошибка
        defer resp.Body.Close()
    
        // Закрытие неиспользуемых соединений
        // Нужно ли это теперь?
        // client.CloseIdleConnections()
    
        // Проблема могла быть тут
        // if err != nil {
        //     return err, "", "", ""
        // }
    
        headers := buildHeaders(resp.Header)
        body, _ := io.ReadAll(resp.Body)
    
        // и это нам уже особо не нужно
        // resp.Body.Close()
    
        return err, headers, string(body), resp.Status
    }
    Ответ написан
    3 комментария
  • Почему я получаю ошибку invalid operation: err (variable of type Error) is not an interface при проверке типа переменной?

    Я полностью присоединюсь к ответу выше, просто хочу дополнить.

    Замечу, что вы проверяете не то, что нужно, шиворот-навыворот. Проверять при приведении типов лучше конкретные типы. Т.е. мы получаем из функции ошибку в виде интерфейса error, а уже в проверке проверяем её на наш кастомный тип MyError. Поэтому желательно (не обязательно) не проверять переменную ошибки в той же функции, где вы её создали, а возвращать откуда-то и уже тогда проверять на ошибку.

    К тому же, если у вас вопросы по этой теме, я настоятельно хочу порекомендовать правильно использовать кастомные типы ошибок, и даже если указатель на ваш кастомный тип ошиьбки равен nil, то ни в коем случае не возвращайте сам этот указатель, а возвращайте буквально nil. Так вы избавитесь от тысяч выстрелов себе в ногу.

    package main
    
    import (
    	"fmt"
    )
    
    type MyError struct {
    	Message string
    }
    
    func (e MyError) Error() string {
    	return e.Message
    }
    
    func main() {
    	// Возвращаем из функции нашу кастомную ошибку, но в виде интерфейса error
    	err := foo()
    
    	if err == nil {
    		fmt.Println("Нет ошибки")
    	// И теперь тут приводим error к нашему типу MyError и проверяем
    	} else if myErr, ok := err.(MyError); ok {
    		fmt.Printf("Ура! Нужный нам тип ошибки: %v\n", myErr.Message)
    	} else {
    		fmt.Println("Какой-то другой тип ошибки:", err)
    	}
    
    	// Проверка одной из "подстав" Go
    
    	err = bad()
    	if err != nil {
    		fmt.Println("Упс... Как так... Не nil...")
    	} else {
    		fmt.Println("Должно вывестись это, но не выводится...")
    	}
    
    	err = good()
    	if err != nil {
    		fmt.Println("Это не должно выводиться, всё верно.")
    	} else {
    		fmt.Println("Ошибки нет, всё верно.")
    	}
    }
    
    func foo() error {
    	err := MyError{"Ой! Ошибка MyError!"}
    	// err := fmt.Errorf("Ой! Обычная ошибка!")
    	// var err error = nil
    	return err
    }
    
    func bad() error {
    	var p *MyError = nil // Вроде же nil, но не работает....
    	// p = &MyError{"Ой!"} // Пробуем создать ошибку, и всё работает.
    
    	if p == nil {
    		fmt.Println("Ну nil же-ж... Должно же-ж работать", p)
    	}
    
    	return p
    }
    
    func good() error {
    	// return MyError{"Ой!"}
    
            // Буквально пишем "nil", никаких указателей, которые равны nil, это прямой выстрел в ногу
    	return nil
    }


    https://go.dev/play/p/2YcWcH9oqel
    Ответ написан
    Комментировать
  • Насколько актуальна книга Марка Саммерфильда?

    Не читал, но не осуждаю)

    Я считаю, что если многие советуют, то можно брать, если хотите.

    Go - язык немного особенный в плане устаревания информации. Если, например, купить книгу по JavaScript того года, то это будет супер-вредно, потому что в те времена это был чуть ли не другой язык.

    А создатели Go с самого начала заявили, что обратная совместимость будет одной из основных характеристик языка. Роб Пайк вообще говорил, что Go 2 никогда не будет.

    Так же, из-за простоты языка существует великолепный феномен, когда разные программисты, решающие одну и ту же задачу, напишут практически одинаковый код.

    Всё вышеперечисленное позволяет мне, даже не читавшему эту книгу, заявить, что вреда она вам точно не причинит, и предположить, что принесёт пользу.

    P. S. Совет лично от меня: читайте книги по программированию на английском. Очень часто переводчики просто бредят как ChatGPT, и некоторые книги просто невозможно читать.
    Ответ написан
    2 комментария
  • Как в goшном SOA сервисе работать с базой данных?

    Не знаю, какая у вас архитектура, но когда какая-то библиотека обрастает огромным количеством методов, то Go - это один из редких языков программирования, который, благодаря своей утиной типизации позволяет использовать шаблон проектирования "consumer interfaces", т.е. объявлять интерфейсы в месте, где они используются и включать в эти интерфейсы только те методы из огромной структуры базы данных, которые именно тут, на месте, и используются. Таким образом ваши интерфейсы будут минимальными, понятными, и искать их не придётся. Ну, и в добавок, старый добрый Dependency Injection решит массу наших проблем

    База данных:
    package db
    
    import "fmt"
    
    // Стуктура базы данных. Здесь нам даже и не нужно объявлять никаких интерфейсов
    type Service struct {
    	// ...
    }
    
    func NewDbService() (*Service, error) {
    	return &Service{}, nil
    }
    
    func (d *Service) CreateUser(username string, email string) {
    	fmt.Println(fmt.Sprintf("user %s with email %s is created", username, email))
    }
    
    func (d *Service) CreateProduct(name string) {
    	fmt.Println(fmt.Sprintf("product  %s is created", name))
    }


    Пользователь:
    package user
    
    // Тот самый интерфейс, который нам позволяет выбрать из структуры базы данных
    // только нужные нам здесь методы
    type dbUser interface {
    	CreateUser(username string, email string)
    }
    
    type Service struct {
    	db dbUser
    	// ...
    }
    
    func NewService(db dbUser) (*Service, error) {
    	return &Service{db}, nil
    }
    
    func (c *Service) New(username string, email string) {
    	c.db.CreateUser(username, email)
    }


    Товар:
    package product
    
    // Тот самый интерфейс, который нам позволяет выбрать из структуры базы данных
    // только нужные нам здесь методы
    type dbProduct interface {
    	CreateProduct(name string)
    }
    
    type Service struct {
    	db dbProduct
    	// ...
    }
    
    func NewService(db dbProduct) (*Service, error) {
    	return &Service{db}, nil
    }
    
    func (p *Service) New(name string) {
    	p.db.CreateProduct(name)
    }


    main.go
    package main
    
    import (
    	"test2/db"
    	"test2/product"
    	"test2/user"
    )
    
    func main() {
            // Инициализируем базу данных
    	dbService, _ := db.NewDbService()
            // Структура базы данных реализует интерфейс dbProduct, инжектим её
    	productService, _ := product.NewService(dbService)
            // Структура базы данных реализует интерфейс dbUser, инжектим её
    	userService, _ := user.NewService(dbService)
    
            // Пользуемся на здоровье...
    	userService.New("user1", "uswr1@example.com")
    	productService.New("product1")
    }
    Ответ написан
    Комментировать
  • Как организовать структуру проекта с несколькими модулями Golang?

    Делаем три разных файла main.go под каждый сервис. Кладём их каждый в свою подпапку в директории, например "cmd".
    А для общих библиотек используем отдельную директорию, например "pkg", и будем импортировать отсюда функционал во все три сервиса.

    Т.е. у нас получается структура файлов:
    cmd/
          repeater/
                main.go
          controller/
                main.go
          executor/
                main.go
    pkg/
          c-library/
                clibrary.go
    go.mod


    И потом запускаем компиляцию:

    go build ./cmd/repeater
    go build ./cmd/controller
    go build ./cmd/executor


    Пример main.go
    package main
    
    import c_library "test/pkg/c-library"
    
    func main() {
    	c_library.HelloWorld()
    }


    И общая библиотека:
    package c_library
    
    import "fmt"
    
    func HelloWorld() {
    	fmt.Println("HELLO WORLD")
    }


    Весь проект у меня лежит в папочке test, и в файле go.mod надо бы указать следующее

    module test
    Ответ написан
    5 комментариев
  • Как предотвратить бесконечную загрузку страницы при отправке post запроса?

    Использовать SSE (Server Sent Events). Это на порядок проще, чем вебсокеты, но мощь практически такая же.
    Вот неплохая статья на английском.
    https://blog.stackademic.com/real-time-communicati...

    Кстати, библиотека HTMX позволяет это обрабатывать и без написания Javascript
    https://htmx.org/extensions/server-sent-events/
    Ответ написан
    Комментировать