The other day one of my clients met a problem - website that was made by their developer stopped sending letters and putting requests into database. I was invited to help in investigation, so they won't waste days for downtime in ads, until their developer is back to work.
Important note: I'm not judging or diminish the work of another developer - he did his job and quite quickly made exactly what client asked him to. But he had some mistakes, to which I'd like to pay attention. I'd never noticed them if several years ago I didn't make the very same mistakes.
The main issue was that before saving the request to database or at least to logs, the request was trying to send itself to the admin mailbox. At some moment the SMTP policy was changed and the authorization stopped working => the request simply stopped to be sent. The Client invested in ads, leads were coming, filling the form and getting nothing back. Very sad story...
Critical mistakes in forms
Screwing up in forms - is the most expensive mistake in website development. Imagine it - you spend money to advertising, a potential client came, saw the website, liked it. Then the client looks at what you offer and your portfolio, who you are, what is your experience, reads feedbacks.
When the client is ripen he fills in the form and gets "nothing". After such fiasco, not likely someone will stay as a potential client. That is why in request forms as well as in sky-jumping it's very important to be very sharp and careful and always have a backdoor plan if something goes wrong.
I developed a lot of different feedback forms for a lot of different websites and what's more important I did a lot of different mistakes which led to financial and emotional loss for both me and my clients. Time passed and I created a checklist by which we inspect the feedback forms. Every single point of it is written with
If you think you can add something, do not hesitate to text me via what you prefer the most. In case if you agree with some idea, but the real example of a code is missing, also text me - we'll figure it out together and I will supplement the post!
Sending a message right away
I write about it in the beginning of the post. It is a quite common mistake - especially for the beginners, because the client accepts the job not by the code but by the fact of receiving a message to mailbox. And if there's no opportunity to make an asynchronous processing then process possible mistakes and send a message about a lead after saving the request information to database.
In aim of checking make an intended mistake in a code of sending a message, send a request and make sure that the request is received by the database. Yes, the client will see only the error notification, but you for sure will have the contact information.
Absence of error processing
We passed the project to the client and everything was perfect. At some moment unsatisfied client tells us "requests aren't working" (honestly this phrase was my pure nightmare). So I'm trying to understand what is happening and then it occurs that admin changed the password of database and never told anyone, while the ad was running and the requests were being wasted.
It is possible that something goes a wrong way not only with sending the mail. The database can stop working, accesses can change and the disk can be full. Make sure that you completely set the processing of all errors. Moreover, you should sharply know if one or another issue appeared. For me I solved it by sending a notification about an error to a special Telegram chat.
A couple of code lines of message sending "if error" already rescued our nervous system and money of our clients.
Absence of sent forms logging
In previous passage there's a situation when database is dead and the data was lost. But even such an issue can be solved by setting of logging properly. For example, you can make saving logs from POST yet by nginx side, but it's enough to log a request by the side of application's entry point.
Well, you can not make such a convenient search by logs as by indexed DB, but it may rescue you when force major!
Synchronous processing of a form and pending in the interface
The client complained about a long time of form processing. After a quick analysis of a form processing code, I noticed something interesting. While user was waiting for a "thank you for your request" window, on a server side there were happening a lot of iterations:
- Saving a request to DB
- Sending a message to several recipients' mailbox (in a cycle)
- Sending request to CRM
- Sending request to analytical system
- Telegram notification of a new request
All this time a user was just waiting without seeing any movements (even a simple loader). Sometimes there were situations that a user just went away without waiting - in some of these situations a request was not processed completely and the processing stopped which led to a lead loss.
In any forms it's better to come to an optimistic UI and make a user understand that everything is Ok and the processing of his request is really running.
Long synchronous script making order in integrations
The continuation of the previous passage. If in backend there's a very long processing and placing of a form among integrations, then you should use the asynchronous data processing. Long time ago I used Gearman for it, but for the start it can be placing the forms to DB and showing the user that everything is Ok. Then, using cron, launch the forms processing and make needed actions with the integrations.
Extra commented row of a form sending
And in the end I will tell you about the most expensive failure in my IT career. We developed a cool useful request form. The client bought the ads and the whole thing was running well - we saw the referrals to the site, but somehow there was not a single request form left.
We noticed that something was wrong quite late - after a week. It's a very good question to client's marketologists which did not care about the efficiency of the website, but still our failure is more important - we tested a form so many times that extra commented the row of a form sending trying to set UI.
As a result - by the side of a website everything is great - beautiful animation, loader, smooth pop-up window and thank you to the client for filling in the form, which… we were just throwing out to trash...
At Yandex Webvisor the personal data were already hidden and to recover the requests was impossible. We declined last month's payment for this failure , which anyway didn't cover the waste for ads...