На чем написать простой rest API?

Раз ты уже знаешь JS, бери ноду, не? Зачем усложнять себе жизнь, тем более логики там никакой не планируется почти.

Да тоже подумываю. Express даже вроде как понимаю, но вот эти вот БД, orm… Очень непривычный синтаксис

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

бэкенд нужен

Так, закажите. Я так понимаю, приложение будет связано либо с коммерцией, либо это «по работе».

Подскажите, какими инструментами проще всего реализовать простенький бэкенд?

Проще всего бэкенд не реализовывать https://www.google.com/search?q=no+code+backend

Заказал бы, но бюрократия, увы

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

За ссылку спасибо, что-то над no code даже не думал

!lol kek

простенький бэкэнд реализуется простенько

добавление нескольких полей на фронте али бизнес0логика посередине?

Golang

Golang yourself

На всем.

Процесс примерно такой:

1. Выгружается таблица из 1с, вставляется в xlsx

2. Этот xlsx преобразуется в json и вставляется в базу данных, добавляя ещё пару полей

3. По Get на фронт отдаются все поля

4. По Post добавляются новый объекты, либо меняется одно из кастомных полей, либо очищается база

Вся остальная работа с сортировками и прочим реализуется на фронте

Такая глупая реализация через файл только потому, что доступа к конфигуратору нет, а апишки на эти данные отсутствуют

Если нагрузка http будет небольшая, можно взять Flask/Bottle - всё очень и очень просто. Можно позже прикрутить логику и обработку на питоне-пандасе, например. Ну и эксели легко читать. Для местной автоматизации самое то. А вот если нагрузка http будет большая, единственный вариант - C (EPOLL и пр.)

Зачем себя ограничивать? Используй сразу Cobol, пусть коллеги сдадут тебя в дурку.

Также все усложняется тем, что в работе понадобятся данные, которые будут заноситься в xlsx.

Я планировал сделать так: Пользователь обновляет файл, он компилируется в JSON, далее записывается в БД с добавлением нескольких полей, ну и отдается на фронтенд через GET.

Проблема XY детектед. Скажи, что тебе нужно сделать с xlsx с точки зрения полтзовательского сценария, а мы тебе скажем, как это лучше будет сделать.

А чтобы 2 раза не вставать. А какую БД целесообразно использовать в данном случае? Sqlite должно хватить? Или лучше подзапариться и вкорячить postgres/mongodb

Дано: отчёт в 1с где есть колонка с id документов, названием номенклатуры и количеством(которое, блин, записано в названии номенклатуры через запятую, блен). Полей чуть больше, но мне необходимы только эти.

Я хочу сделать приложение фронт, Аля обычной тудушки, где по клику будет проставляться поле done(которого нет в данном документе) в true

Как-то так

О JS на беке забудь как о страшном сне. Возьми ченить проверенное и легкое на подъем, типа ASP.NET MVC итд

Сейчас Вам каждый будет пытаться «продать» инструменты, с которыми привык работать. Значит ли это, что они именно Вам подходят? Вовсе нет 😊. Вы бы лучше обозначили, а на чем Вы в состоянии написать хоть что-то крупнее helloworld. А то ведь из 4-х известных букв слово «вечность» не сложишь, как ни старайся 😊.

В основном JavaScript, typescript, ибо на фронтенде альтернативы и нет.

Пока разбирался, python маленько вспомнил

если всё равно всё в json и персонала у тебя не мильёны - бери couchdb.

Всё, почти весь бек готов. Пиши фронт который хорошо знаешь

вс> чудесатее и чудесатее

sqlite нет ибо это не для мультиподключений (можно но не нужно)

mongodb оно конечно json - но исходное nosql

остаётся postgresql - (с опцией в nosql и прочий пыщь пыщь json)

буит ли 3ье звено?

вс> таки на каком этапе(и следовательно какая точка в пространство-времени континууме ) «добавляются поля-фраги»

фронт вопросов нет - ибо.

бэк не ингресс - орм вурм вурм - и поехал

Поля-флаги добавляются по задумке перед переносом в базу данных

… mongodb оно конечно json - но исходное nosql. остаётся postgresql - (с опцией в nosql и прочий пыщь пыщь json)

Если до этого с базами не работал, то лучше начинать с mongodb - более практичная СУБД-шка для подобных приложений. Тем более, что там задействован Javascript.

О JS на беке забудь как о страшном сне. Возьми ченить проверенное и легкое на подъем, типа ASP.NET MVC итд

Чем же ASP.NET MVC легче на подъём по сравнению с JS, и чем плох JS на микробекенде для фронтендера?

Вэб головного моска((

Какая-то микро поделка засосать в скуль экзель и сразу конечно хрест во все поля. И пофиг что его главное назначение масштабируемость и кластеризация.

чья роль - добавления полей-фрагов - клиента - али на стороне базы - али на стороне «человека по середине» ака буизнес-чувства но всяко на стороне бека?

эээ

ибо mognodb для nodejs ( и в целом для js-сферы)

что pickle для python

способ долговременного (персист промеж пусков) существования данных

али какае монго преимущество ля js-жителей?

… ибо mognodb для nodejs ( и в целом для js-сферы)

Это вы откуда такое выдумали? ) MongoDB - очень удобная документоориентированная СУБД-шка, с которой можно работать на любом языке, для которого имеется драйвер. Nodejs там задействован только в CLI-утилите mongosh, ну и в некоторых других клиентах для ручной работы с базой.

Зойчем нужен мвц если рендеринг на клиенте?

тамо (грядёши) фсё jsonify is int it?

тамо (грядёши) фсё jsonify is int it?

Внутренний формат хранения документов - BSON. Но какое это имеет отношение к Javascript и NodeJS?) На PHP, например, драйвер отдает документы в программный код в форме ассоциативных массивов.

Сама СУБД-шка написана, кстати, на C++.

Судя по описанию вам нужен простой, но быстрый диспетчер который получает HTTP запрос с файлом/данными, дергает назначенную в роутинге функцию обработки запроса (с чтением/записью в бд) и возвращает ответ.

Простой и при этом быстрый - Slim 4, но это на PHP. Если не знаете PHP то ищите аналог на языке который знаете.

Основная логика приложения будет на клиенте

Ну, главную ошибку вы уже совершили, теперь на бекенд хоть lisp, хуже для проекта уже не будет. Все равно потом выкидывать и переписывать с нуля.

Адекватный вариант примерно следующий:

У 1С есть Native API который позволяет писать свои внешние компоненты к 1С и под винду и под линукс хоть на С++, хоть на Go, Rust и тд. В итоге, клиентская часть это кнопка в 1С «Отправить данные», а серверная часть это Slim 4 c БД.

Спасибо за ответ.

Увы, касаемо последнего пункта об адекватном решении - не решаемо. Я бы и сам на 1с быстро создал решение, будь у меня доступ

Возьми монгу вместо бд и суй в неё свои джейсоны.

история по пружинной(винтовой) линии

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

насколько мир типичен

там нет 1с

вс> таки «мало их» и «дАлеки от народа»

идекаклически монга же клч-знач на спидах не?

xlsx

Выбери стек с родной библиотекой работы с ним.

там нет 1с

Дано: отчёт в 1с где есть колонка с id документов, названием номенклатуры и количеством

вс> таки «мало их» и «дАлеки от народа»

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

Увы, касаемо последнего пункта об адекватном решении - не решаемо. Я бы и сам на 1с быстро создал решение, будь у меня доступ

В таком случае берите любой фреймворк для создания HTTP API на том языке который вы знаете.

Flask. Заодно осиль Питон на каком-то приемлемом уровне. Пригодится для всего.

там(у топик-стартера доступа) нет 1С

--клиповый обезян(не армян) горе в семье

почуму не fast api?

Читайте внимательно сообщение. Предложенный вариант с 1С - это на переписывание с нуля. Вы бы хоть вчитывались в сообщение которое критикуете.

Все равно потом выкидывать и переписывать с нуля. Адекватный вариант примерно следующий:…

Ну да ладно, я опять пытаюсь метать бисер.

идекаклически монга же клч-знач на спидах не?

Это слишком упрощенное представление о монге. Там имеется полноценный функционал индексирования коллекций по одному или нескольким полям и, соответственно, быстрая выборка подмножества документов из коллекции. Имеется возможность выбирать отдельные поля документов, а не документы целиком. Так что, в плане выборки документов из одной коллекции - те же возможности, что и при выборке записей из SQL-таблицы. Аналоги выполнения JOIN-запросов тоже поддерживаются, но уже совсем в другой форме.

Не программист, делал тестовый rest сервер через python+bottle.py и оно работало

Сам я frontend разработчик

node.js? Если смущает orm и фреймворки, то можешь не использовать их, и подключаться к БД без orm.

попытайтесь увидеть в своём поведении проявление клиппового восприятия

всех благ метателю_бисера перед лицами которых он по причине (хз) попытался задеть ложной идентификацией тем самым обозначив себя хуже чем до.

почуму не fast api?

Потому что я про такой не знал. :)

TypeScript + NestJS (Не путать с NextJS) + TypeORM. А дальше можно навешивать что хочется.