This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-25
Channels
- # aws (1)
- # bangalore-clj (9)
- # boot (97)
- # capetown (1)
- # cider (4)
- # clara (1)
- # cljs-dev (2)
- # cljsrn (109)
- # clojure (258)
- # clojure-finland (3)
- # clojure-greece (2)
- # clojure-italy (1)
- # clojure-russia (33)
- # clojure-spec (41)
- # clojure-uk (46)
- # clojurescript (57)
- # component (17)
- # core-async (6)
- # datomic (13)
- # devcards (10)
- # dirac (2)
- # euroclojure (1)
- # figwheel (1)
- # funcool (1)
- # hoplon (472)
- # luminus (17)
- # off-topic (1)
- # om (16)
- # onyx (40)
- # pedestal (14)
- # proton (12)
- # re-frame (27)
- # reagent (15)
- # ring-swagger (2)
- # specter (5)
- # testing (4)
- # untangled (258)
- # vim (4)
Парни, проконсультируйте по следующему вопросу.
Собираюсь делать проект в области страхования.
Для конечных пользователей будет сделано несколько десятков специфичных rails
приложений, которые будут содержать пошаговые формы с сотнями полей.
Данные со всех этих приложений будут передаваться на clojure
приложение, которое будет их обрабатывать по-всякому и, в конечном счете, отправлять дальше на сервера страховых компаний (интерпрайз, стандраты, xml).
А теперь вопрос: есть ли смысл использовать edn
или transit
вместо json
как формат передачи данных между rails
и clojure
?
С моей точки зрения - не очень большой. Данные практически всегда можно легко с помощью json
перегнать, а уже на стороне clojure
привести в нужную форму (json array -> set и тд)
@mkaschenko I think yes, json has a limited set of types that it supports and transit will allow pass more complex types such as dates and uuids as example
Лучше бы спросил "есть ли смысл писать кучу рельсовых приложений вместо кложаскрипта?" )
А мне кажется лучше обычный json/rest. Не нужно придумывать себе велосипед, который потом в будущем, на коньках (например, с node.js) кто будет пытаться садиться (интегрироваться). Если по websoсket какой, то да, а вот обычный http - rest и json однозначно.
Плюс рест - это скорее всего какая автоматическая документация (swagger) и возможность просто это дело тестировать.
в случае рельсы + кложа - надо действительно взвешивать и смотреть на то, что за данные надо будет гонять. но это гемор, который получаешь за разношерстность стека. самое интересное, это то, что такое бывает в легаси системах, в которые приносят кложу, а тут - якобы свежий проект. И мне прям очень интересно, почему рельсы?
@potapenko а свагер разве с транзитом не умеет работать?
ну рельсы, это ж сразу и js в браузере, получается 3 языка вместо 1, там как раз транзит был бы ништяком, с нуля если писать, а не переводить на транзит что-то готовое
ну да, будут валидации форм в жс, такие же нужно будет тащить в руби и возможно в кложу
вообще, надо представлять, сколько % системы (и команды) кложа. по формулировке мне показалось, что основная - кложа, а рельсы - мелочи. Может это и не так, и тогда возможно стоит по правилам рельс играть
> Лучше бы спросил "есть ли смысл писать кучу рельсовых приложений вместо кложаскрипта?" ) Пока на 100% не знаю всех требований заказчика, но, вроде, это будут приложения, написанные разными командами с разными требованиями. Я же буду иметь дело только с clojure. > И мне прям очень интересно, почему рельсы? Я бы сам, конечно, один язык везде бы использовал. А причины такие, что не все умеют clojurescript и, скорее, эти рельсовые “веб-морды" будут заутсорсены. Да и рельсовиков много сейчас как и джаваскриптеров, да и подешевле будут. > что основная - кложа, а рельсы - мелочи. Да, так и задумывается.
Хотя с другой стороны денег на проект должны выделить много да и времени тоже, может стоит научить пару другую рельсовиков кложуре? Но я пока даже и не представляю чем это может обернуться… Было бы больше кложуристов, было бы попроще 😞
да... будут вероятно на аутсорсе рубисты материть Вас за edn. У нас вот похожий проект, формочки для страховщиков с кучей полей, но backend на clojure, frontend на clojurescript, потому выбор json vs edn не стоял.
@rkosenko а ваша система общается с какой-нибудь другой системой, например, через которую осуществляется покупака страховок?
у нас нет покупок страховок, у нас формочки для медицинских учреждений, которые хотят с нами работать. Есть некоторый legacy на рельсах из которого данные импортируются и есть интеграция с некоторыми API третьих компаний, там везде json. А внутри своей системы edn.
рубисты кста может легко передут на кложуру. Очень часто доклады по кложуре видел на всяких руби евентах, близка по духу походу)
кста - один из авторов RSpec счас в когнитеке работает, тесты за Ричи пишет наверно :))
а потом сразу на ocaml 🙂
а про edn/json - дак а чо не оба? Сделать миддлваре которое если Accept application/json
то конветнуть уж в JSON, в других случаях чистый EDN
или я чота не понимаю? Сори, я про EDN тока краем уха слышал