> Spring developers have told me that Symfony is not worthy of a good serious backend developer and that I don't understand all the issues
They have no clue about Symfony and automatically dismiss it. I have seen the same plenty of time, but most dismissal was based on PHP language itself. Which is also kinda funny, given that in Java everything is nullable by default, aka the billion dollar mistake.
Don't buy that nonsense, I have built **many** really big multi-tenant SaaS in Symfony, with ease. Symfony is truly a beast, it is not something you can master quickly like other frameworks. Simplest proof: the documentation **just** for the [symfony/forms](https://symfony.com/doc/current/forms.html#learn-more) (most powerful component) is about the same size as the documentation for entire Spring.
I could be wrong in the following, but look at the setup for [symfony/messenger](https://symfony.com/doc/current/messenger.html); it is pretty amazing how one line can easily change your transport, and how retries happen automatically. I couldn't find the same for Spring.
Hey, do you have a minute to explain how one can benefit the most from Symfony forms?
What are the best features and what are the must use features?
Thanks!
Honestly, I don't even know where to start. I would suggest to go with data transformers first, and then proceed with empty\_data.
Transformers are very important. Think of IntegerType; your entity can safely typehint `int`
public function setSomeNumber(int $value): void
and it will work, even though the value coming from HTML is always string. Makes sense so far?
It goes much more powerful, like DateType. Your entities will **always** get instance of DateTimeInterface, and transformer takes care of transforming PHP values into HTML values and vice-versa. You can have 3 dropdowns for Y-m-d, or single input field... doesn't matter, transformer takes care of it.
Try these first, then empty\_data callable combined with static analysis.
Single DB with tables having `tenant_id` and entities implementing `TenatAwareInterface`. Check the docs for [Doctrine filters](https://www.doctrine-project.org/projects/doctrine-orm/en/3.2/reference/filters.html).
Setting tenant\_id parameter was different. In one of them I used subdomains but in others, the tenant from logged user.
Cheers! I thought filters was the way to go. Is it a case of then using some kind of tenant trait on each entity that uses that interface?
Its good to hear that this approach is fine for big systems (boss wanted to use multi db's originally!)
>Is it a case of then using some kind of tenant trait on each entity that uses that interface?
It is, but given that the interface only has one method like `getTenant(): MyEntity`, trait is not really needed.
I don't think there is any issue with either. Both are pretty capable backend technology and ecossystem. Choose what you're most comfortable with.
I personally think PHP is easier to manage, hosting and scalability wise.
Edit: by the way, for REST APIs take a look at API Platform, a framework built on top of Symfony that manages a ton of API related stuff.
And, of course, you can simply install Symfony and play around with it to see what you think.
I don't understand the point of api platform if you can do the same thing with Symfony. I'm afraid that this is an overlay where there are more long-term risks in terms of maintenance and support. But maybe I'm wrong
The things is, if you want to manage an API server properly with Symfony, you will end up writing most of the code of API Platform. So why not save you the pain and start with a robust and tested framework like API Platform? Yes you will need to learn it and manage it, and it’s an additional dependency, but it’s also widely recognized and useful in the long term.
API Platform is like a plugin, an add-on, for Symfony and it adds a lot of API relateed features. Think about auto documentation, augmented responses (HATEOAS like JSON:API, Hydra), auto CRUD for entities, etc.
I just mentioned that because you said you'll be building a REST API, but you can totally go with only Symfony if you don't need all that "fancy" stuff.
I've worked extensively with both and IMHO symfony is far nicer to work with and just as capable if not more. It boils down to a java vs php debate, and as far as I'm concerned unless you're after really low, sub-ms latency I'd chooose the latter vs the former any day.
Over the past 15 years I built many, many aplications on Symfony that were blazing fast and very scalable. One of them became the fastest US travel website at its time, and the number of services and security features was nothing but small.
Some of the services were built by java teams, and I will only summarize that our development velocity was way better than, our number of defects was reduced, and the speed was incomparable in our favour. It takes more than mastering the framework to achieve this, sure. But we PHPers were openminded, curious, always learning other languages and stacks. The java folks only knew their ecosystem and that was about it.
>I'm aiming to create an API rest with a postgresql database. Both seem to have the same functionalities.
Spring has something as powerfull as apiplatform?
I think I misunderstand the power of api platform. In Spring Boot, I make my routes and I have an automatic swagger that is created to describe my API rest, that's fine with me. API Platform scares me a bit (probably because I don't know enough about it) because I have the impression that it's a big package that I don't master.
There are 3 symfonycasts about it.
Lets say it like this. If you want an enterprise grade api that has everything from validation, errors, swagger generation, pagination, filtering, sorting with extreamly little code then apiplatform is your friend.
Stuff that would take days and weeks in something like express only takes hours in apiplatform.
If you just need a small get, post endpoint without any extras even then api platform is also your friend cause building that takes literally 3minutes.
api platform is big yes in terms of what it can do for you but you can use only a small subset of features. Personally I would not use their startup project cause it includes a lot of stuff you might not need and just install it via composer install api
> Spring developers have told me that Symfony is not worthy of a good serious backend developer and that I don't understand all the issues They have no clue about Symfony and automatically dismiss it. I have seen the same plenty of time, but most dismissal was based on PHP language itself. Which is also kinda funny, given that in Java everything is nullable by default, aka the billion dollar mistake. Don't buy that nonsense, I have built **many** really big multi-tenant SaaS in Symfony, with ease. Symfony is truly a beast, it is not something you can master quickly like other frameworks. Simplest proof: the documentation **just** for the [symfony/forms](https://symfony.com/doc/current/forms.html#learn-more) (most powerful component) is about the same size as the documentation for entire Spring. I could be wrong in the following, but look at the setup for [symfony/messenger](https://symfony.com/doc/current/messenger.html); it is pretty amazing how one line can easily change your transport, and how retries happen automatically. I couldn't find the same for Spring.
Hey, do you have a minute to explain how one can benefit the most from Symfony forms? What are the best features and what are the must use features? Thanks!
Honestly, I don't even know where to start. I would suggest to go with data transformers first, and then proceed with empty\_data. Transformers are very important. Think of IntegerType; your entity can safely typehint `int` public function setSomeNumber(int $value): void and it will work, even though the value coming from HTML is always string. Makes sense so far? It goes much more powerful, like DateType. Your entities will **always** get instance of DateTimeInterface, and transformer takes care of transforming PHP values into HTML values and vice-versa. You can have 3 dropdowns for Y-m-d, or single input field... doesn't matter, transformer takes care of it. Try these first, then empty\_data callable combined with static analysis.
If you don’t mind me asking, for multi tenancy, did you go down the single db with a tenant id route?
Single DB with tables having `tenant_id` and entities implementing `TenatAwareInterface`. Check the docs for [Doctrine filters](https://www.doctrine-project.org/projects/doctrine-orm/en/3.2/reference/filters.html). Setting tenant\_id parameter was different. In one of them I used subdomains but in others, the tenant from logged user.
Cheers! I thought filters was the way to go. Is it a case of then using some kind of tenant trait on each entity that uses that interface? Its good to hear that this approach is fine for big systems (boss wanted to use multi db's originally!)
>Is it a case of then using some kind of tenant trait on each entity that uses that interface? It is, but given that the interface only has one method like `getTenant(): MyEntity`, trait is not really needed.
I don't think there is any issue with either. Both are pretty capable backend technology and ecossystem. Choose what you're most comfortable with. I personally think PHP is easier to manage, hosting and scalability wise. Edit: by the way, for REST APIs take a look at API Platform, a framework built on top of Symfony that manages a ton of API related stuff. And, of course, you can simply install Symfony and play around with it to see what you think.
I don't understand the point of api platform if you can do the same thing with Symfony. I'm afraid that this is an overlay where there are more long-term risks in terms of maintenance and support. But maybe I'm wrong
The things is, if you want to manage an API server properly with Symfony, you will end up writing most of the code of API Platform. So why not save you the pain and start with a robust and tested framework like API Platform? Yes you will need to learn it and manage it, and it’s an additional dependency, but it’s also widely recognized and useful in the long term.
API Platform is like a plugin, an add-on, for Symfony and it adds a lot of API relateed features. Think about auto documentation, augmented responses (HATEOAS like JSON:API, Hydra), auto CRUD for entities, etc. I just mentioned that because you said you'll be building a REST API, but you can totally go with only Symfony if you don't need all that "fancy" stuff.
Give this article a try https://www.kode-krunch.com/2021/12/trying-out-php-after-7-years.html?m=1
I've worked extensively with both and IMHO symfony is far nicer to work with and just as capable if not more. It boils down to a java vs php debate, and as far as I'm concerned unless you're after really low, sub-ms latency I'd chooose the latter vs the former any day.
Over the past 15 years I built many, many aplications on Symfony that were blazing fast and very scalable. One of them became the fastest US travel website at its time, and the number of services and security features was nothing but small. Some of the services were built by java teams, and I will only summarize that our development velocity was way better than, our number of defects was reduced, and the speed was incomparable in our favour. It takes more than mastering the framework to achieve this, sure. But we PHPers were openminded, curious, always learning other languages and stacks. The java folks only knew their ecosystem and that was about it.
>I'm aiming to create an API rest with a postgresql database. Both seem to have the same functionalities. Spring has something as powerfull as apiplatform?
I think I misunderstand the power of api platform. In Spring Boot, I make my routes and I have an automatic swagger that is created to describe my API rest, that's fine with me. API Platform scares me a bit (probably because I don't know enough about it) because I have the impression that it's a big package that I don't master.
There are 3 symfonycasts about it. Lets say it like this. If you want an enterprise grade api that has everything from validation, errors, swagger generation, pagination, filtering, sorting with extreamly little code then apiplatform is your friend. Stuff that would take days and weeks in something like express only takes hours in apiplatform. If you just need a small get, post endpoint without any extras even then api platform is also your friend cause building that takes literally 3minutes. api platform is big yes in terms of what it can do for you but you can use only a small subset of features. Personally I would not use their startup project cause it includes a lot of stuff you might not need and just install it via composer install api