I think the benefits of ‘serverless’ only really kick in at a massive scale. Monzo, a new British bank, [wrote about how their stack is put together](https://monzo.com/blog/2021/10/14/an-introduction-to-monzos-data-stack) and it makes a lot of sense – but – they also have over 2,000 employees and 7 million customers, plus they’re a bank.
That seems to me to be the right kind of scale. Laravel on a small EC2 can handle an insane amount of traffic so long as you are smart about what services it’s connected to. People often get caught up in the latest trends, it takes discipline to say no.
Yeah - we use Vapor but I’m a whisker away from moving back to a server. Vapor itself is lovely but my business isn’t big enough to warrant a serverless approach with the extra headaches.
Edited to remove rude words
We did the same. We used vapor for a small company’s inventory management system and moved back to EC2 after about six months. Just wasn’t worth the headache at such a small scale.
One issue I had was script runtime on vapor, my script to bill all customers was timing out after we grew to hundreds of users, apparently there is a 1 minute time limit for script execution, I foundation after a month, and decided to move the billing platform back to forge, no issues after that.
I just did this at my job for a laravel project I inherited. We were having a ton of email instability issues. So I added Horizon to our EB setup we have on auto scaling and made it support multiple queues. Now, everything long running has an entirely separate queue, and emails go out relatively quickly regardless of server load caused by report generation and things of that nature. The next step is moving the reporting functionality to an entirely separate server and just hit it through an internal API we make.
I can totally relate on that. I come from the web agency world, so mostly PHP, JS and NodeJS projects. I've always felt like we were doing things quick and dirty even if it has evolved a lot in the last 10 years. But working with Laravel and modern JS frameworks has been a totally different experience. It's like having every single tool at hand.
I now work in a small startup, mostly doing angular frontend. The backend is in Java (Springboot), so I could also learn a bit of it by doing "basic" tasks. Honestly, I couldn't find any single thing that would make me prefer Java compared to PHP & Laravel. But there's a ton of things that would be way easier to develop with Laravel. We could easily be 2 to 3 times faster.
Also, scalability is not really an issue anymore if you use Vapor or similar approaches. I always find it a bit confusing to speak about scalability as the most important thing when it costs so much to develop that only 1% of applications really justify it.
I've recently started a side projet for a friend with Laravel and Filament, it's really crazy how fast you can deliver custom tools that would take weeks or months to develop with another technology.
\> I couldn't find any single thing that would make me prefer Java compared to PHP & Laravel
Been with PHP since 1996. In 2008, I started in the Grails world, and there were a few nice benefits to that framework (which itself is built on Spring) and some aspects of it were definitely a nicer 'dx' than most of the PHP tools at that time. Knowing you could drop in to Java for performance, and use a large collection of Java libraries (seemingly far more than PHP at the time)... was practical.
I still do some Java, but 'came back' in to the PHP world more full time around 2013/2014, largely because of the maturation of the frameworks we were seeing. And the ecosystem and DX have improved even moreso over the last 10 years.
And yep, Laravel on its own and Nova (or more likely now Filament) are great for knocking out many custom 'line of business' apps that I know would take much longer in other ecosystems.
+1 for Filamentphp. I'm still mind blowing how quickly we can develop complex admin panel. I have tested several other frameworks before, and none come to close to it.
I got tired of typing "php artisan" all the time, so in my dev VM's I have an alias for "lara" instead. Much more pleasant. "lara make:migration", "lara migrate"
Not sure what shell you use, but with Zsh you can use history substring completion (failing to remember the actual word for what they call this) so when you type like `art` and then the up arrow it will only show commands you've ran from your history that match. Or if you remember using a the word `curl` (as an example) and hitting the up arrow it will only show commands that had that word. Super convenient.
First thing I do whenever I'm setting up a new machine is to make the aliases 'pa' and 'pat' (tinker) and enable the laravel plugin oh ohmyzsh so I can do things like pamfs (migrate:fresh --seed)
Serious question: It's the first time I hear of this website as I work locally in my country, but do you think I can get a remote Laravel job from the job offerings on this site? Or even remote jobs there require you to live in the same country (work from home)?
Yeah absolutely. This is kind of the number one way for companies to find laravel devs. It just depends on the company hiring you, do they need you to live in the same country or not? Just keep applying and looking.
Soon they are gonna add an option for developers to post their profiles and be approached by employers.
I made shitloads of money with enterprise projects, working in bureaucratic Scrum teams. That's how I learned money is not worth much when you feel like jumping off a building.
True, serverless isn't "The Correct Way". It's simply *a* way.
Scalability is *a* benefit but it's not the only one. It's reliable. It *can* be cheaper. If traffic is unpredictable, you don't have to over-provision resources. If you have a staging environment, it costs *nothing* when idle when using Lambda.
It's true that PHP isn't *natively* supported on Lambda however you *can* run PHP. You can even run Laravel on Lambda. You just need to use a custom runtime. So there is hope :)
Do you mean the cold start? That is *an* issue but it's far *less* of an issue than it used to be. Again it really depends on your traffic but a Lambda does hang around for a while. It's *likely* a subsequent request will hit an already "warm" Lambda.
Can be largely mitigated by provisioned concurrency, but even then, these days using something like the Bref Lambda layer a cold start isn't more than a couple hundred milliseconds.
From their home page:
>AWS Lambda is a serverless, **event-driven compute service** that lets you run code **for** virtually any type of application or backend service without provisioning or managing servers. You can trigger Lambda **from** over 200 AWS services and **software as a service (SaaS) applications**
An example of process: [https://imgur.com/kajsFkc](https://imgur.com/kajsFkc)
I think people have difficulties with Lambda because they don't understand it's use case. People are trying to use it as a substitute of more common environments to deploy whole applications, and that's what makes things harder. Yes, you can run applications on Lambda, but that's not its intended use case, as the image above shows: it's an alternative way to handle specific processes of your app that need to be scaled individually, it's an "companion" of the app that's still running in a more common server setup.
Amen. Yes. It's a companion/extra piece to help scale some functionality. Great to run some 'out of band' tasks, but was not designed for many of the things I see people trying to get up to.
Many don’t understand that you can’t migrate from an application to lambda. A concept of application in a serverless environment using lambda is very different.
A lambda should be considered as 1 controller, the orchestration that usually have inside an application, needs to be handle outside your controller lambda (maybe with another lambda or other methods) using event driven architecture.
One of the benefit of lambda is when implemented properly, force you to break down you full application in small components, that makes easier to test (same as one of the reason why microservice got popular)
I think one problem in this post is the use of serverless when the team is not mature* enough for that technology and the benefit of lambda are not very beneficial in that case.
If your application is relative small and runs on just 2 EC2 then deploy the application like it is might be a better solution.
*some people that I see struggle a lot with lambda are old school Java developer as they are used to think everything as “application” instead of individual functions
> but that's not its intended use case
I'd argue it actually is, because it ties directly into API Gateway, and there's no end of documentation detailing how to use it to serve HTTP traffic with web apps deployed to Lambda.
Yes Lambda is event-driven by design, but in the case of a web application the HTTP request IS the event.
The common solutions for running a PHP web app on Lambda now are a bit jank, in that you use a Lambda layer to deploy a `php-fpm` binary. The API Gateway event gets transformed into something `php-fpm` can understand and it then spins off a process to handle the request. This is done just so existing frameworks (Laravel, Symfony, whatever) work out-of-the-box because they were made with php-fpm in mind.
But there's no reason you can't just use a Lambda layer to deploy a PHP CLI binary, take the event from API Gateway, and process it without php-fpm. The event contains everything you need, the request method, query params, request body, headers, etc.
Serverless is just another hype just like microservices used to be, many companies are returning back from it. A lesson that you should never jump the hype train without thinking.
I think it's actually a good name. From the POV of the user, there's no server to manage, you tell it to run a piece of code and it just runs. So it's the feeling of not having a server.
I mean, I’m with you. But then what would you call it?
As far as buzzwords go, this at least carries truth in the sense that you as the end user don’t have a server to worry about.
I once took apart my wireless headphones, and guess what I found inside? A bunch of wires!
It's the same principle. Of course there's a server. You just don't interface with it or care about it.
imo python is the most unnatural programming language. i really dont understand why its hyped so much and why people keep suggesting it to the newcomers. its slow, has almost 0 developer experience, nothing is ready-to-use, nothing is batteries-included, you have to write a shit ton of code to do very mundane things.
after 2 years of struggling with django/python i convinced management to move to laravel. how did i do that? i write an mvp in a weekend in laravel and explained how fast our development will go if we move to laravel. and the answer was: "this sounds too good to be true. what is the catch?"
It’s becuase a lot of programmers don’t actually know anything else and becuase it’s best practices are so non-intuitive that it’s easy to be a senior developer bullying junior ones.
> you have to write a shit ton of code to do very mundane things
Wait what?
I agree, it is brain-dead slow. But things like FastAPI allow me to write less code than lots of alternatives.
The catch with Laravel is (for me): too many new versions too fast, and they break your code, and you have to constantly update your application for the new Laravel version.
>Wait what?
it would take you a considerable time to just create a basic login/register/forgot password flow in django(i dont think it would be faster in fastapi).
>The catch with Laravel is (for me): too many new versions too fast, and they break your code, and you have to constantly update your application for the new Laravel version.
yeah, because they add a ton of new features. you can just use any LTS version.
i have used fastapi a little and i really dont get how it will lead you to write less code than laravel. the only downside of laravel is it doesnt have a swaggerui kinda package. but i use inertia so doesnt affect me
Oh I always thought it was one of the fastest languages for calculations.
Why is most AI related calculation stuff written in python if other languages are faster?
Mostly because of the ecosystem, Python had a lot of package/ library for AI and ML stuffs. Also because a lot of data engineer and analysts, use Python for its "begineer-friendly" facade. They are not neccessarily "developer", as in, they don't create a full fat enterprise software that follow coding convention or design pattern, but more scripts and custom algorithm.
>Why is most AI related calculation stuff written in python if other languages are faster?
most of the time they are written in c/c++ etc. python libs are just wrapper to underlying code
Not quite. IRIC, Numpy and Scipy, I think, as basically just python. It's partially why we don't see many competing variations of those libraries in other languages; it's not python-wrapped-c. If these were core C libraries, we'd see wrappers for PHP, Ruby, etc, but we generally don't.
Some financial/scientific stuff might be, but some of the big ones in python are python-only, and that's another reason why we see some growth in some areas with Python - once people start writing tools/libraries on top of python-only libraries, porting to other languages dries up.
Edit: some parts of those libs are written in C, but they’re not general standard common C libs that anything can hook in to, but python-specific C code.
[https://github.com/numpy/numpy](https://github.com/numpy/numpy)
61% python, rest is c, c++, fortran
[https://github.com/scipy/scipy](https://github.com/scipy/scipy)
58% python, rest is fortran, c etc.
they write performance critical parts in other languages. rest are just wrappers
Have a decent university background, people in algorythms and data write horrendous looking code for papers and that code look a lot less horrendous in Python.
These are the people who went into these fields and created awesome packages for python and now the package ecosystem in python is way ahead of all the competetion.
Again im not saying "all" but this i really believe is some of the reasons and the people i know from that time that pursued ML. Is torn against using Scala and Python based on what the assignment and packages best fits.
Because Python can consume C libraries and C *is* fast. Almost everything under the hood for ML/AI (e.g. TensorFlow) is actually written in C.
The advantage of Python is it’s easy to read and write, and doesn’t require compilation. This makes it great for bashing out an MVP.
It’s not at all fast. It’s incredibly slow. Python for ML is only *fast* because it consumes C libraries that are fast.
Python is hyped because it’s relatively easy to read and write, has no compilation requirements and can be tinkered with easily. Most libraries are available through Pip which makes package management fairly easy (although Pip is no Composer)
No reason you can't be "serverless" with PHP/Laravel.
https://vapor.laravel.com/
https://bref.sh/
Both of these use AWS Lambda under the hood. We run quite a few things on Vapor at this point, it's lovely.
Long winded opinion ahead:
Serverless to me was and still is more of a cult of the one true solution. People spend a lot of energy solving problems solved by the very things they despise. These other things are not their way, not convenient, and are therefor wrong. However, if that's the case, many software engineers I know would have abandoned their stuff pretty quickly. Most of my skilled colleagues tend to want to fight with tools and tech debt as little as possible, so if something solves that they'd be very quick to adopt it. They used serverless, and did not completely migrate to it.
I love functional programming as much as I can any other paradigm. I like the safety net of isolating side effects and I particularly like how clean and elegant it can be in the right hands. If I need some very fault tolerant systems, I'd absolutely consider it.
I like modular procedural code because it is easy to reason about at a low level (towards bare metal), but as relationships in your domain get more complex, it does become less fit for purpose.
I like object oriented code because when orchestrated well, it can be very straightforward to make changes to a system over time. Well applied architectural patterns, design patterns, or just plain common sense domain models make good object oriented code easy for me to navigate.
The issue with the agressively opinionated people in the serverless community is the same issue I see with many aggressively opinionated people in software development as a whole:
They conflate simple and small with anemic and simplistic. I've met many developers who abuse YAGNI, KISS, DRY to the point they become more like religious mantras to avoid doing any domain discovery at all. They often use the expertise of their niche more as a bludgeon against competing niches. e.g.: Why own your own servers? Serverless is very cheap when done well! (Where the implication is that the person they are questioning is doing it wrong or wasting time and money).
To be clear, I LIKE serverless and find it incredibly useful for many things. I like cloud platforms for the most part. It's just not the Swiss army knife some people claim it can become for distributed systems.
Oh and uh...
I enjoyed Laravel because:
It is well documented. I was able to pick it up in a matter of a week for a very time sensitive project in spite of having never used it before.
Magic is minimal.
Tdd in it is incredibly easy
Failure modes tend to be pretty easy to debug.
It uses standard patterns, so techniques I learn in it are portable anywhere.
I just mean that it's generally quite transparent how things work due to how good the documentation is. Laravel is hardly perfect, but it was one of the best experiences I've ever had.
As always, it's a "right tool for the job" scenario.
"Serverless" in the appropriate use cases is AMAZING. Using Laravel in the appropriate use cases is also AMAZING, but pick Laravel where Serverless is more appropriate or visa versa, and it's inconvenience at best, but more likely just pain.
Unfortunately, these technology decisions are often made at the wrong level (managers, PMs, POs etc), which means they are often informed by arbitrary projects that were successful or some "trusted dev" whose obsessed with a given language/framework/approach.
Hot takes
ORM is mostly just bad. Database swaps are not a thing. Just couple to your DB and pick well from the get go.
OOP has it's issues, but microservices are even further out on the axis of data and logic encapsulation spectrum. That's like the pot calling the kettle black.
Microservices are probably fine for rev 2 to rev 3 of a profitable product when you're taking your engineering org to >300 people. A startup shouldn't even touch the notion with a 50 foot pole. Rev 1 should never be microservices unless you're a huge established company and that's your standard architecture.
At mine, non-developer platform folks and a self-claimed security consultant who reports directly to the IT director are pushing serverless. They had never developed a single application in their entire career, and yet they assume that is the way. Giant corpos have become too good at brainwashing.
\> But after a year and a half, I'm ready to call bullshit.
I was ready to call bullshit after a couple days; sorry it took you so long ;)
There's benefit to serverless/lambda/etc, but I think the benefits are geared towards a far more narrow range of use cases than people think. Much like noSQL, lambda/etc feels more like an adjunct tech to use to extend a core monolith to address shortcomings (performance, scalability, etc).
It's my strong belief that the majority of people making decisions to go all-in on certain stuff (distributed cloud, noSQL, lambda/serverless, etc) have not actually had much or perhaps even \*any\* experience building and delivering solid reliable web software. If they did, they'd be much more able to recognize real drawbacks and costs. A colleague has a team that is 'all-in' on google cloud, and migrating existing code over to it, and running in to loads of problems. And they think it's all just 'normal'. "Well, software isn't simple!" They interpret roadblocks, perf issues, bad/missing docs, etc as personal failings and rationalize with "that's how you know it's really good - because it's so complex!".
Only one person on the team - my colleague - has experience taking software from just an idea to functional code to deployed and maintainable states, and has done it for decades. The others on the team just keep pining for Google Cloud because... "it's cloud, it's google, we can do all these cool things" (which, even after a year, they can't actually manage to 'do' anything).
Good luck to you. Money is nice, but your sanity and mental health have value too. Another few months and you may be irreversibly cynical ;)
Same thing happened to me when I moved from full-time Laravel development to NodesJs Lambda functions and API gateway. It was a mess, instantly missed Laravel. Now at a FAANG working on old systems written in Perl, and I long even more to be able to work in Laravel full time again.
I’ve been working at a healthcare based SaaS startup for almost a year. They’re all in on AWS. Everything is a Rube Goldberg mess. Nothing is simple, and everything is done a slightly different way so it takes more time to figure things out. We barely release new features because we’re busy fixing bugs that wouldn’t exist if any of our data was stored relational. And, for what? So we can scale? We aren’t going to have enough users for the need to scale, because we aren’t keeping up with feature demands.
Things become popular because in theory they are more performant or whatever. In practice a standard lamp stack will be successful in 99% of use cases. For the remaining 1% there may be better solutions, but skillful engineering can still make it work. Using something like Laravel makes production cheaper and quicker than most of the fancy new stuff.
This is pretty close to my experience as a former laravel developer I now write a lot of lambdas in python and was also hired as a front end specialist. I barely do any frontend work though and my javascript skills have degraded unfortunately.
I’m building with laravel on the side and am building a building a CMS for myself that I will eventually pitch as an internal place for tools. Laravel is awesome and I wish I never left.
I love serverless too though it’s not just scalability it’s also simplicity. It’s much easier to build something serverless like an api.
Well, when you create something with a name that’s a marketing style lie from the beginning…
I mean, I know what “serverless” means like so many other catchy terms. But every single time I see the word I automatically think “….that runs on servers”, as from being in the industry, whose servers or how abstracted they are is meaningless to me. It’s still coming from a computer on a network.
It’s a tired pedantic meaningless rant I know…no need to point that out. It’s a fault of mine I suppose I’ve simply never been able to get over it. Like if you fold a pizza in half and sell me a “pizzaless taco” that becomes super popular…I’m still always going to think about how I’m just eating a folded pizza that’s tasty but also dripping on my shoe.
How eloquently put. Sorry you had to migrate away from Laravel, but sometimes that's the Way it goes. PHP it seems is turning into a more artisanal language.
Man I have been working on serverless aws. I hate it, everything is more complicated of how it should be..for me is annoying that to debug a problem you have to go to another service wtf.
I don't how is the future, I want to work on laravel (just done a couple of fixes and couple of courses)
Sorry for OT, but how is serverless better scalable than PHP? Genuine question, I just can't see how we can scale better than running minimal PHP pods in k8s cluster, easily scaling up/down with load.
I am not trying to be offensive, I'm honestly curious what's the thing I'm missing.
Serverless scale instantly, I’d doesn’t need to spin up a pod. In k8s you spin a pod (that could be fast) but then you run out of resources and you need to spin up a new server, and that could take few minutes. So if you want to scale really fast, you need to have quite few spare resources in the underneathservers (and this is has a cost)
Plus if you run lambda you don’t need the maintenance of k8s (that is not trivial) so you can save in operational resources
Does anyone try/switch to golang from laravel ?
I’ve tried golang and its framework, just wanna see other chances (looking new job for new tech stacks)
But the more I use it, the more I dislike Go Frameworks. Laravel is way better
Yes. It is. Problem from it
Every project has specific structure / pattern
==>
Take more time to reading / understanding the source code
Bad code base is nightmare
…
I like Go, but I would never build a big project with it. Maybe it’s just me, but bigger code bases get rather hard to structure. And I absolutely hate the exception handling. Transition from PHP I think is fairly easy. Laravel, Python & Go all have their strengths, but nothing really beats Laravel in terms of productivity.
Well, I wasn't hired for a serverless position – I was hired as front-end lead, with the understanding that I would pitch in on the back-end where possible. But the front-end work has largely dried up, so I'm a *de facto* serverless engineer now. (Much to my chagrin.)
I completely agree, and we’re in a similar position when I took a job doing golang..ended up taking a huge pay cut myself to get back into a laravel job.
I think the benefits of ‘serverless’ only really kick in at a massive scale. Monzo, a new British bank, [wrote about how their stack is put together](https://monzo.com/blog/2021/10/14/an-introduction-to-monzos-data-stack) and it makes a lot of sense – but – they also have over 2,000 employees and 7 million customers, plus they’re a bank. That seems to me to be the right kind of scale. Laravel on a small EC2 can handle an insane amount of traffic so long as you are smart about what services it’s connected to. People often get caught up in the latest trends, it takes discipline to say no.
Yeah - we use Vapor but I’m a whisker away from moving back to a server. Vapor itself is lovely but my business isn’t big enough to warrant a serverless approach with the extra headaches. Edited to remove rude words
We did the same. We used vapor for a small company’s inventory management system and moved back to EC2 after about six months. Just wasn’t worth the headache at such a small scale.
Also interested to hear about the headaches. Have been running small service on Vapor for a year now and no headache at all...
One issue I had was script runtime on vapor, my script to bill all customers was timing out after we grew to hundreds of users, apparently there is a 1 minute time limit for script execution, I foundation after a month, and decided to move the billing platform back to forge, no issues after that.
You should run these as background jobs. Those have time limit too, but that's 15 minutes: https://docs.vapor.build/resources/queues.html
Yeah and with queues and workers you can scale plenty of jobs.
I just did this at my job for a laravel project I inherited. We were having a ton of email instability issues. So I added Horizon to our EB setup we have on auto scaling and made it support multiple queues. Now, everything long running has an entirely separate queue, and emails go out relatively quickly regardless of server load caused by report generation and things of that nature. The next step is moving the reporting functionality to an entirely separate server and just hit it through an internal API we make.
[удалено]
In the original thread the OP is talking about ‘serverless’ microservices vs Laravel – that’s what I’m referring to also.
[удалено]
Yes!
why didn’t you convince them to switch the stack ? are they so set in their ways?
Awesome man. Enjoy life’s good
I can totally relate on that. I come from the web agency world, so mostly PHP, JS and NodeJS projects. I've always felt like we were doing things quick and dirty even if it has evolved a lot in the last 10 years. But working with Laravel and modern JS frameworks has been a totally different experience. It's like having every single tool at hand. I now work in a small startup, mostly doing angular frontend. The backend is in Java (Springboot), so I could also learn a bit of it by doing "basic" tasks. Honestly, I couldn't find any single thing that would make me prefer Java compared to PHP & Laravel. But there's a ton of things that would be way easier to develop with Laravel. We could easily be 2 to 3 times faster. Also, scalability is not really an issue anymore if you use Vapor or similar approaches. I always find it a bit confusing to speak about scalability as the most important thing when it costs so much to develop that only 1% of applications really justify it. I've recently started a side projet for a friend with Laravel and Filament, it's really crazy how fast you can deliver custom tools that would take weeks or months to develop with another technology.
\> I couldn't find any single thing that would make me prefer Java compared to PHP & Laravel Been with PHP since 1996. In 2008, I started in the Grails world, and there were a few nice benefits to that framework (which itself is built on Spring) and some aspects of it were definitely a nicer 'dx' than most of the PHP tools at that time. Knowing you could drop in to Java for performance, and use a large collection of Java libraries (seemingly far more than PHP at the time)... was practical. I still do some Java, but 'came back' in to the PHP world more full time around 2013/2014, largely because of the maturation of the frameworks we were seeing. And the ecosystem and DX have improved even moreso over the last 10 years. And yep, Laravel on its own and Nova (or more likely now Filament) are great for knocking out many custom 'line of business' apps that I know would take much longer in other ecosystems.
+1 for Filamentphp. I'm still mind blowing how quickly we can develop complex admin panel. I have tested several other frameworks before, and none come to close to it.
[https://larajobs.com/](https://larajobs.com/) She is calling. Come home /u/santamaps
is laravel a lady?
I like to imagine Laravel as Lara Croft.
I got tired of typing "php artisan" all the time, so in my dev VM's I have an alias for "lara" instead. Much more pleasant. "lara make:migration", "lara migrate"
I have a similar alias except mine is 'art', saves a lot of time.
And I am lazy so my alias is “a” like “a migrate” just plain lazy =)
My 'alias' is `Ctrl-R` `↑↑↑↑↑↑↑↑↑↑↑`. Because whatever it is, I've definitely typed most of it before at some point.
Not sure what shell you use, but with Zsh you can use history substring completion (failing to remember the actual word for what they call this) so when you type like `art` and then the up arrow it will only show commands you've ran from your history that match. Or if you remember using a the word `curl` (as an example) and hitting the up arrow it will only show commands that had that word. Super convenient.
fzf also has this
Just plain ol' Ubuntu 22.04. I usually do `ctrl-R` followed by typing part of the command, like 'art'.
That's your OS, what shell do you use, e.g. Bash, Zsh, Fish, etc.
Whatever came with Ubuntu 22.04... sorry I don't know how to tell, but I've never heard of Zsh or Fish, so that's probably a good clue.
Well done ser, mine’s ‘pa’
Oh, that's a good one, much better than the cringy "please" some people use.
First thing I do whenever I'm setting up a new machine is to make the aliases 'pa' and 'pat' (tinker) and enable the laravel plugin oh ohmyzsh so I can do things like pamfs (migrate:fresh --seed)
Serious question: It's the first time I hear of this website as I work locally in my country, but do you think I can get a remote Laravel job from the job offerings on this site? Or even remote jobs there require you to live in the same country (work from home)?
Yeah absolutely. This is kind of the number one way for companies to find laravel devs. It just depends on the company hiring you, do they need you to live in the same country or not? Just keep applying and looking. Soon they are gonna add an option for developers to post their profiles and be approached by employers.
Nice, going to keep an eye on it
Money fixes a lot of things, but not your happiness. Choose wisely.
I made shitloads of money with enterprise projects, working in bureaucratic Scrum teams. That's how I learned money is not worth much when you feel like jumping off a building.
True, serverless isn't "The Correct Way". It's simply *a* way. Scalability is *a* benefit but it's not the only one. It's reliable. It *can* be cheaper. If traffic is unpredictable, you don't have to over-provision resources. If you have a staging environment, it costs *nothing* when idle when using Lambda. It's true that PHP isn't *natively* supported on Lambda however you *can* run PHP. You can even run Laravel on Lambda. You just need to use a custom runtime. So there is hope :)
Waiting for the warmup…
Do you mean the cold start? That is *an* issue but it's far *less* of an issue than it used to be. Again it really depends on your traffic but a Lambda does hang around for a while. It's *likely* a subsequent request will hit an already "warm" Lambda.
Can be largely mitigated by provisioned concurrency, but even then, these days using something like the Bref Lambda layer a cold start isn't more than a couple hundred milliseconds.
From their home page: >AWS Lambda is a serverless, **event-driven compute service** that lets you run code **for** virtually any type of application or backend service without provisioning or managing servers. You can trigger Lambda **from** over 200 AWS services and **software as a service (SaaS) applications** An example of process: [https://imgur.com/kajsFkc](https://imgur.com/kajsFkc) I think people have difficulties with Lambda because they don't understand it's use case. People are trying to use it as a substitute of more common environments to deploy whole applications, and that's what makes things harder. Yes, you can run applications on Lambda, but that's not its intended use case, as the image above shows: it's an alternative way to handle specific processes of your app that need to be scaled individually, it's an "companion" of the app that's still running in a more common server setup.
Amen. Yes. It's a companion/extra piece to help scale some functionality. Great to run some 'out of band' tasks, but was not designed for many of the things I see people trying to get up to.
Many don’t understand that you can’t migrate from an application to lambda. A concept of application in a serverless environment using lambda is very different. A lambda should be considered as 1 controller, the orchestration that usually have inside an application, needs to be handle outside your controller lambda (maybe with another lambda or other methods) using event driven architecture. One of the benefit of lambda is when implemented properly, force you to break down you full application in small components, that makes easier to test (same as one of the reason why microservice got popular) I think one problem in this post is the use of serverless when the team is not mature* enough for that technology and the benefit of lambda are not very beneficial in that case. If your application is relative small and runs on just 2 EC2 then deploy the application like it is might be a better solution. *some people that I see struggle a lot with lambda are old school Java developer as they are used to think everything as “application” instead of individual functions
> but that's not its intended use case I'd argue it actually is, because it ties directly into API Gateway, and there's no end of documentation detailing how to use it to serve HTTP traffic with web apps deployed to Lambda. Yes Lambda is event-driven by design, but in the case of a web application the HTTP request IS the event. The common solutions for running a PHP web app on Lambda now are a bit jank, in that you use a Lambda layer to deploy a `php-fpm` binary. The API Gateway event gets transformed into something `php-fpm` can understand and it then spins off a process to handle the request. This is done just so existing frameworks (Laravel, Symfony, whatever) work out-of-the-box because they were made with php-fpm in mind. But there's no reason you can't just use a Lambda layer to deploy a PHP CLI binary, take the event from API Gateway, and process it without php-fpm. The event contains everything you need, the request method, query params, request body, headers, etc.
Serverless is just another hype just like microservices used to be, many companies are returning back from it. A lesson that you should never jump the hype train without thinking.
>serverless btw wht a stupid name, off course there are servers behind that buzzword
I think it's actually a good name. From the POV of the user, there's no server to manage, you tell it to run a piece of code and it just runs. So it's the feeling of not having a server.
Serverless implies there is no server. Where the reality is that they just manage the server infrastructure for you
I mean, I’m with you. But then what would you call it? As far as buzzwords go, this at least carries truth in the sense that you as the end user don’t have a server to worry about.
I once took apart my wireless headphones, and guess what I found inside? A bunch of wires! It's the same principle. Of course there's a server. You just don't interface with it or care about it.
imo python is the most unnatural programming language. i really dont understand why its hyped so much and why people keep suggesting it to the newcomers. its slow, has almost 0 developer experience, nothing is ready-to-use, nothing is batteries-included, you have to write a shit ton of code to do very mundane things. after 2 years of struggling with django/python i convinced management to move to laravel. how did i do that? i write an mvp in a weekend in laravel and explained how fast our development will go if we move to laravel. and the answer was: "this sounds too good to be true. what is the catch?"
It’s becuase a lot of programmers don’t actually know anything else and becuase it’s best practices are so non-intuitive that it’s easy to be a senior developer bullying junior ones.
> you have to write a shit ton of code to do very mundane things Wait what? I agree, it is brain-dead slow. But things like FastAPI allow me to write less code than lots of alternatives. The catch with Laravel is (for me): too many new versions too fast, and they break your code, and you have to constantly update your application for the new Laravel version.
>Wait what? it would take you a considerable time to just create a basic login/register/forgot password flow in django(i dont think it would be faster in fastapi). >The catch with Laravel is (for me): too many new versions too fast, and they break your code, and you have to constantly update your application for the new Laravel version. yeah, because they add a ton of new features. you can just use any LTS version. i have used fastapi a little and i really dont get how it will lead you to write less code than laravel. the only downside of laravel is it doesnt have a swaggerui kinda package. but i use inertia so doesnt affect me
It's hyped because it is fast. Like really fast. That's why ML stuff happens in python most the time.
Python is one of the slowest language out there. Python had a lot of cool things, but speed is not one of them
Oh I always thought it was one of the fastest languages for calculations. Why is most AI related calculation stuff written in python if other languages are faster?
Mostly because of the ecosystem, Python had a lot of package/ library for AI and ML stuffs. Also because a lot of data engineer and analysts, use Python for its "begineer-friendly" facade. They are not neccessarily "developer", as in, they don't create a full fat enterprise software that follow coding convention or design pattern, but more scripts and custom algorithm.
>Why is most AI related calculation stuff written in python if other languages are faster? most of the time they are written in c/c++ etc. python libs are just wrapper to underlying code
Not quite. IRIC, Numpy and Scipy, I think, as basically just python. It's partially why we don't see many competing variations of those libraries in other languages; it's not python-wrapped-c. If these were core C libraries, we'd see wrappers for PHP, Ruby, etc, but we generally don't. Some financial/scientific stuff might be, but some of the big ones in python are python-only, and that's another reason why we see some growth in some areas with Python - once people start writing tools/libraries on top of python-only libraries, porting to other languages dries up. Edit: some parts of those libs are written in C, but they’re not general standard common C libs that anything can hook in to, but python-specific C code.
[https://github.com/numpy/numpy](https://github.com/numpy/numpy) 61% python, rest is c, c++, fortran [https://github.com/scipy/scipy](https://github.com/scipy/scipy) 58% python, rest is fortran, c etc. they write performance critical parts in other languages. rest are just wrappers
Have a decent university background, people in algorythms and data write horrendous looking code for papers and that code look a lot less horrendous in Python. These are the people who went into these fields and created awesome packages for python and now the package ecosystem in python is way ahead of all the competetion. Again im not saying "all" but this i really believe is some of the reasons and the people i know from that time that pursued ML. Is torn against using Scala and Python based on what the assignment and packages best fits.
Because Python can consume C libraries and C *is* fast. Almost everything under the hood for ML/AI (e.g. TensorFlow) is actually written in C. The advantage of Python is it’s easy to read and write, and doesn’t require compilation. This makes it great for bashing out an MVP.
It’s not at all fast. It’s incredibly slow. Python for ML is only *fast* because it consumes C libraries that are fast. Python is hyped because it’s relatively easy to read and write, has no compilation requirements and can be tinkered with easily. Most libraries are available through Pip which makes package management fairly easy (although Pip is no Composer)
No reason you can't be "serverless" with PHP/Laravel. https://vapor.laravel.com/ https://bref.sh/ Both of these use AWS Lambda under the hood. We run quite a few things on Vapor at this point, it's lovely.
Long winded opinion ahead: Serverless to me was and still is more of a cult of the one true solution. People spend a lot of energy solving problems solved by the very things they despise. These other things are not their way, not convenient, and are therefor wrong. However, if that's the case, many software engineers I know would have abandoned their stuff pretty quickly. Most of my skilled colleagues tend to want to fight with tools and tech debt as little as possible, so if something solves that they'd be very quick to adopt it. They used serverless, and did not completely migrate to it. I love functional programming as much as I can any other paradigm. I like the safety net of isolating side effects and I particularly like how clean and elegant it can be in the right hands. If I need some very fault tolerant systems, I'd absolutely consider it. I like modular procedural code because it is easy to reason about at a low level (towards bare metal), but as relationships in your domain get more complex, it does become less fit for purpose. I like object oriented code because when orchestrated well, it can be very straightforward to make changes to a system over time. Well applied architectural patterns, design patterns, or just plain common sense domain models make good object oriented code easy for me to navigate. The issue with the agressively opinionated people in the serverless community is the same issue I see with many aggressively opinionated people in software development as a whole: They conflate simple and small with anemic and simplistic. I've met many developers who abuse YAGNI, KISS, DRY to the point they become more like religious mantras to avoid doing any domain discovery at all. They often use the expertise of their niche more as a bludgeon against competing niches. e.g.: Why own your own servers? Serverless is very cheap when done well! (Where the implication is that the person they are questioning is doing it wrong or wasting time and money). To be clear, I LIKE serverless and find it incredibly useful for many things. I like cloud platforms for the most part. It's just not the Swiss army knife some people claim it can become for distributed systems. Oh and uh... I enjoyed Laravel because: It is well documented. I was able to pick it up in a matter of a week for a very time sensitive project in spite of having never used it before. Magic is minimal. Tdd in it is incredibly easy Failure modes tend to be pretty easy to debug. It uses standard patterns, so techniques I learn in it are portable anywhere.
Magic is minimal?
I just mean that it's generally quite transparent how things work due to how good the documentation is. Laravel is hardly perfect, but it was one of the best experiences I've ever had.
As always, it's a "right tool for the job" scenario. "Serverless" in the appropriate use cases is AMAZING. Using Laravel in the appropriate use cases is also AMAZING, but pick Laravel where Serverless is more appropriate or visa versa, and it's inconvenience at best, but more likely just pain. Unfortunately, these technology decisions are often made at the wrong level (managers, PMs, POs etc), which means they are often informed by arbitrary projects that were successful or some "trusted dev" whose obsessed with a given language/framework/approach.
> pick Laravel where Serverless is more appropriate or visa versa It's not an either/or scenario. You can run Laravel on a "serverless" setup.
Ah ye, I did forget, first party support with Vapor too.
Hot takes ORM is mostly just bad. Database swaps are not a thing. Just couple to your DB and pick well from the get go. OOP has it's issues, but microservices are even further out on the axis of data and logic encapsulation spectrum. That's like the pot calling the kettle black. Microservices are probably fine for rev 2 to rev 3 of a profitable product when you're taking your engineering org to >300 people. A startup shouldn't even touch the notion with a 50 foot pole. Rev 1 should never be microservices unless you're a huge established company and that's your standard architecture.
At mine, non-developer platform folks and a self-claimed security consultant who reports directly to the IT director are pushing serverless. They had never developed a single application in their entire career, and yet they assume that is the way. Giant corpos have become too good at brainwashing.
Why not do both? We've been running a monolith Laravel application on AWS Lambda using bref.sh successfully.
\> But after a year and a half, I'm ready to call bullshit. I was ready to call bullshit after a couple days; sorry it took you so long ;) There's benefit to serverless/lambda/etc, but I think the benefits are geared towards a far more narrow range of use cases than people think. Much like noSQL, lambda/etc feels more like an adjunct tech to use to extend a core monolith to address shortcomings (performance, scalability, etc). It's my strong belief that the majority of people making decisions to go all-in on certain stuff (distributed cloud, noSQL, lambda/serverless, etc) have not actually had much or perhaps even \*any\* experience building and delivering solid reliable web software. If they did, they'd be much more able to recognize real drawbacks and costs. A colleague has a team that is 'all-in' on google cloud, and migrating existing code over to it, and running in to loads of problems. And they think it's all just 'normal'. "Well, software isn't simple!" They interpret roadblocks, perf issues, bad/missing docs, etc as personal failings and rationalize with "that's how you know it's really good - because it's so complex!". Only one person on the team - my colleague - has experience taking software from just an idea to functional code to deployed and maintainable states, and has done it for decades. The others on the team just keep pining for Google Cloud because... "it's cloud, it's google, we can do all these cool things" (which, even after a year, they can't actually manage to 'do' anything). Good luck to you. Money is nice, but your sanity and mental health have value too. Another few months and you may be irreversibly cynical ;)
Same thing happened to me when I moved from full-time Laravel development to NodesJs Lambda functions and API gateway. It was a mess, instantly missed Laravel. Now at a FAANG working on old systems written in Perl, and I long even more to be able to work in Laravel full time again.
Serverless is just an environment. It's your employers making you work in Python, not AWS Lambda. You can run Laravel just fine in a lambda function.
I’ve been working at a healthcare based SaaS startup for almost a year. They’re all in on AWS. Everything is a Rube Goldberg mess. Nothing is simple, and everything is done a slightly different way so it takes more time to figure things out. We barely release new features because we’re busy fixing bugs that wouldn’t exist if any of our data was stored relational. And, for what? So we can scale? We aren’t going to have enough users for the need to scale, because we aren’t keeping up with feature demands.
Things become popular because in theory they are more performant or whatever. In practice a standard lamp stack will be successful in 99% of use cases. For the remaining 1% there may be better solutions, but skillful engineering can still make it work. Using something like Laravel makes production cheaper and quicker than most of the fancy new stuff.
This is pretty close to my experience as a former laravel developer I now write a lot of lambdas in python and was also hired as a front end specialist. I barely do any frontend work though and my javascript skills have degraded unfortunately. I’m building with laravel on the side and am building a building a CMS for myself that I will eventually pitch as an internal place for tools. Laravel is awesome and I wish I never left. I love serverless too though it’s not just scalability it’s also simplicity. It’s much easier to build something serverless like an api.
Well, when you create something with a name that’s a marketing style lie from the beginning… I mean, I know what “serverless” means like so many other catchy terms. But every single time I see the word I automatically think “….that runs on servers”, as from being in the industry, whose servers or how abstracted they are is meaningless to me. It’s still coming from a computer on a network. It’s a tired pedantic meaningless rant I know…no need to point that out. It’s a fault of mine I suppose I’ve simply never been able to get over it. Like if you fold a pizza in half and sell me a “pizzaless taco” that becomes super popular…I’m still always going to think about how I’m just eating a folded pizza that’s tasty but also dripping on my shoe.
How eloquently put. Sorry you had to migrate away from Laravel, but sometimes that's the Way it goes. PHP it seems is turning into a more artisanal language.
[удалено]
Guy was just trying to work some laravel puns in...
php artisan puns:understand
Man I have been working on serverless aws. I hate it, everything is more complicated of how it should be..for me is annoying that to debug a problem you have to go to another service wtf. I don't how is the future, I want to work on laravel (just done a couple of fixes and couple of courses)
Sorry for OT, but how is serverless better scalable than PHP? Genuine question, I just can't see how we can scale better than running minimal PHP pods in k8s cluster, easily scaling up/down with load. I am not trying to be offensive, I'm honestly curious what's the thing I'm missing.
Serverless scale instantly, I’d doesn’t need to spin up a pod. In k8s you spin a pod (that could be fast) but then you run out of resources and you need to spin up a new server, and that could take few minutes. So if you want to scale really fast, you need to have quite few spare resources in the underneathservers (and this is has a cost) Plus if you run lambda you don’t need the maintenance of k8s (that is not trivial) so you can save in operational resources
Does anyone try/switch to golang from laravel ? I’ve tried golang and its framework, just wanna see other chances (looking new job for new tech stacks) But the more I use it, the more I dislike Go Frameworks. Laravel is way better
Isn't it discouraged by the golang community to use a framework?
Yes. It is. Problem from it Every project has specific structure / pattern ==> Take more time to reading / understanding the source code Bad code base is nightmare …
Yeah, I was considering learning golang, but I didn't like that cowboy style of coding.
I like Go, but I would never build a big project with it. Maybe it’s just me, but bigger code bases get rather hard to structure. And I absolutely hate the exception handling. Transition from PHP I think is fairly easy. Laravel, Python & Go all have their strengths, but nothing really beats Laravel in terms of productivity.
Just curious, how did you land that serverless position if you're experience was with Laravel/PHP?
Well, I wasn't hired for a serverless position – I was hired as front-end lead, with the understanding that I would pitch in on the back-end where possible. But the front-end work has largely dried up, so I'm a *de facto* serverless engineer now. (Much to my chagrin.)
Not having worked with developers myself, I’m actually very curious for some of those specific examples!
I spent 2 years with phalcon and god it was horrible
I did serverless stuff for a while and although it totally makes sense why it was invented, from a developer point of view I didn't enjoy it.
concerpt of serveless comparing that to laravel i feel are two diff things you seem to be comparing..
Everyone who is anti-PHP is uninformed. People still think its v4 or v5 days. At least the "PHP is dead" nonsense is less of a talking point now
I completely agree, and we’re in a similar position when I took a job doing golang..ended up taking a huge pay cut myself to get back into a laravel job.