likortera

I think the key on this comment is "90s". Modern PHP is very different. As you say, Laravel makes trivial and a joy to use things that in 90s PHP are like today's node.

Most "full stack" frameworks in the node ecosystem consider themselves "full stack" just because you can run code on the server. See the Fresh (deno) discussion here in HN from a few weeks ago.

To me a framework which doesn't come with a clear way to do translations, background jobs, query builder, ORM, migrations, asset bundling, validations, error handling, etc it is not full stack. It is just "server code compatible" at best.

Bad. Like really bad. Unless you're doing it for some small corner case where you need up to the list bit of performance, raw SQL queries and mapping them to objects or manually moving or many pulsating the result sets manually is really bad. Specially for others having to maintain your code 3 years later.

There's a reason ORMs are so popular.

Adonis is far, far, far from reaching even a small percent of what Laravel is. It has almost no community and very little or almost no third party packages. When I tried it las year I couldn't even find a formatter for the templates.

Later I've found out the author of the framework has fake accounts pretending to be a happy user of it, and that was the end of it for me.

So, not comparable at all in my opinion.

Same here, except I use Unpoly for all my side projects.

I think you're only considering the backend part of these frameworks.

Rails is really full stack. Django's frontend story is a joke.

Yeah, that's the point. I think the SDK is not that helpful when running code in the backend (SSR).

What frustrates me is that I don't get what's wrong with just using the traditional http-only secure cookie backed by a server side session. That just works, and it's one of the most safe ways to do it. Even banks do it that way. All the JWT temporary refresh token whatever sounds like somebody was just bored and wanted to have fun. Sorry, I was pretty burned out about this. So much that we ended up swapping it for something else.

I really wish directus had a simple "cookie" based auth, and not all this crazyness with a cookie + refresh token + renewals + refresh + JWTs +... I was trying to use it with Next.js, where I needed to authenticate the current user server side to fetch some data and it was by far the most overcomplicated part of my application.

We ended up switching to Django, where just an traditional http only secure cookie which we "proxied" from Next.js to the frontend and back was enough and maybe even more secure than all the mangling we had to do with the refresh tokens, etc.

I really wish this trend of fancy authentication mechanisms goes away. It doesn't take in account how easy they make for people to mess up on their implementation/usage of it when things are too complex.

Hit reload like crazy. I was desperate.

I like react, and next. I use it at work and it pays my bills. But I 100% agree with you, the complexity is mind blowing. And I'm pretty scared of all the upcoming server components, etc...

It is a very powerful tool for sure, but it is so misused in places where it is not needed.

Ha! I've met web developers that didn't know that you could do form posts without a JSON API

I like https://tallstack.dev/ a lot.

But I think https://unpoly.com/ is nice also and works with any backend.

Tailwind for CSS is great too.

Too Javaish for my taste.

It is very likely that GAE will last a lot more than the Kubernetes cowboy you hired to set up the undocumented and untested version of it in house.

> I started out with Iaas namely Google App Engine and we suffered a ton with huge bills especially from our managed db instance Are you factoring in the salaries of the people setting up Kubernetes? And the cost of those people/salaries not working on the actual product? And the cost of those people leaving the company and leaving a ton of custom infrastructure code behind that the team can't quickly get up to speed with?

> ton with huge bills especially from our managed db instance

This doesn't have much to do with App Engine, right? Last time I used it, we were using a PostgresQL instance on AWS and had no problems with that.

> Doing deployments was fine but complicated enough that only seasoned team members could do it safely

I just plain don't believe this. I bet you were doing something wrong. How is it possible that the team find too difficult to do an App Engine deployment but then they're able to setup a full kubernetes cluster with all the stuff surrounding it? It's like saying I'm using React because JavaScript is too difficult.

> Using kubernetes forces you to write configurable code and is very similar to testing: it sounds like it'll slow you down and shouldn't be invested in until the codebase is at a certain size but we've all learned from experience how is actually speeds everything up, makes larger changes faster, cheaper customer support and saves you from explaining why a certain feature has been broken for 10 without anyone's knowledge

This is far, far, far from my own experience.

Some other questions:

How did you implement canary deployment?

How much time are you investing in upgrading Kubernetes, and the underlying nodes operating systems?

How did kubernetes solve the large database bills issue? How are you doing backups and restoration of the database now?

If I were to found a company, specially not VC founded, dealing with kubernetes would be definitely far below on my list of priorities. But that's just me.

I've only used SWR. How does it compare? I

Yes, they do. You get these "for free" with any PaaS. You have to do it yourself with vps or custom in house kubernetes.

Yes, because optimising for docker image size sounds like the right thing to optimize for.

What about backups? What about the vps going down? What about upgrading the server? What about security updates?

Professional work on VPS is either a lot more work, or not that professional. If it is not being a lot more work then you're not providing the same service, security and guarantees to your customers.

This is where PaaS shine. Easy and safe. And if you factor in your own time, then cheaper too.

Yes, I agree. The "minimum complexity" is way higher this way, even for simple things.

But my fear is that when things get complex in the frontend, at some point there is a peak point at which these tools become easier and the more traditional ways more difficult. And it is not easy for me to day where that peak point is.

Something it took me some time to understand, and I feel very dumb for that, is that with these modern "SPA" tools such as Next, you can still do quite easily dumbed down non interactive websites that do traditional form posts. It works perfectly fine.

The other way around, using the dumber tools and trying to do highly interactive apps, is a lot harder.

That might be part of the reasoning most things are nowadays built with these spa like frameworks.

Not that I agree. Just trying to understand.

I don't find this anything better than just using Next.js or any similar framework. Custom solutions for bundling end up being custom reinvented square wheels in my experience.

It's forking all the way down. I run my code on a fork of Linux, just in case.

Problems that most of Kubernetes users don't have, and could have been solved with some unfashionable 2/3 servers and a load balancer.

No need to go back 30 years.

If doing professional work, use heroku, App Engine or any similar PaaS solution.

If doing hobby/side projects, Dokku is a great self hosted heroku alternative. Easy to setup and use.

Kubernetes is a very low level tool. If you want to run it yourself you need s full team of infra experts to not fuck it up. So I think it could be a great tool for large companies with many teams and a lot of money.

As usual the problem is not taking into account context, and single developers or startups thinking they need to do what google does so they go full Go microservices spa Kubernetes crazy. Add some of the Agile bullshit on top of this and welcome to your average startup nowadays.

And almost impossible to understand or maintain to anyone coming after you to the project.

The benefits of frameworks is that there's shared knowledge on how to use it, lots of documentation and they are more battle proven.

There's a reason people are not writing assembler. Reinventing the wheel every single time has its trade offs too.

Recommending people that don't know how to/if to do it (that's why they are asking) to write their own auth, trivializing the problem and in the same comment recommending using JWT terrifies me quite a lot.

And I'm not sure about the cheaper.

You push your code and only god knows where it runs but cheaper and more webscale.

haha, lol... So I'm a top 1% dev then :). I have all the megabytes in my frontend.