Details
Details
Embedded Files
The google sheet link below has a complex JSON object represented in it. The object is created by a webserver when it gets a request for three SQL calls to be made sequentially and returned to the client for client side GUI rendering.
https://docs.google.com/spreadsheets/d/19hTrBrFB1-emN4QHNtUa56Ea054h7AKUf_eq10TpIDk/edit?usp=sharing
The Challenge -- and your first project for learning Full Stack Development
The Challenge -- and your first project for learning Full Stack Development
This is the MOST COMPLEX scenario for web based software and database calls that exists at this time and it only exists because 1) we are using the "modern" client side GUI control (graphical user interface control) stanards for this and 2) this particular platform we are using (Google Apps Script) has some longer than normal database call wait times when using a google sheet for a database (but makes for a GREAT learning leasson) .
None of this is needed with server side Classic ASP or PHP, but those are 30 year old technologies that most say are obsolete, overtly complex, or hard to secure -- so we are going to show you the "elegant insanity" the modern IT world wants you to believe is "better" with an extra twist of batching calls making it more complex.
LEARNING NOTE 1: this same object control process would be needed for any of the modern JS frameworks so you are learning something that is a universal standard for those. The only difference is they'd only run one SQL call through this gantlet at a time not 3 or more as we are goign to show you how to do.
LEARNING NOTE 2: EVERYTHING you learn here relatd to database calls and data handling can be applied to any other client side or server side rendering platform and thats one of several reasons you should go all in on this edu-tainment opportunity head first.
A Manufacturing Company Production Order Model was applied for Data Management Needs...
We are modeling this complex web request like a Production Order going through a factory floor, or even a Pizza order going from raw materials to finished pie. We provide the raw material ( a SQL template string) and the server parses our template, checks security parameters, injects permissible data, runs the queary through our database system and returns matching records, as if they were the completed product or the pizza coming out the other end of the production line.
REMINDER: none of this is required with server side GUI rendering but that's out of vogue now -- possibly because IT consultants globally wanted to bill companies and governments10x what they would have made otherwise -- so just keep that in mind as you traverse this mess. It does NOT need to be this complex but you can learn so much from this it's worth the journey in spades for that reason alone.
Root Property 1 - Metadata
Our Production Order object has metadata ("meta") as its first "root property". That includes summary reporting for each workstation (parsing, security and recordset creation (aka arrays)), and a final report (complete/incomplete).
Root Properties 2, 3, 4 - Parsing, Security, Arrays (aka recordset generation)
Our Production order object also has three other "root properties" -- one for each production station (parsing, security, and arrays (aka recordset generation)). Each prodution station gets its own reportcard to tell us what transpired and if the work needed at each station was successful. Each also holds onto modfied parts of the SQL string and/or the parts needed to produce the final product, which is a recordset.
But prior to getting into any more technical details, all good Software Engineers would want broader context about the Business Applicaiton - and in this case they'd want a lot more understanding why on earth we are doing this in the most complex way possible via google when there are far better platforms for this. HINT: if you can learn to do it this way here with the most "modern" technology around -- you'll know when and how to use that properly -- and when we show you 20 year old technology that they say is obsolete that will make your life a lot easier for certain applications (with this being one of them possibly), you will then have an appreciation for that which can not be had any other way.
The Business Application - A DNS Hosting System run via a Google Spreadsheet with a Google Apps Script GUI (graphical user interface) that allows your customer and their customers to add, upate and delete the domains they have entrusted you for DNS handling
We are building web based software that does DNS hosting. The software is built for Software as a Service (Saas), and you are goign to be the owner of the entire platform and software. You can setup the system just for your own use, you can set it up to be the only person offering services to others using it or you can set it up to allow others who want to offer DNS hosting to do that for their own customers.
DNS hosting is the decentralized phonebook for the internet. DNS hosting is service that tells the world www.the-poster-press.com is associated with IP address 1.1.1.0 (for example).
Suprisingly, anyone can offer DNS hosting services. There is no registration system required to become a DNS hosting provider. You just do it. You just become a global contributor on that global systems for routing if you want to. It use to be overtly complex technically (and still is but with AI support you can work around that), and cost prohibitive for most. However, we are goign to show you how to do it for under $15/month (your cost) with an AI of your choice as your Technical Support Guru.
DNS Hosting is the same service that Godaddy, Cloudfare, NameCheap, Porkbun and others offer if you reserve your domain through them. We'll likely build out a white label domain name registraton system software next so you can in fact become a domain name reseller with DNS hosting services for your clients, but one step at a time.
Your web based software has the following "pages" / "scenes" / "modules":
login - a page/scene/module that is used to verify a user has rights to login and later issues credentials for their user session. NOTE: this is commercial grade programming under the hood. This was not done as a demo product.
domains - a page/scene/module where a user can view all the domains they have registered with the service and html forms that allow them to add, update and delete domain information NOTE: we will likely disable "update" for production, such that it will only be add or delete, but update is built in now for educational purposes.
zoneRecords - a page/scene/module where the domain owner or a manager can add and delete zone records for a given domain.
forwards - a page/scene/module that allows the domain owner or a manager to add and delete forwards for a given domain.
authManagement/Tech support and other - there will be other modules for you to learn about, explore and add to as you desire.
But first you need to step back to learn more about the platform you will be using because its 1) unique and 2) it was NOT designed for this level of complex use.
GAS (Google Apps Script) Single Page Appliction (SPA) platform Introduction
GAS (Google Apps Script) can be used to create an "single page website" that can include content you retrieved from a google sheet or other database system. They call that single page website an SPA ("Single Page Application"), and instead of using the word "publish" for what you do to get your single page website to show up on the world wide web, they use the word "deploy" (annoyingly). The URL for your webpage will be google.apps.script/{adadasfsd/macro/aiosoajoiaa}. It's not attractive URL, but it can be embeded in an iframe in any website and we believe a subdomain could be pointed to it as well but if its a simple pointer, upon arrival the URL would be the googls.apps.script one.. We are checking now to see if there is anyway to associte the subdomain with it , but that is doubtful. Instead what you can do if you have a googleworkspace account i build a google site, associate that with a subdomain, and then included your SPA via an iframe there. SPA systems are typically designed to serve a single form or a single action. If you are a business owner that has multiple mailing lists people could subscribe to, this is a way your subscriber could update their choices or unsubscribe, for example (so you might be able to dump mailchimp or others like that). And you could make another one that allows people to create trouble tickets and maybe even update them and close them (so you could ditch zenDesk or comparable possibly). If the single page website was data driven, the content for this webpage would typically come from a google Sheet associated with it BUT that's a very limited view. Your SPA can be written to access any google drive related resource and it can make backdoor calls (aka curl, winhttp, etc) to any other website or webserver on the planet to upload or get other information or content.
Our "absurd" use case for a GAS SPA that turns a nice low cost, single point, single page website into a Ferrarri (albeit a bit delicate)...
We are using a complex set of scripts to dynamically change the content on our single webpage to make it look like it's a 10+ page website with complex login, authtentication and backend business system "pages". The average person would not know this was all being done on a single webpage other than for the fact that the URL never changes as they navigate from page to page (which is scene to scene as we have labeled it in our development environment.
Page updated
Report abuse