Calling Developers!
We are reenergizing our code contribution process! Learn More

What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Can you share with me why Spryker choose Propel instead of Doctrine?

Options
U03A37J26NP
U03A37J26NP Posts: 5 🧑🏻‍🚀 - Cadet
edited June 2023 in Knowledge Sharing

Hey guys,
Can you share with me why Spryker choose Propel instead of Doctrine?

Tagged:

Comments

  • Unknown
    Unknown
    Options

    The answer is within 2011-2013 somewhere, so too long ago I think for most of us to know for sure.

  • Alberto Reyer
    Alberto Reyer Lead Spryker Solution Architect / Technical Director Posts: 690 🪐 - Explorer
    Options

    Back then the decision was taken due to the more simplistic approach of Propel. You can argue if this is still valid or not, but that's not the point.

    When we founded Spryker, a good part of the code base was taken from an internal framework (Yves & Zed) developed by Project A and back then we had a very long list of things to adapt and change to lay the foundation of what Spryker is today.
    One of the things on the list was to exchange Propel by Doctrine, especially as I see a lot of value in the data mapper which would have been handy in a lot of places. But we decided against as the effort needed would have nearly a complete rewrite of the Spryker base compared against very little value add using Doctrine instead.

    In the end, even as I was the one always arguing for migrating to Doctrine, I think that this decision was good one, while other decisions, like starting without a message queue were clearly wrong and it's good Spryker has challenged and fixed a lot of those decision that we did in the early days.

  • UKU1E0ENB
    UKU1E0ENB Posts: 34 🧑🏻‍🚀 - Cadet
    edited September 2022
    Options

    ☝ Alberto is right about this. Back then we checked Doctrine and decided against it. Doctrine is quite complex and Propel is lightweight but powerful.

    The only bad thing about Propel v1 architecture is the active record pattern which connects the entities with the ORM. This forced us to introduce another - independent - type of data objects (~ the transfer objects).

    Another problem was that propel wasn't maintained anymore, that's why Spryker took it over some years ago.

    I think Propel 2 improved this, but @UQK3ZPJEN knows this much better.

  • Chemaclass
    Chemaclass Tech Lead Spryker Solution Partner Posts: 213 🧑🏻‍🚀 - Cadet
    edited September 2022
    Options

    Just my 2 cents: even though at first I didn’t like Propel (I already had experience, and I was pretty comfortable with Doctrine), the idea of these intermediate DTOs between the persistence layer and the domain logic was really clever and well done.
    The main issue I see (almost daily) is that you must double-check that the data inside the DTO is fulfilled and not null. Otherwise, you might get a null pointer exception… but for this, PHP 8 got a new handy feature: the null safe operator in which you can now check nested values:

    $foo?->bar?->baz()?->boo?->baa();
  • Unknown
    Unknown
    edited September 2022
    Options

    The new DTOs also have a orFail() method wrapper to check for when you know it should not be null.
    This is the better and more clear way of using it instead of ?-> for required fields.
    For optional fields I agree 🙂

  • Chemaclass
    Chemaclass Tech Lead Spryker Solution Partner Posts: 213 🧑🏻‍🚀 - Cadet
    Options

    Right! I usually use the orFail() version, I don’t know why I forgot to mention that 🤦🏼 Also, you can add the strict=true in the XML definition from the DTO at property level or to the whole DTO. Especially good for new DTOs or the ones that you own if you want to ensure strictness to the properties 🧠

Categories