h a l f b a k e r yRenovating the wheel
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
Save the users form submission and process it later
Most websites are real time - you can edit a record and see the change immediately..or you submit a form and an email is generated immediately. Human error can bring down these websites and apps and systems. Because any thing can put the service offline and the user cannot do anything. When the server is down, nobody can submit requests. I am proposing - it might not be for every site - an approach to build very reliable systems by never knocking the form submitting part offline. | |
This idea is to introduce a layer before the backend of the website whose responsibility is absolutely minimal for simple reliability. The reponsibility of this layer is to store the users form submission for processing later.
When you go to a website you can submit a form and the form server shall
save the form. The response shall be processed later.
Yes that's all it is. Save the users form fields to the database.
This service should do as minimum as possible that would break.
This architectural unit is designed to be changed very rarely
A real backend backend can pick up the data and process it and put it back for display.
https://en.wikipedi...wiki/Message_broker
[pertinax, Aug 09 2025]
https://www.oracle....essage-service.html
[pertinax, Aug 09 2025]
https://activemq.apache.org/
[pertinax, Aug 09 2025]
//That's the goal of the idea - minimise downtime due to change to code.//
https://www.youtube...watch?v=Uo3cL4nrGOk
[pertinax, Aug 10 2025]
[link]
|
| |
So like putting a ticket booth outside the facility sort of? You don't lose your place in line designated by your ticket and entry form if the place blows up? Okay. [+] |
|
| |
This is called a message queue broker. There's a standard for it, called JMS, whose implementations include ActiveMQ, RabbitMQ and HornetQ. See also MSMQ. |
|
| |
Anyway - baked and widely known to exist. |
|
| |
Of course, you might wonder why this well-known tech is not widely used in consumer-facing websites, but mostly in the internal information flows of corporations. The answer probably has something to do with the attitude of the corporation to the consumer. |
|
| |
On the other hand, it might also have something to do with the expectation of the consumer; if you put everything into a queue so that it can be processed later, this would mean that, when the back-end system *is* functional, the system with a queue in the middle would probably be less responsive than the system without. |
|
| |
I do rather like the hack protection this would seem to provide. |
|
| |
You wouldnt expose RabbitMQ or ActiveMQ over the internet. |
|
| |
You could call it a form message broker. |
|
| |
The real backend does the work and updates the frontend server database. But behind the scenes the Devs can do whatever they want - they shall rarely break the frontend form collection flow. |
|
| |
That's the goal of the idea - minimise downtime due to change to code. |
|
| |
To clarify the responsibility of this system is to persist form submissions over HTTP. |
|
| |
Some other process is used to extract forms out of the system by the backend backend. |
|
| |
//You could call it a form message broker. // |
|
| |
OK, and it would differ from an ordinary message broker in that ... ? |
|
| |
//persist form submissions over HTTP// |
|
| |
... in that you're making it depend on a new extension to the HTTP protocol? |
|
| |
OK, that would be a new idea. |
|
| |