Ask HN: If you were to build a new webapp today, how would you pick your techs?

[babebridou]

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.

Assuming the client side is done already. I'm now pondering what technology to use for the backend.

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.

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?

Bonus: how often do you ask yourself this very question?

[boothead]

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.

Benefits that I can see:

* Purity. You can test the hell out of this with no side effects.

* Transaction log built in.

* The ability to look back in time, by only applying the events up until the point you're interested in and disregarding the rest.

* Very flexible and scalable.

* You can retrospectively answer questions that you might not have known how to ask, by creating new operations over your states.

* Plays well with monitoring, and analysis. E.g. just stream all of your events into logstash and elastic search.

[babebridou]

So basically, passion, right? Or is it what you already know and do all the time?

It's an interesting take nonetheless, I've been toying with the concept of data/documents as the integration of event streams (commits, status updates etc) for a few years but never really thought to use the concept "from the ground up". The idea to me never really had any technical justification, mostly end user ones. Collaborative editing (Google Wave), action replays and time machine visualization (Starcraft, Gource), status update and event analytics dashboards (google analytics or the twitter firehose)...

It's a bit outside of the scope of my webapp for the time being but I'm glad there are people who think there is value in that approach!

[boothead]

Well it's basically Event Sourcing [1]. It's probably also worth mentioning CQRS as well. All this stuff really appeals to my functional programming side :-)

I haven't quite figured out to what extent OT is the same as event sourcing. I guess OT is event sourcing with the additional concept of translating events over the top of other events (i.e rebase).

[1] http://martinfowler.com/eaaDev/EventSourcing.html

[babebridou]

I'm not familiar with either CQRS and OT. Google fails me completely on the latter, but does CQRS mean "Command Query Responsibility Segregation"?

[boothead]

CQRS: Yes that's it.

OT is operational transform; the set of algorithms behind google wave/docs. A modern take is http://sharejs.org/

[runT1ME]

FRP?

[memracom]

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.

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.

[geektips]

I Will be using a Lemp (Linux engine-x Mangodb Php) Stack instead of Lamp Stack , I will be using memcache for cacheing

[babebridou]

Php is an old lover to me, I haven't even touched it in the last decade. Revisiting this tech is very tempting, especially when I look at the first line of the changelog for all the things I missed:

> Switch to using Zend Engine 2, which includes numerous engine level improvements.

Does anyone have an executive summary of how Php evolved since the 4.3 days? Where there any fundamental changes anyone should be aware of?

[pearjuice]

>how PHP evolved

http://php.net/manual/en/language.oop5.php

http://laravel.com/