10 common mistakes made during Sylius development
Sylius is an excellent 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. They could be easily skipped if only people had more experience or knew something before. Well, now, you will know. Sit down, relax, and read ten 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 or create a Symfony request event for custom order event listener (state machine callbacks rock!). You will find a lot of reusable templates in the Admin & UI bundles.
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 packages. When you have any problem with plugins, feel free to contact us.
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. If you don’t have many tests and CI procedures, things might break up very quickly. If you feel like your app gets more complicated, 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 whenever 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. Your development environment performance is going to be much lower due to file search operations that are done under the hood. It affects the performance of your work, which is not great, especially if there’s no reason for it.
Do you need help with Sylius implementation? Leave your contact information and I will find a solution during our FREE consultation.
5. Using API in a wrong way
Should the integration be done by the ERP partner or the development team? The answer might be: yes/no/it depends. In our opinion, often third-party vendors responsible for ERP integrations would spend much more time and cover fewer cases trying to integrate with the Sylius API. An experienced Sylius development team, who could parse XML/CSV files and import it to Sylius compatible database format using Resource factories and validators, might be a better choice.
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. 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. In essence, 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 mighty 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 more comfortable with customizing 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 efficiently 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. It makes the whole code harder to maintain and navigate through. In fact, it computes into a great step to an evolving technical debt.
It is easier to avoid mistakes during Sylius development when you know about those most common. We know that it is not possible to eliminate all mistakes but you can limit them and then Sylius development will go easy. If you need advice, go to this page and contact us directly or use a contact form below.