Introduction
In December, we continued with our intensive work on the framework orchestration possibilities, implementing feedback from the community and performing one of the last huge backward compatibility breaking refactorings before the upcoming stable release.
Google Cloud Platform deployment
Shopsys Framework is dedicated to the development of large e-commerce solutions (or companies already on their way towards growing into this bracket). For such projects, it is vital to handle heavy traffic peaks, and we believe that proper cloud deployment is the right solution for them.
The last few months, we have been working thoroughly on the possibility of deploying Shopsys Framework to the Cloud solutions while defining the infrastructure as a code. Therefore, any change of the architecture is now performed as a commit to the Git repository and we are able to test it. We adopted suitable tools for that, such as:
- Terraform to define testable infrastructure on Cloud so you do not need to click it via GUI every time.
- Kustomize to differentiate your environment settings.
- Kubernetes for orchestration of your application and management of your Docker images.
For more information see the new section “Orchestration” in our docs.
Configurations of all the necessary tools mentioned above are defined in a new repository shopsys/kubernetes-buildpack in the form of Dockerfile. Then, in your project, you’ll find prepared shell scripts and Kubernetes manifests that use the Docker image of the buildpack and enable deploying your Shopsys Framework project to the Google Cloud Platform. You can see all the implementation details in the pull request #633.
By leveraging our prepared solution, you are able to deploy your project to the Cloud within 15 minutes. You do not need to configure everything from scratch on your own, you can save yourself around 400 hours of development, and you have a solid background for building your project that can be autoscaled with Kubernetes on Cloud.
Refactoring of Service Model Layer
The first stable release of Shopsys Framework is fast approaching. We want to have the model layer of our framework as clean as possible by then so implementing new projects is as easy and intuitive as possible.
We decided to get rid of a whole layer of our model — we removed all the classes with the *Service suffix. The original purpose of such classes was a separation of business logic, however, it was not followed strictly and the unclear concept was not easy to explain to novices.
So, some of the *Service classes were renamed to describe their purpose better (e.g. DomainService was renamed to DomainIconResizer), some of the *Service classes were removed completely and the logic was moved into entities in accordance with the domain driven design. In addition, the former nomenclature is not causing confusion with Symfony services anymore.
It was a huge backward compatibility break (see the “Upgrade Instructions for Services Removal” article or all the related pull requests — #627, #652, #657, #670, #671, #672, and #691) hence we wanted to do it now, in beta phase, before the stable is released.
Improvements from community feedback
We really appreciate any kind of feedback from our users regarding how to make the framework better and fit their needs. The first beta version of Shopsys Framework was released 3 months ago and we have been collecting feedback from project developers since then. In the last month (i.e. since the last release on 28th of November), we have managed to close 21 issues and accepted 5 pull requests proposed by the community. We would love to thank all the contributors and reporters!
We also improved our upgrading instructions. We have our own demoshop built on Shopsys Framework that we upgrade with every new release. We also gathered and implemented the feedback on the upgrading instructions from the projects that are being built. Thanks to the new form of the instructions, adapting new versions of Shopsys Framework will be faster and easier. To see all the changes made, check the pull request #699.
Last but not least, we extended our documentation with new information:
- Differences between installation of project-base and monorepo
- Translations and how to use them on Shopsys Framework
- What are data objects good for
- How to display generated SVG icons
- Cookbook for basic data import
New features
Based on our experience in the e-commerce field, we implement new features that are convenient for project developers. The list below mentions the most interesting of them:
- Frontend performance boost (PR #703) — by using a customized (smaller) jQueryUI library, moving most of the javascripts to the bottom of the page and proper setting of gzip compression, based on the Google Page Speed Insights, we significantly improved performance — on a desktop, we achieved a score of 99/100 points!
- Prefixes for Redis and Elasticsearch (PR #673 and #651) — these are very handy features when you need to use multiple instances (i.e. stages like development, pre-production, etc.) of your project and want to save some server resources; you can connect all of them to the same instances of Redis and Elasticsearch.
- Generalized AJAX pagination (PR #579) — there is a new generalized frontend component that can be used for dynamic pagination of any entity using “load next XY items” button. We added a new cookbook “Adding Ajax Load More Button into Pagination” to our docs so you have the instructions on how to do it.
- Debian instead of Alpine for php-fpm Docker image (PR #702) — despite the fact it is larger, we decided to use Debian as a platform for our php-fpm Docker image because it is better known in the community, its commands are easier to understand, and it provides more features (e.g. it is able to connect to MSSQL databases, unlike Alpine we used before).
