The needs are pretty generic, users post content that gets hashed into a url and stored. Other users can now follow that link and see that content on their browser/device/application.<p>Assuming the client side is done already. I'm now pondering what technology to use for the backend.<p>I'm technology agnostic and would love to kill two birds in one stone with this project: make it work and learn something new. For the "make it work" part I can do it quickly with my legacy skills since I already have significant experience with those in production systems (mostly java-based), but I'm not sure I'm going to learn much here from a technical point of view and part of me would love to add a new technical line to the resume.<p>How would you go about it? Would you try something new to you, something new to the "scene"? Any tech in particular? (passion) Or would you get it done first (reason), deferring the learning part to the challenges at scale later down the way, which may or may not happen at all?<p>Bonus: how often do you ask yourself this very question?
I would almost certainly build the back end from the ground up based on the concept of a stream of events. Current state is then expressed as left fold over a base empty state and all of the event types you're interested in.<p>Benefits that I can see:<p>* Purity. You can test the hell out of this with no side effects.<p>* Transaction log built in.<p>* The ability to look back in time, by only applying the events up until the point you're interested in and disregarding the rest.<p>* Very flexible and scalable.<p>* You can retrospectively answer questions that you might not have known how to ask, by creating new operations over your states.<p>* Plays well with monitoring, and analysis. E.g. just stream all of your events into logstash and elastic search.
Event-based technology stack. You could try using Erlang but it can be harder to find developers. Easier to use something like Mongrel2 as the webserver with Python multiprocessing backend to leverage the UNIX/Linux process model. Or to use something like Akka on the JVM along with spray.io. Or use Clojure, again on the JVM.<p>But remember, one of the benefits of using event-based design is that you can write your event processors in different languages if it makes sense. Don't block off that possibility; in other words look at how you can use messaging technologies like ZeroMQ and AMQP rather than something like JMS which locks you in.