10 common mistakes made during Sylius development
Sylius is a great technology itself. It allows doing great things without much effort in a stable and standardized way. However, like any technology, it is just a tool which if it’s used in a wrong way might generate a lot of business lost you might want to avoid. During years of working with other companies and supporting them in stepping into Sylius and delivering projects, we observed that many common mistakes are being made, which could be easily skipped if only people had more experience or knew something before. Well, now you will know. Sit down, relax and read 10 common mistakes you should avoid during Sylius development.
1. Not using Sylius potential
Sylius being based on Symfony shares all Symfony components and practices. It is ok to use it, however often the vendor has a bunch of things available out of the box which increases the performance of work and development significantly. I.e. instead you decide to write your own Symfony Controller and add some actions to Doctrine Entity events to provide some CRUD operations, read a little bit more about SyliusResourceBundle and Resource Events. The Sylius codebase is very intuitive. Even though something might not be documented doesn’t mean that it does not exist in the vendor. That being said, do proper research before you decide to write your own admin UI implementation (you will find a lot of reusable templates in the Admin & UI bundles) or create a Symfony request event for custom order event listener (state machine callbacks rock!)
2. Reinventing the wheel
We have seen that many people not necessarily know how to use the full potential of open source. Sylius has a lot of plugins available in the community and what’s more, all Symfony bundles are compatible with it. It is much easier to fork a plugin, decorate a service or wrap a Symfony bundle than creating something from scratch, especially if your problem seems very common. Check out the Sylius plugin list and packagist for Sylius plugins and Symfony bundles.
3. Not using a testing environment
Sylius is one of the best open-source projects using BDD methodologies. As your eCommerce grows, it becomes less and less efficient to test everything manually and if you don’t have many tests and CI procedures, things might break up very easily. If you haven’t done it yet and you feel like your app gets more complex, invest some time in learning how to test the behavior of your web eCommerce app.
4. Using themes without a reason
Sylius themes are great. However, it doesn’t mean you have to use them every time when you start a new project. 90% of eCommerce platforms do not require a custom template per specific channel. If you decide to use it, add all assets including node_modules to the theme catalog. The performance of your development environment is going to be much lower due to file search operations that are done under the hood. This affects the performance of your work, which is not great, especially if there’s no reason for it.
5. Using API in a wrong way
Should the integration be done by ERP partner or the development team? The answer might be yes/no/it depends but in our opinion, often third-party vendors responsible for ERP integrations would spend much more time and cover less cases trying to integrate with the Sylius API than an experienced Sylius development team, who could parse XML/CSV files and import it to Sylius compatible database format using Resource factories and validators.
6. Integrating heavy third-party CMS or PIM software when it is not needed
Sylius might not have all the fancy features other vendors do but in our experience, it is not like everyone uses all available features. If you need just the possibility to import/export resources in your product catalog, it doesn’t mean you have to implement a third-party PIM connection – it is much easier to customize Sylius to have it. The same thing with the CMS – having a blog section and a few flexible homepage data blocks or media assets doesn’t necessarily mean you need an enterprise CMS system.
7. Not using channels properly
Channels are very powerful and flexible. They have countless possibilities of combining various settings and extending them to specific needs. Remember that maybe instead of creating a new Sylius instance for a distributor, it might be easier to create a separate channel with different configs and give it another theme, domain and have it maintained easily from one place.
8. Creating resources instead of customizing models
Long story short – being super abstract does not make much sense in developing business platforms. Instead of creating a new relationship between Sylius resources, creating a new entity and combining it all together, it is often much easier to customize the native model to have more fields. It is super easy, fast and produces less code to maintain. For instance, if you want to sell tickets in your Sylius store, it doesn’t mean that you need Event & Ticket entities – creating a new product type will work very well.
9. Dockerizing everything
Sylius doesn’t require many resources to work, especially if you just started a project. We have seen dozens of people spending countless hours adjusting the Docker performance, extending it to add new dependencies, asking questions about performance on OSX, where it could work very efficient on a local environment using just PHP (with built-in webserver), MySQL and yarn. Of course, Docker makes sense for production ready projects but shooting a bug with a bazooka is not always a great idea.
10. Making everything a bundle
Although with Symfony 4 it became less common, still some people do start the work with trying to do everything possible a bundle, trying to be super abstract and decoupling it. As a result, in most cases, created bundles depend on each other and don’t follow any standards (i.e. some bundles follow annotation mappings, some XML), which make the whole code harder to maintain and navigate through, which computes into a great step to an evolving technical debt.