Live data from Hacker News

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

news.ycombinator.com

1–10 of 11 posts

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

#1
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?

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

#2
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.

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

#4
post #2

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…

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!

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

#5
post #3

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

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?

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

#6
post #2

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…

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 edi…

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

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

#7
post #3

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

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 o…

>how PHP evolved

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

http://laravel.com/

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

#8
post #6

Earlier quoted context omitted.

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 edi…

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

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

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

#9
post #6

Earlier quoted context omitted.

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

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

CQRS: Yes that's it.

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

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

#10
post #2

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…

FRP?
Post reply on HN