On the TeachersPayTeachers.com Engineering blog they've posted a retrospective of what they went through to scale to millions of views per day on AWS using Kubernetes, React, PHP, and Elixir.

Here at Teachers Pay Teachers (or TpT, as we call it) we’ve been in the process of migrating our website from a PHP monolith to a microservice based architecture utilizing React, Phoenix and GraphQL. To date, this migration has delighted our community of educators with it’s myriad of UX improvements. We’re able to objectively measure these improvements with our A/B testing infrastructure which also enables us to gradually expose functionality to broader and broader levels of traffic.

Our product page receives ~2 million pages views per day making it the most heavily trafficked page on TpT (here’s an example page). We decided to use a simple UI refresh as an opportunity to migrate the page to our new tech stack. This post dives deeply into the challenges we overcame while scaling the product page on our new infrastructure!

The post then shows an infographic of their migration and the major steps in the process along a timeline. They also include an overview of their updated architecture, specific technical issues found during the migration and handling server load. They also cover error spikes they saw just after scaling and how they were either able to resolve or just dismiss them as "red herrings".

On the SitePoint PHP blog editor Bruno Skvorc has a post sharing some of his experience contributing to an open source PHP project and the flow he followed to add in a new feature. The project in question is Gatekeeper, an "all in one", framework-agnostic solution for user authentication and authorization.

GateKeeper is a pretty nifty user registration, authentication and authorization library which uses its own database to store and query the user records. This means that it’s completely decoupled from your main app (so you can, essentially, use Postgre or Mongo for your business logic while using a completely different engine like MySQL for basic user records) and easy to tweak and extend.

[...] This post isn’t about Gatekeeper per-se, though. It’s about contributing to open source, and going about the right way to doing it.

He then breaks the rest of the post up into a few different steps in the contribution flow:

• Step 1: Ask the owner
• Step 2: Fork, clone, test
• Step 3: Plan of Action
• Step 4: Just Do It ™
• Step 5: Testing

He includes the code he contributed to the project and where each change needed to be made. He also shows how he tested the new feature and the results of calling his new method to count the number of records for a user, group, permission, etc.

In a new post to his blog Tibo Beijen presents a case study about doing Domain Driven Design in an application using Doctrine2 to work with objects and your database.

Nowadays developing web applications usually requires a flexible process due to changing business logic, shifting priorities or new insights. Besides choosing the right methodology this also requires designing the application in such a way that this flexibility can be achieved. [...] In this article I will show how to implement a specific case using Doctrine 2. Full code accompanying this article can be found on GitHub.

He starts by describing the entities (User/TimeSheet/TimeSheetStatusChange) and how they're defined in Doctrine objects. He modifies them to build in some business-level restrictions like "status changes are only allowed in a certain order". He shows that the domain models presented are about more than just working with the database tables. They enforce rules that effect the flow of the application as well.

In a new post to his blog Justin Carmony shares the story of how he took a platform running with MySQL as the backend (Dating DNA) and made the choice to move to Redis for storing compatibility scores for every user in the system.

We wanted not only for people to be able to visit a profile and see a score, which is easy to generate a score on demand. We wanted our users to be able to browse other profiles sorted by their score with them. This requires us to pre-generate and store these scores, and then later query them. [...] I believe we could have bent MySQL to our will and got it to work, but it would be at a high cost of server power, and that cost wouldn't scale well with our revenue stream.

He talks about some of the other options they sorted through including NoSQL databases or building something completely in-house. In the end, though, they decided that Redis was more of what they needed. He prefaces talking about their configuration with some of the limitations of the tool and then moves into their setup and statistics on its use (complete with pretty graphs). He points to predis as their Redis client of choice for PHP.

Justin Ireland has posted an article to his blog about creating real-time interfaces for your sites using the combination of HTML, CSS and Javascript to connect to a physical interface on the backend.

Physical interfaces such as button panels or remote controls have many disadvantages. Panel controls require a dedicated display for feedback and physical access to a fixed location. IR remote controls offer only one-way communication with limited feedback and can become difficult to manage for multiple devices. [...] We propose a new type of solution to address these issues and bring simplified management and control to a broader market through embedded virtual interfaces.

He lays out the structure of the application, some of the issues that could come up in the connection (using COMET and Websockets). His proof of concept is a connection to a HDMI switch that can be talked to through an embedded controller via a simple interface.

On DZone.com today Giorgio Sironi offers some of his opinions on web applications as enterprise software.

In this article we'll focus on a case study on enterprise software where the porting failed, to list the issues of introducing a web application into the enterprise, and hopefully pave the way for future successes. This is kind of a written retrospective.

He briefly touches on some of the advantages first, mentioning the portability they offer and the fact that it's an "automatic upgrade" for users without having to install additional software. He also talks about a case study of an application that failed but also covers things learned along the way like:

• How complex the domain the application lives in could be (enterprise needs from enterprise software)
• Worries about data portability
• Struggles with the limitations of the browser (like working with large file downloads)
• and, of course, the huge amount of requirements that come with the application just because of the needs of the company

In this new post to Symbiotix.net they take a look at a migration they made taking their site and content over from a WordPress installation into a new Drupal site.

We've been running a small educational non-profit - Edulogos - for over three years now. Until recently edulogos.org has been little more than a Wordpress blog with a few extra pages and an off the shelf theme. [...] We decided it was high time to redesign the site and move it over to Drupal to give it room to grow. Like repotting a plant. "Liefde en substral", as they used to say in our home country.

They talk about the planning stages of the move - what version control they were going to use, which Drupal modules they were going to install - and walk you through the installation and configuration process step by step. They used git and github as their chosen method for deploying the site.

On the Quality Assurance in PHP Projects site, Mike Lively has written up a few thoughts on how developers and development environments should work with testing databases as resources (case study).

Proper interaction with relational databases is incredibly important in most pieces of software. The importance of this interaction is underscored by the fact that many software architectures have at least one entire layer or system devoted to data persistence and data loading. When dealing with critical data in enterprise level applications it becomes even more important to make sure your data is being stored and retrieved correctly.

He talks about a case study on the topic (still in development) that will talk about testing techniques, functionality and how to create the tests needed to ensure your development environment can correctly use the database resource via unit tests and functional tests.

In a case study posted to his blog, Toomas Romer wonders if a PHP script is embarrassingly slower than than its Java counterpart.

The problem. The PHP implementation [of the IP2C library] is a lot slower. Embarrassingly slower. Without any caching the Java version is able to do ~6000 queries per second. The PHP counterpart can push through ~850 queries. The implementations are the same. The stats provided by the author of the library are 8000 vs 1200. So about the same as my measurements.

He details the script, showing what parts the script is taking up the most time on. A large part of the execution is tied up in IO and the fseek/fread and readShort/readInt functions take up a good chunk.

He even tries removing the functions and making things a bit more streamlined. This helps, but still lags behind its Java brother. Check out the post for more statistics comparing the two.

Aaron Wormus has dug up some old notes that he made at the International PHP Conference back in 2005 on the topic of Unicode in PHP that he wanted to share.

He mentions:

• A case study of an online survey generator
• info about Unicoding and UTF-8
• Iconv and mbstring
• and the migration of the application to support Unicoded characters (a nine step process)

And also, a word of warning:

Everything was much more complex than expected. Don't do this because you think that UTF-8 is cool, it's difficult, not well supported in PHP, and don't do it without needing it. Don't do this without a CVS.