My server side rendering pipeline: I use nginx to invoke PHP to invoke Node.js to invoke Puppeteer to invoke Chromium.
Client side receives a screenshot of the webpage. They can never steal my super secret HTML and JavaScript code again.
If the whole webpage is a screenshot picture, how to have hyperlinks you ask? <A HREF=browse.php><IMG SRC=page.bmp ISMAP></A>
ISMAP attribute creates a server-side image map. You click anywhere and server receives coordinates: GET /browse.php?10,27 HTTP/1.1
Want a mobile site? Sure.
I can use Selenium to control an Android emulator. The screencast is streamed as MJPEG straight to your device!
Bandwidth consumption isn't a problem. This is what 5G is for.
This is probably the most over-engineered backend stack I've ever heard of... Why are you afraid of serving up regular HTML/JavaScript? Isn't this an extremely expensive operation that results in significant client delay and server cost?
I would also be greatly concerned with accessibility and interactivity since essentially all user actions are static.
What was your purpose in developing this architecture?
Accessibility? We are fully ADA compliant.
There's a 800 phone number on the page in text format. Blind personnel can call this number to speak to a live operator, who would read the page to them. This is a friendlier service than Text-To-Speech systems.
Aside from text-to-speech issues, serving up an image as your webpage creates issues with those who have to use special navigation devices. Also, consider a person with a speech impediment trying to explain to the live operator which page he is on. I'm not trying to sound demeaning, but you really have to consider every use case here.
In addition, you excuse the high use of bandwidth by stating that "this is what 5G is for," but almost the entire world still uses 4G/3G and will for the foreseeable future. Assuming the majority of your users are entirely up-to-date with mobile technology is a major pitfall.
Using ISMAPs for an entire page are extremely archaic and rarely implemented well, but from what it sounds like you have some form of a working website using it. Which brings me to my original question: why don't you just serve the HTML and JavaScript, eliminating nearly all of these issues I've stated and drastically reducing costs for your company and your users?
Ah, so I'm assuming you're a telecommunications company. The 5G makes a little more sense now.
But why are you trying to keep the HTML and JavaScript "super secret"? I don't understand the problem with serving a regular webpage as long as you're not storing passwords and other secure information in the actual HTML/JavaScript code (which you shouldn't be doing anyway.)
I'm too ashamed to let others find out that the page is made with Microsoft FrontPage Express and Flash and ASP and jQuery, so it has to be kept secret.
My server side rendering pipeline: I use nginx to invoke PHP to invoke Node.js to invoke Puppeteer to invoke Chromium.
Client side receives a screenshot of the webpage. They can never steal my super secret HTML and JavaScript code again.
If the whole webpage is a screenshot picture, how to have hyperlinks you ask?
<A HREF=browse.php><IMG SRC=page.bmp ISMAP></A>ISMAP attribute creates a server-side image map. You click anywhere and server receives coordinates:
GET /browse.php?10,27 HTTP/1.1Want a mobile site? Sure.
I can use Selenium to control an Android emulator. The screencast is streamed as MJPEG straight to your device!
Bandwidth consumption isn't a problem. This is what 5G is for.
EXPANDED VERSION: dev.to/yoursunny/the-worst-server-...
This is probably the most over-engineered backend stack I've ever heard of... Why are you afraid of serving up regular HTML/JavaScript? Isn't this an extremely expensive operation that results in significant client delay and server cost?
I would also be greatly concerned with accessibility and interactivity since essentially all user actions are static.
What was your purpose in developing this architecture?
Accessibility? We are fully ADA compliant.
There's a 800 phone number on the page in text format. Blind personnel can call this number to speak to a live operator, who would read the page to them. This is a friendlier service than Text-To-Speech systems.
Aside from text-to-speech issues, serving up an image as your webpage creates issues with those who have to use special navigation devices. Also, consider a person with a speech impediment trying to explain to the live operator which page he is on. I'm not trying to sound demeaning, but you really have to consider every use case here.
In addition, you excuse the high use of bandwidth by stating that "this is what 5G is for," but almost the entire world still uses 4G/3G and will for the foreseeable future. Assuming the majority of your users are entirely up-to-date with mobile technology is a major pitfall.
Using ISMAPs for an entire page are extremely archaic and rarely implemented well, but from what it sounds like you have some form of a working website using it. Which brings me to my original question: why don't you just serve the HTML and JavaScript, eliminating nearly all of these issues I've stated and drastically reducing costs for your company and your users?
We could support TAB key navigation by defining
<AREA>tags over the picture.We send 5G MODEMs to every user.
As I said, the HTML and JavaScript are super secret.
Ah, so I'm assuming you're a telecommunications company. The 5G makes a little more sense now.
But why are you trying to keep the HTML and JavaScript "super secret"? I don't understand the problem with serving a regular webpage as long as you're not storing passwords and other secure information in the actual HTML/JavaScript code (which you shouldn't be doing anyway.)
I'm too ashamed to let others find out that the page is made with Microsoft FrontPage Express and Flash and ASP and jQuery, so it has to be kept secret.
Ahhhh 😂 Definitely for the best then!
Hahah, made my day 🤣🤣👍
Can you show me this site? It's sound amazing :D
It's in internal network for now. 50 Likes on the comment above and I'll put up a public version.
there's a special place in hell for whoever came up without this idea and is also a reason why we can't have nice things, just plain terrible.
Hell has cookies, but only if you visit the hell with HTTP/1.0.
My hell client uses HTTP/0.9, so I can't receive cookies.