This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aatree (4)
- # admin-announcements (1)
- # beginners (62)
- # boot (279)
- # business (14)
- # cider (1)
- # cljsrn (3)
- # clojure (88)
- # clojure-czech (3)
- # clojure-madison (2)
- # clojure-poland (117)
- # clojure-russia (74)
- # clojurescript (168)
- # core-async (8)
- # css (6)
- # datavis (39)
- # datomic (67)
- # devcards (2)
- # dirac (1)
- # editors (9)
- # emacs (13)
- # events (2)
- # hoplon (2)
- # jobs (9)
- # ldnclj (38)
- # lein-figwheel (9)
- # leiningen (7)
- # luminus (4)
- # off-topic (77)
- # om (114)
- # omnext (1)
- # onyx (221)
- # parinfer (10)
- # portland-or (5)
- # proton (3)
- # re-frame (24)
- # reagent (14)
- # ring-swagger (13)
after an especially grueling couple of sprints on this project I'm afraid I'm losing my faith in Clojure!
but I'm afraid Clojure might suffer from the same old dynamic language problem where it's too easy to make a mess
after 9 months of coding full-time in clojure in a project which is almost 3 years old now I can say that I have even more faith in Clojure! There’s very little mess and I need to try really hard to break things. I am still able to quickly deliver new functionalities. My productivity is roughly the same when compared to my work as a Scala developer.
and how many of them we would need to say that a system has a microservices architecture
we've got 10 app projects, 12 lib projects, and one project to tie them all together, and one top-level project.clj for lein modules
The seconds rule of Microservices Club is If You Absolutely Have To - First Write a Monolith Using Hexagonal Architecture.
well, it's simple enough to run in a single process in development, and on a single machine in production!
@jcromartie: it is a hard decision, I'm new to Clojure however I develop lots of microservices using nodejs. The company I work for has lots of products, I believe that at the moment we may have around 50 microservices. The product I'm working on has 12 microservices and as you mentioned it is pretty complex to handle them. At production we have a very structured deployment system based on continuous integration/deployment, we also run our products on fair large servers, so no problems on it however in development the things sometimes get hard. We reproduce our production environment in our development environment so we run a CoreOS VM and deploy each microservice as an individual docker container, it is ok to do it but you need a lot of memory resource
some people suggest microservice-first and others to postpone it till is really needed
at the company I work for we share microservices between projects, at least the ones that don't have a business logic attached to them like, user management, profile management, e-mail/sms/ios/android notifications, etc
the approach you are taking of having one big project that group all microservices is a good one, to simplify things you can try to create a small CLI tool to boot all microservices making it easy to add / remove services
the user wants to create a record, so it goes to service A, which in turn needs to store the record, so that calls service B, and after storing the record in datastore X, it puts a message on a queue service C, in order that the record can be indexed by service D into datastore Y, and finally the user can retrieve the record by hitting service E which retrieves the data from datastore Y
so, tracing the flow of a single record through that is obviously going to be difficult
I always try to make the microservices as dump as possible, they usually manage something using DDD concept
I'm currently reading Evans' book with Vaughan next in line; mostly read internet articles thus far
I highly recommend this talk too: http://www.infoq.com/presentations/ddd-microservices
@jaen what about your experience, are you building microservices? If you do, what approach you are taking?
Hah, I can't speak much in the way of practical experience; all I know is mostly theoretical.
Didn't have any chance to build something complex enough for long enough that microservies would (IMO) start to make sense.
I guess that I do it a lot because of JS. I've managed a system with more than 100k lines of JS and it is not a good experience. Microservices help you keep things loosely coupled
nodejs has memory alloc limit, so you have to break it down in order to create a medium sized project