Thanks for the both great tools. just i didn't understand one thing ?
the request flow, imaging we have 10 servers where we choose this request goes to server 1 and the other goes to 7 for example. and since its zero down time, how it says server 5 is updating so till it gets up no request should go there.
With over eight years of leadership experience in technology teams, I have witnessed the challenges and opportunities in our fast-paced industry. To enhance team performance and project outcomes, I developed a methodology called Cycle.
The Cycle approach emphasizes a flexible, lightweight methodology designed to keep teams focused, collaborative, and adaptable, with no backlog overload, minimal ceremonies, and shared responsibility.
author here. as i mentioned in post i said we choose frankenphp since it's already supported by php foundation and in some cases we might use Go php extensions. i know writing extensions in any language add a bit complexitiy but i believe if the extensions selected wisely they will be somehow fire and forget. for instance creating pdf files would be faster in Go than php. you can create an pdf creator extension and that extension would probebly work for a long time without any adding much effort to maintenance.
Perfect. we wrote our gateway in Go which handle authentication as well and then pass users data to other services (Go and php) and return their responses.
author here. thanks for reading my post. i didn't suggest php for all type of projects. i don't choose that myself. what i just mentioned if the only reason to choose something else for responding some apis faster you still may continue in php for that.
as i mentioned we just choosed frankenphp which is officially supported by php foundation. also only less than 5 percent of our code base is in Go. i don't see any problem to hire developers.
i don't recommend rewrite in anycase (had done 2 successful rewrite before but still i don't choose that my self) and new php run times can may be really fast. you can checkout benchmarks. swoole for instance if used with all the functionalities like its specific caches may be so fast (in some cases as fast as Go)
Author here. thanks for reading my post.
actually you still don't need rewrite. running php with workers (swoole, frankenphp, ...) may be as fast as node.
and for typed array php has static analysers like phpstan. it support generics and typed arrays with typed comments.
about 6 months ago we hired a 24 aged guy as a php developer (with more than 3 year experience). so yes.
with recent changes in PHP, like modernize stack, good frameworks (laravel, symfony, hyperf) and huge speed it gains from new runtimes like swoole, openswoole, frankenphp, it is really good stack to start new projects and have almost zero need for future migration to something else.
i need to mention we have GO in our backend stack as well and no plan to migrate anything but in our case GO services can easily be replaced with new PHP runtimes and we would have no performance issues.
Thanks a lot for the review you did which was much more than i requested. i noted all the 4 comments you did to apply on the package. Thanks again.
Also currently we have Laravel backend and Laravel + Redis + Horizon [0] + Supervisor as a queue runner for our production and it's working fine for us. but would be great to can access Hatchet from php as well which we might switch in future as well.
Another thing since you mentioned handling large work load do you recommend Hatchet as kafka or Rabbit message queue alternative to microservice communications ?
Don't want to steal your topic but I had written a lightweight task runner to learn GoLang [0]. Would be great to have your and others' comments. It works only as a Go library.
One year ago we successfully migrated to a new version (totally big bang) with less than 4 hours downtime, for us it was version 3 and v1 and v2 (plus a side service) both was working side by side (v2 was a failed migration so they ended up a frankenstein system which some requests goes to v2 and some other to v1 and they put data in each other's databases. yes not a single source of truth for all the data in database) and here are my three cents:
1. Don't - i don't know the size of the software but for us it was lots of works specially at weekends and holidays. after release almost half of the developers quits and the other half were exhausted. totally doesn't worth that.
2. Don't - if its possible to fix and refactor current version please do that. you would thank yourself later. we had 15 months of developments and in the middle of the project we need some features and fundemental fixes for our current version which we ended up another minor migration that we called v2.9.
3. Don't - only do it if you had to and do it incrementally as others suggested. start by building a microservice for most used domain of your application with api backward compatibility (if possible) and even use same database you are already using.
If you can't refactor current version (which i can't understand why) and you insist to have a bigbang migration know the current system well and know every column in the database(s) since you will need to migrate millions of data at the end which is a big project by itself.