Возьмите сторонний deep equal, который разницу выводит

спасибо, они реально не равны были прост

обычная история

Всем привет! Хотелось бы проконсультироаться по реализации архитектуры для проекта со стороны бекэнда. Планируется писать на Go, дробить на микросервисы с общением по RPC. Но немного не ясны вещи по прокидыванию некой "входной точки", откуда все запросы будут уходить по микросервисам. Кто может помочь с ответом на вопрос?) Дабы без лишнего флуда, предлагаю в лс мне написать)

входная точка называется application gateway, и на этом месте обычно или nginx, или traefic, иногда - haproxy

envoy ещё бывает

я очень люблю рисовать архитектуры без ag,но в реальности с ним и проще, и быстрее, и гибче

+

А разве можно api-гейтвеить rpc?

надо сказать, что в go можно писать модульные программы (благодаря internal), которые легко превращаются в микросервисы, когда до них дойдет дело

на начальном этапе (не)значительно ускоряет разработку - не надо пилить rpc протоколы

rpc на openapi? легко.

Аааа

Я столько писал

На grpc можно юзать энвой

сейчас модно не rpc, а grpc 😀

Чего ж он так никому не нравится :(

я вот просто не трогал его еще

Мне просто немного не ясна картина как завязать все правильно -
1. Дробить на сервисы. Допустим, у нас два сервиса: UserService(включает в себя авторизацию, регистрацию); PostService(отвечает за публикацию неких объектов, удаление и тд.) Вход к ним по https - .com/api/v1/user/login и .com/api/v1/post/create и тд. И как завязать эти урлы к сервисам? Получается, необходимо создать некий сервис Router, в котором поднимается веб-сервер с, к примеру, gorilla mux и там уже в хендлерах идет вызов по RPC каких-либо сервисов?
2. Больше не придумал 😄
Какая практика считается правильной?) либо я что-то не понял до конца

он только набирает популярность

Ну, тебе и не надо особо. Это для любителей grpc удобно