Comments 3
А какая добавочная ценность у OpenDAL для проектов не в экосистеме Apache?
Отрицая родные SDK и переизобретая реализации конкретных сервисов, OpenDAL сразу становится отстающим по функционалу от родных SDK.
Как максимально общий интерфейс взаимодействия, он же сводится к минимальному общему функционалу, а все особенности и локальные улучшения становятся или неподдерживаемыми, или протекающими абстракциями.
Нет ничего хуже для интегрированного приложения, как использовать единый общий интерфейс, с костылями под каждый сервис на уровне приложения. Вместо N зависимостей от SDK, получаем N+1, и хорошо еще если вообще можно какой-никакой доступ в нижним слоям получить и напрямую в SDK присунуть требуемое.
Проще уж проектное архитектурное решение принять, привнести в проект стандартную зависимость от конкретных официальных SDK, и реализовать диктуемые конкретными требованиями проекта интерфейсы абстракций, учитывая в первую очередь нужды продукта, а не цель общности абстракции.
Когда проект связан ровно с одним типом хранилища, OpenDAL будет не нужной прослойкой (при условии, что гарантируется отсутствие необходимости смены хранилища). А вот когда типов хранилищ сразу несколько, то он встанет в полный рост, т.к. общий функционал будет реализован ровно один раз, а функционал специфичный для хранилища одного типа и необходимый в проекте все равно нужно будет как-то имплементировать для остальных типов хранилищ.
По сути аналог ODBC/JDBC для баз данных.
Это справедливо если у вас только одно хранилище. А также если вы не планируете никогда подкючать новые, организовывать многооблачность или мигрировать на другие хранилища.
Для проектов с очень специфичными требованиями и функциональностью, использование официальных SDK может быть оправдано. С другой стороны если проекту требуются специфические функции конкретного хранилища, то OpenDAL можно дополнить, реализовав необходимые расширения, так как есть поддержка обращения я к низкоуровневым API через методы raw, дает возможность использовать уникальные функции конкретного хранилища.
Хотя если брать тот же самый S3 то из всего списка операций поддерживаются stat, read, write, create_dir, delete, copy, list, scan, presign. И не реализованы только rename и blocking, что в принципе не выглядит какой-то проблемой.
Open Data Access Layer — замена для AWS S3 SDK?