Комментарии 10
Не надо тащить HTTPS внутрь приложений, ну пожалуйста. Каждый раз это дополнительный головняк для эксплуатации, а пользы никакой. То оно ломается при обновлении крпитографических либ в контейнере, то оно сертификаты не умеет менять без перезапуска... зачем?
Не очень понял. Имеется в виду web сервер, а называется просто сервер? Для меня сервер - это куча железа, на нём поднимается гипервизор и там виртуалки, на которых только поднимаются web сервера и web сервисы. Но у автора что-то с терминологией. Плюс вообще не понял, чем этот проект на rust лучше asp net core на c#, который я использую сейчас. Так что очень интересно, но не понятно.
Да, я имел ввиду именно веб сервер, извиняюсь)
Плюс вообще не понял, чем этот проект на rust лучше asp net core на c#, который я использую сейчас
Вообще цель проекта - ускорение разработки. Я очень стараюсь сделать написание кода минимальным. Да, своей ценой - изучение нового "языка" (условный, конечно, язык, но не суть), но он должен уменьшить количество этих самых строк кода и не требовать глубокого понимая принципов работы веб серверов, увеличивая абстракцию и скрывая от пользователя детали работы. Т.е. пользователю нужно только объявить маршруты и что веб серверу надо делать при запросе на этот маршрут.
Раст здесь (для пользователя. Понятное дело, что весь проект на нём) нужен только для тех, кому требуются более экзотические задачи или просто те (задачи), которые не даёт решить сам RDL. Сейчас я делаю на этом же проекте веб сервер, который будет выступать в роли "ракетного менеджера" для RDL и позволять публиковать/скачивать плагины. Если всё будет реализовано по плану, это позволит большинству пользователей не писать платины самостоятельно, т.к., вероятно, под их задачу уже будет всё написано ранее (и опубликовано)
Так... Тогда другой вопрос, а ускорение разработки чего вы хотите добиться? У нас есть разработка разных бэкенд приложений, которые представляют собой веб-серверы. Я вот к примеру работаю в области бизнес систем, там очень много бизнес логики, что объект а нужно обработать таким образом и бла-бла-бла. И вот обвязка веб сервера там не такая и большая, по сравнению с бизнес логикой. Того, что вы упростите написание веб части, почти ничего не поменяет в плане бизнес задачи.
Или речь про то, что вы хотите разработать некоторый аналог nginx, который маршрутизирует некоторый контент и маршрутизирует запросы между разными серверами? Для задачи того, что на сервер А приходят запросы от 3-х разных сайтов и их нужно перенаправить на нужные сервера в режиме прокси - с этим прекрасно справляется nginx, и там просто нужно чуть-чуть написать конфига. Для этого я не буду писать каждый раз новый веб-сервер на c#.
Моя задача в первую очередь была набраться опыта в создании нечто большего, чем обычный пет проект (видимо так себе получилось):)
Проект не рассчитан на бизнес и решение его проблем) конечно, для задач бизнес можно и даже нужно писать веб сервера самостоятельно. Я же создаю этот проект для менее... обеспеченной(?) навыками, знаниями или людьми стартапов или просто для обычных людей, которые не хотят тратить время на изучение, но веб сервер им почему-то нужен. В целом и проекты другие, которым нужен не слишком сложный бэкенд, могут воспользоваться этим.
NGINX безусловно хорошее решение, но это другая ниша. Я с ним и не планировал конкурировать. Писать саму серверную логику в nginx не очень то и удобно (хотя обратный прокси на нём замечательно работает), а у моего предложения как раз на неё идёт упор. Для сложный сценариев я добавил возможность интегрировать плагины, но даже с ними бизнесу (крупному.... хотя кто его знает...) вряд ли потребуется это решение
Зачем это нужно когда есть k8s?
Статья написана плохо, не структурированно, сумбурно. Не описаны нормально ни предмет разработки, ни цель, ни процесс. В итоге, вообще непонятно о чем речь и зачем она (статья) нужна.
Ускорение серверной разработки