How long should a “Contact Me” form take, on a website?
You type in your message, click the “send” button and …
10 seconds … 30 seconds …
… a full minute, just to send an email?!
Sure, there are a lot of steps to something as simple as sending an email.
There’s the web server handling the request, configuration for the SMTP server, opening a connection from your server to the SMTP server and handle errors for that connection.
The email needs to be formatted, and you have to send the email and wait for a response to make sure it was sent.
All of this happens every time you send an email, too. No wonder it can take thirty seconds to a minute to do something that should be simple!
But here’s the real killer… as frustrating as it is for you, a developer that knows these things, it is 100x more frustrating for the average user that expects your website to work instantly.
No one wants to stick around for 30 seconds or more.
And when you look at the largest, most popular and most used sites around, none of them make you wait around like that.
Have you ever created a new git repository on GitHub?
Perhaps you’ve paid for something with PayPal or on Amazon?
These websites and systems do not process your request in real time. They use message brokers, queues and background processing systems. They respond to you almost immediately while doing the actual work in the background.
Your web server should not be doing the heavy lifting.
Like Amazon, Github, PayPal and so many other services, your application design should use background processing for any real heavy lifting.
I’m not talking about simple select statements from a database, or even basic inserts when you’re just dealing with CRUD data, necessarily.
But any time you have real work to do where there may be a failure from a network or other external resource, you should consider a messaging system like RabbitMQ.
Any time you have work that would significantly delay the response from the web server; any time you have to handle failure with retries; any time you need to know that work has been requested and receive status updates…
It may be a network resource, such as an SMTP service. Or perhaps is an image manipulation and processing system. Webhooks are another great place where your work should be pushed into the background.
There are countless opportunities around you, where you can improve the architecture, performance and maintainability of your software system.
And these are all cases where RabbitMQ and the patterns that it brings to the table, will greatly improve your application architecture and design.
It may seem overwhelming when you first look at messaging servers, though. And that’s understandable.
But you may not realize this:
You’re already working with messaging patterns and message queues. Every day.
If you have ever sent an XHR / AJAX request from a browser, that’s an asynchronous messaging pattern.
Open your email client of choice – there’s a queuing system.
Ask a coffee shop employee to make your favorite drink, and dozens of messages will be sent between the employees and other systems to fulfill your request.
Stand in line at fast food restaurant or a bank, and you’re in another a queue.
You’re already taking advantage of the way the real world works with messages, brokers and queues.
Isn’t it about time your application architecture took advantage of this, as well?
Join my mailing list, below. I’ll send you more information on RabbitMQ and how it can improve your application architecture with messaging patterns.
You’ll hear about success in spite of failed and buggy code, and find resources on how to get started and work effectively with RabbitMQ.