Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Go-to web stack today?

news.ycombinator.com

Post reply on HN
Print view View original

421–430 of 453 posts

Re: Ask HN: Go-to web stack today?

#421

Post by scanr »

jypepin wrote: post #331
scanr wrote: post #79

Earlier quoted context omitted.

Google will load JavaScript but you can also use react-static to do static SSR if you’d like your first render to be fast or you’d like better SEO from crawlers that don’t read JS. Ping me if you’d like to know more.

my question is directly related with parent's answer, which, afaik, react assets on s3 + lambda won't allow SSR.

You can do the first render statically into s3 and then attach react. So basically your build does the SSR. It works if you have a smallish number of pages.

Re: Ask HN: Go-to web stack today?

#422

Post by nathan_long »

dragosmocrii wrote: post #315
dragosmocrii wrote: post #42

Earlier quoted context omitted.

Elixir/Erlang is concurrent, not parallel though.

To best of my knowledge, Erlang was not built for parallelism, but concurrency. When the language was created, multicore CPU where not yet available. The following article can explain better the point. http://jlouisramblings.blogspot.com/2011/07/erlangs-parallel...

It's true that when Erlang was first made, machines were single-core, so parallel execution was not possible on one machine. However, the "no shared memory" process model made transitioning to true parallelism much simpler. The ability to run one scheduler per core was added around 2005 I think. See https://hamidreza-s.github.io/erlang/scheduling/real-time/pr...

Also:

> Erlang achieves concurrency by interleaving the execution of processes on the Erlang virtual machine, the BEAM. On a multi-core processor the BEAM can also achieve parallelism by running one scheduler per core and executing one Erlang process per scheduler. The designer of an Erlang system can achieve further parallelism by distributing the system on several computers. > https://happi.github.io/theBeamBook/

My understanding is that the BEAM will also do "work stealing" among schedulers to take better advantage of the available CPUs.

Re: Ask HN: Go-to web stack today?

#423

Post by nathan_long »

inferiorhuman wrote: post #114
malloryerik wrote: post #87

Earlier quoted context omitted.

May I ask, what is it that you don't like about Elixir?

Deployments are a nightmare.

I'm not sure what you're comparing it to. Releases can be tricky, but if you're accustomed to `git push heroku master`, or to "blue green deployment" (https://martinfowler.com/bliki/BlueGreenDeployment.html), there's no reason you can't do that with Elixir.

Re: Ask HN: Go-to web stack today?

#425

Post by mcintyre1994 »

peteforde wrote: post #202
virtualwhys wrote: post #144

Earlier quoted context omitted.

For a long time I was in the server-side html + js for ajax/validation/effects camp, but I'm starting to gravitate to the SPA side of the fence. Why? While server-side based web sites can load quickly, there's something dissatisfying (to me) about clicking around a site, waiting for server responses, when nothing has changed . Sure, js, css, img, etc. assets are likely cached in the browser, and you're just downloadi…

I urgently encourage you and anyone else reading this to check out Turbolinks 5, ideally in tandem with Stimulus. https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s https://github.com/turbolinks/turbolinks https://stimulusjs.org/ You can get all of the benefits of server-generated pages with the speed of an SPA. 90%+ of the sites built using SPAs would be better served by Turbolinks and Stimulus.

This all looks really nice - any idea if there's anything comparable that works with Django?

Re: Ask HN: Go-to web stack today?

#426

Post by eximius »

edude03 wrote: post #415
shadowmint wrote: post #269

Earlier quoted context omitted.

This. JWT is a pain in the ass for a lot of reason people don’t appear to understand until they actually try to use it; and the majority of the proponents for it appear to have never actually used it seriously and had to deal with issues like, oh wow, redis is now the bottleneck for my ‘stateless’ authentication. Unless you need it and can articulate why, with no magic hand waving... just. use. cookies. ...and ffs, d…

I think you are confusing the technology with the implementation here. JWT the technology is essentially a way to issue a token and validate that the token is legimiate. No one said anything about stateless authentication. If you're going to use cookies, and I recommend that, you need to put something in the cookie, cookies don't magically implement authentication for you. If for some reason you're not using the fram…

And you don't understand the purpose of JWTs.

No one needed to mention anything about stateless authentication because enabling stateless authentication is the purpose of JWTs [1].

Yes, just store a signed cookie with a random token for the session and use stateful authentication. That fits most people's needs better than stateless. (Even signing is more or less optional in many common cases. If the cookie is only a sufficiently long random token for the session key, then I don't really care if a user changes it, they'll only log themselves out.)

[1] - https://jobs.zalando.com/tech/blog/the-purpose-of-jwt-statel...

Re: Ask HN: Go-to web stack today?

#427

Post by eximius »

edude03 wrote: post #414
eximius wrote: post #234

Earlier quoted context omitted.

What is the purported benefit as opposed to a shorter cookie that is the key for an expiring record in redis that contains whatever session information the JWT would have? And it scales... The JWT would just continue to grow in size and increase request response size... And you'd have TWO expiration dates (on the cookie and in the JWT).

Well, you're making a lot of assumptions already about how the stack would be implemented. I'm fairly certain most frameworks store session information in your main DB (postgres, mysql) and adding redis would be an enhancement. Secondly, why would the JWT continue to grow? It (should, in this case) only be used as a standard way to validate that this cookie is legimate and signed by the server.

> Secondly, why would the JWT continue to grow?

I replied to your other comment more completely, but thought this part was worth answering as well.

If you are using JWTs for stateless authentication/authorization, you need to include the identity (which doesn't grow) AND the list of authorizations (which might grow).

And, even if it doesn't grow, JWTs are quite large compared to the HMAC of a random token. HMAC size: 64 bytes, JWT size: several hundreds of bytes, easily a few kb, if we put more than the bare minimum.

Re: Ask HN: Go-to web stack today?

#428

Post by inferiorhuman »

nathan_long wrote: post #423
inferiorhuman wrote: post #114

Earlier quoted context omitted.

Deployments are a nightmare.

I'm not sure what you're comparing it to. Releases can be tricky, but if you're accustomed to `git push heroku master`, or to "blue green deployment" ( https://martinfowler.com/bliki/BlueGreenDeployment.html ), there's no reason you can't do that with Elixir.

Deployments are a significant amount of magic, moreso than with other languages. You're deploying a whole beam ecosystem not just a single app. If you want to do anything remotely dynamic (e.g. using environment variables as knobs a la 12-factor) you'll have to rely on distillery and voodoo.

Meanwhile distillery has been broken on FreeBSD for months with no fix in sight and no actual community understanding of how things fit together. Dockyard also has a good blog post explaining how complex Elixir deployments get:

https://dockyard.com/blog/2018/02/28/elixir-deployment-tools...

No bueno. Generating a WAR or JAR to deploy is typically trivial in comparison. Capistrano? Easy peasy AND reliable. Distillery? I'm just glad I don't have any production Elixir apps.

Re: Ask HN: Go-to web stack today?

#429

Post by agbell »

ninjakeyboard wrote: post #62

I don't believe there is a good answer to this as details are missing. What scale are you trying to get to? What level of concurrency? How much state and how often is it accessed? And what are the skill of your engineers. You could write a rails monolithic app on postgres if you're building an internal application 100 people will use. Or you could use Akka and Scala with all state in memory backed by an event journal…

If scala, http4s, gaurdrail and doobie connecting to postgres is a great stack.

Http4s is a great functional http service.

Guardrail generates stub services from an openapi spec and is well thought out enough that it doesn't get in the way.

Put React with Typescript on top of it.

Re: Ask HN: Go-to web stack today?

#430

Post by therealdrag0 »

AsyncAwait wrote: post #245
Retozi wrote: post #86

Frontend: (vanilla) React with TypeScript. - TypeScript is more important than React, static typing is such a productivity boost, even for projects of all sizes. - Start with vanilla React and create-react-app, monitor for painpoints and look for solutions for these pain points in the community, don't look at the whole ecosystem before you start building stuff. Backend: Kotlin on the JVM. Kotlin is a really nice lang…

Wanted to look into Kotlin on the backend for a while now. Do you use any framework or do you just assemble individual libraries for whatever you need? I am not sure I find Spring an attractive proposition and Ktor seems rather young, slow and not that well documented. What do you think is the best option?

I haven't used it yet, but I like the look of this guy: http://micronaut.io/
Post reply on HN