CUTCODEDOWN
Minimalist Semantic Markup

Welcome Guest
Please Login or Register

If you have registered but not recieved your activation e-mail in a reasonable amount of time, or have issues with using the registration form, please use our Contact Form for assistance. Include both your username and the e-mail you tried to register with.

Author Topic: To Route Or Not To Route - The Definitive Guide???  (Read 1012 times)

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 694
  • Karma: +128/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #15 on: 9 Nov 2020, 02:13:26 pm »
Update, now that I'm done talking on zoom, I tossed in a simple "mobile menu as modal" CSS. Should have been pushed to all versions.

I also added the missing static to common.lib.php and pushed that too. I also missed it on the "set" command. Pure hurr-durrz on my part. What I get for coding alone; it only embeds your errors.

And yeah, git can suckle my friend plank. Or even log.

What rolls down stairs, bowls over in pairs, runs over the neighbors dog. It's fit for a snack, it fits on your back, it's log log log...

« Last Edit: 9 Nov 2020, 02:18:43 pm by Jason Knight »
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 694
  • Karma: +128/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #16 on: 9 Nov 2020, 02:19:55 pm »
but you did it in two days I think!
More like 30 minutes this morning to completion, but that's from a bit of copypasta from my own codebases, a lot of experience, and having thought about it all weekend.

Just thinking and planning before you even lay down a line of code helps a lot.

Still that template? Existing code. $_REQUEST and 90%+ of the index.php? Existing code. Everything in common.lib.php except "Settings"? Existing code.

About the only stuff that's fresh is /actions/ as I changed things up a bit there to try and modernize further.
« Last Edit: 9 Nov 2020, 02:21:31 pm by Jason Knight »
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

benanamen

  • Full Member
  • ***
  • Posts: 149
  • Karma: +12/-0
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #17 on: 9 Nov 2020, 02:32:29 pm »
And yeah, git can suckle my friend plank. Or even log.

Fortunately I can still use git on my end. Because I did, I was able to see the exact changes you made at the push of a button in my IDE instead of digging through the current 3,041 lines of code.
To save time, let's just assume I am never wrong.

benanamen

  • Full Member
  • ***
  • Posts: 149
  • Karma: +12/-0
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #18 on: 9 Nov 2020, 03:10:52 pm »
I have perused the code. We are of to a great start.

For the purpose of the discussion I would like to see your implementation of CRUD for one database table, say users for example with just a couple fields like first and last name. I would assume that what you do in structure for the one table would be able to be replicated for other tables unless you say otherwise.

For focus, lets say I wanted you to build a warehouse inventory ERP. An example app would be Netsuite by Oracle (Much to huge for this purpose). Since they do not have open demos, you can take a look at https://openboxes.com/ that provides a free demo for similar functionality of standard features of a warehousing business application. The point being just to point out the numerous entity's that would require CRUD functionality in such an application.

In this example some CRUD entity's would be:

admin/users
admin/vendors
admin/shippers
admin/products
admin/categories

I am not asking that you build all that, just the admin/users CRUD so I can see how your code and architecture can scale to all the other ones. No need to worry about authentication. We can just assume user is logged in if you are in /admin. This "should" be all the code I would want to see to determine how this would scale. Take however long you need.

You learned me up on something new, IIFE. I didnt know about it and that Php can do it. Thanks for the growth bump.  ;D



« Last Edit: 9 Nov 2020, 03:20:43 pm by benanamen »
To save time, let's just assume I am never wrong.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 694
  • Karma: +128/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #19 on: 9 Nov 2020, 06:59:43 pm »
For the purpose of the discussion I would like to see your implementation of CRUD for one database table, say users for example with just a couple fields like first and last name.
Wouldn't username, passwords, and permissions be far more useful?

For focus, lets say I wanted you to build a warehouse inventory ERP. An example app would be Netsuite by Oracle (Much to huge for this purpose). Since they do not have open demos, you can take a look at https://openboxes.com/ that provides a free demo for similar functionality of standard features of a warehousing business application. The point being just to point out the numerous entity's that would require CRUD functionality in such an application.

Yeah... no. That's the type of thing that IF I were to implement, it would NOT use this architecture, it probably wouldn't even be built with a web stack, and it sure as shine-ola wouldn't be web-facing on a standard port or protocol. That's not what ANY of the stuff I presented is even for.

In fact, that anyone would even SUGGEST using it for that makes me wonder if they even know what a website is, or what security is for that matter.

NOT that it seems to stop anybody. THEN we wonder why massive breaches and data leaks happen. At MOST I'd let the web side have access to inventory, but it would be locked down to read only and have to request purchases from a different domain using a token policy.

Also given the wildly different nature of all those different data sets, re-using one code or refactoring it for all those purposes is going to be utter shite. WHY would you even CONSIDER doing that in the first damned place apart from making everything grossly inefficient?!?

No need to worry about authentication. We can just assume user is logged in if you are in /admin.

OH HELL NO? ARE YOU ***ING KIDDING ME?!?

Methinks we come from two entirely different worlds of doing things... and from what you said in that post alone, that world is a "f*** security, f*** efficiency, f*** separation of concerns" kind of place.

Good gravy that's horrifying to even think about.

Sounds like a public utility I did some work for four or five years ago, where they were so desperate to slop the same programming model into solving every problem, their dev's didn't even care if it worked, if their servers had the horsepower to actually run it, much less if it was secure.
« Last Edit: 9 Nov 2020, 07:01:32 pm by Jason Knight »
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

benanamen

  • Full Member
  • ***
  • Posts: 149
  • Karma: +12/-0
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #20 on: 10 Nov 2020, 01:17:54 am »
I fear we may be getting off track. The basis of this whole thread is to see how your router less architecture would scale to a large application. We are not talking about an exact implementation. Examples were provided to show use cases that have various unique sections that would be routed to with an actual router or more specifically for your code, without an actual router to see what issues there may be if any and how you would address those issues.

Quote
Yeah... no. That's the type of thing that IF I were to implement, it would NOT use this architecture, it probably wouldn't even be built with a web stack, and it sure as shine-ola wouldn't be web-facing on a standard port or protocol. That's not what ANY of the stuff I presented is even for.

I was quite clear in the beginning the direction I was heading. If what you have shown is NOT the architecture you would use, then what is? My whole point of discussion is to see how you would design a a large scale application without a router.

You can poo poo the examples all you want but the fact is Oracle bought Netsuite for 9.3 BILLION dollars. The base license is almost a thousand dollars a month and $99 per user. For better or worse, more and more company's are moving IT to the cloud and are paying subscriptions for third party SAAS Applications.

It is also a fact that company's will commission a custom development of such types of applications for their own use.

So to get back on track, if a company wanted to hire you to create such a web based application, are you going to turn it down or are you going to take the job? If you take the job, just how would you handle the application architecture?

All the other things you mention just don't matter at this point. I just want to see how you would do a large application architecture without a router, the whole point of this thread.

With one CRUD table addition to your example I could have evaluated the router-less architecture on a larger scale but now you are telling me that is not how you would even do it. So, the question is simple, just how would you do it?
To save time, let's just assume I am never wrong.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 694
  • Karma: +128/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #21 on: 10 Nov 2020, 05:17:28 am »
I guess ModRewrite issue? can the .htaccess file be being ignored?
The rewrite rule is the core of how "one index" works. Without it, no... none of this will work. You either need it as a .htaccess or placed in your httpd.conf or virtual hosts file.

It's odd for such a central part of Apache would be broken or not installed, even on a local copy. I mean yeah, out of box it's disabled if you manually install it, but it's one of the first things that one usually turns on. Does a "sudo a2enmod rewrite"fix it, or is "AllowOverride All" missing from the vhosts?

This is why for local testing I prefer either running a full VM server install, or an off the shelf all-in-one like XAMPP.
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 694
  • Karma: +128/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #22 on: 11 Nov 2020, 08:43:00 am »
I fear we may be getting off track. The basis of this whole thread is to see how your router less architecture would scale to a large application.
Which would make sense if in the original thread the poor sod wasn't just trying to make a normal website, not some goof-assed full stack web crapplet of the like I would NEVER let a client have in the first place.

We are not talking about an exact implementation. Examples were provided to show use cases that have various unique sections that would be routed to with an actual router or more specifically for your code, without an actual router to see what issues there may be if any and how you would address those issues.
Which to me is circular logic "programmer speak" that much like marketspeak doubletalk, doesn't actually mean anything.

I was quite clear in the beginning the direction I was heading.
Apparently not, or at least what you have said is so far away from anything I would let one of my clients have, that we're not even in the same dimension. In fact, the things you have said and it sounds like you are supporting the idea of, is EXACTLY the type of broken crap I am constantly called in to remove / fix because of broken suppositions and ideas from day one.

I deal with the types of systems you describe quite frequently, and my advice to the client is ALWAYS to throw that **** in the trash and start over with proper separation of concerns.

I have shown -- or at least should have shown -- enough for you to provide a "router" equivalent. If you do not find it such, then I genuinely have ZERO blasted clue what you're even talking about. HOW would it not "scale"? HOW would you implement what I've shown so far?

If you can't provide that, we're DONE talking about "routers" and I'll just start my own thread about this system where I'll add database, users, and possibly a primitive blog.

For better or worse, more and more company's are moving IT to the cloud and are paying subscriptions for third party SAAS Applications.
Mostly for the worse, since as an accessibility and efficiency consultant, EVERY damned client who gets SUCKERED into that type of idiocy has been bent over the log and told to squeal like a pig like poor Ned Beatty on a river trip in the deep south.

Bloated, slow, inefficient, and in general a giant scam designed to rape the suit's wallets. That's what I associate "scam as a service" with. Especially given how most of them seem to assume you're going to make broken borked inaccessible scripttard front-ends with zero graceful degradation plan!

So to get back on track, if a company wanted to hire you to create such a web based application, are you going to turn it down or are you going to take the job? If you take the job, just how would you handle the application architecture?
Most of what you said -- and in fact most of what people are throwing "web applications" at -- is broken trash I would do everything in my power to talk the client out of. I would suggest that most of the stuff you listed be built as native or portable REAL applications, not web applet BS, because most of that has zero business web facing, and that parts that are would/should be isolated to a separate codebase.

... and if they're not listening, they're not worth my time regardless of the pay. Again the "ghetto mentality" a lot of programmers have that just lets people less qualified walk all over them because "I NEED THIS CLIENT". No you don't, you need to do a more professional job so you can charge enough to need less clients like that.

It's why in my consulting I grill them as if I'm the one running the interview... because I am. Why? Because they're in trouble legally or financially, and I'm there to get them out of trouble. I solve problems. If my help's not wanted, lotsa luck Gentleman.


Now, you've got a corpse in a car, minus a head, in a garage. Take me to it.

With one CRUD table addition to your example I could have evaluated the router-less architecture on a larger scale but now you are telling me that is not how you would even do it. So, the question is simple, just how would you do it?
I'm not even sure that makes sense either. Methinks we're butting heads not just in intent and logic, but in language as well.

I'll implement a users system, but it's a great example of where CRUD is a broken mentality -- whilst the admin for example might create, and delete, things like READ -- particularly for login -- has ZERO blasted business even being in the same part of the code and should be baked separate.

That's my problem with most people's CRUD approach, it might be fine for the admin level access.. but "moderators" or "maintainers" should have access to some (update) but not others (create/delete).  It's why having a permission system in place BEFORE you even THINK about those types of controls is important.

Most if not all CRUD implementations I've ever seen just try to shoe-horn one programming model into everything... and in most cases it clearly doesn't fit!  More so since many "frameworks" that do this crap load tons of code that isn't even run. I mean, there will always be some cruft, but these notions of loading so much junk IN AN INTERPRETED SCRIPTING LANGUAGE is so mind-numbingly dumbass. Same failings as MVC and other "development models" that try to force a specific way of doing things even if it is an utter and total task complexity mismatch!

Which is why I'd be interested to see what your equivalent -- even of what's there so far -- might be. If you were building a semi-static site where you're just using PHP to handle $_SERVER['REQUEST_URI'] parsing and glueing template to content, what would your "routed" equivalent even look like?

I've presented code. I've presented a lot of code. I've presented a lot of code other people are now asking me if they can use. (Go right ahead folks). What would you have done differently with this "routing" stuff as the base as a clean-room implementation?
« Last Edit: 11 Nov 2020, 09:00:20 am by Jason Knight »
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

benanamen

  • Full Member
  • ***
  • Posts: 149
  • Karma: +12/-0
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #23 on: 11 Nov 2020, 12:35:48 pm »
Quote
If you were building a semi-static site where you're just using PHP to handle $_SERVER['REQUEST_URI'] parsing and glueing template to content, what would your "routed" equivalent even look like?

In this case, it is likely to use a similar architecture as you have presented. As I said, it is fine for small to medium use case, not to say it won't work for a large application. My end point was to show how messy and inflexible it would be at a large scale.

Before I would show a router implementation of something, I wanted to first see what you would do for a large application and first determine if there are even any issues in the first place going large with it.

From your comments it sounds like you would just refuse a client that wanted you to build a large web application which also makes me believe you have never wrote one. That is perfectly fine if you haven't. Probably most programmers have never written a large scale application. In my 30+ years I myself have only had opportunity to build one such application. It just so happened that I built it with an architecture similar to your example so I know first hand the mess it can become and how inflexible it is at that level. At the time, I also didn't know of a better way to do it.

You can huff an puff all you want about whatever but in the end, the client is King and if they want a large scale web application then that's what you build or you just don't take the job. It is not your (our) decision to tell them how to run THEIR business. You can consult and explain to them but in the end, it is their decision. Trust me, the one large app I did, the client wanted me to do many, many things I highly advised them not to do, but in the end, I had to do it. They are the ones writing the check.
To save time, let's just assume I am never wrong.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 694
  • Karma: +128/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #24 on: 11 Nov 2020, 01:46:52 pm »
From your comments it sounds like you would just refuse a client that wanted you to build a large web application which also makes me believe you have never wrote one.
Survivorship bias / supposition fallacy.

I have written two web driven from scratch over the past 20 years, worked with dozens of them for clients over the past ten years. Pre-web I wrote a lot of really large applications, the largest of which being a double-entry accounting system with membership/development (as in fundraising) and retail side integration.

Everything my experience with them has taught me is that it's a giant mistake that screws over everything. That's why I'm so against the concept.

It's the classic "all the eggs in one basket' mistake so common to "Feature creep". It's like designing in all the problems "feature creep" brings to a project, but instead of them coming in over time they're put in at the start on purpose!

It ends up like the old Groucho Marx skit, "doctor, doctor, it hurts when I do this!"



Well don't do that!

Breaking things up into smaller chunks with clear separations -- particularly isolating a web presence from the rest of the business -- gives you more robustness in the solution, greater stability, and makes it all-around just easier to maintain than one giant oversized codebase.

More so if you take rigid programming "models" and try to force every single task to share that internal working. An overall "director" by way of the filesystem paths being a far simpler, sensible, and extensible solution.

Part of why when people say "but it is harder to scale" I go "daf*** yew sae?"

But usually their idea of "scaling" involves integrating into the web presence or an existing system stuff that has NO business being combined that way.

It's a trap I fell into and blindly did 20+ years ago when I didn't know any better. It's not that I've not done it. It's that I've done it and it sucks.

See what happened when the floor manager at a plastics company wanted to me to integrate all their different motor control software into one unified interface. We did it, it worked, but what a ****show to maintain given the machines on the floor came from 40+ manufacturers and half the damned devices dated to prior to Korea.

Korea... Korea... perhaps you've heard of our war?


You can huff an puff all you want about whatever but in the end, the client is King and if they want a large scale web application then that's what you build or you just don't take the job.
Sometimes taking the job isn't worth the money, if they want something that's going to screw them, or leave you liable. That's a lesson I really didn't grasp until my mid 30's.

Though liability in web development isn't really a thing until after the courts get involved, which is a shame. I often think we need something akin to the "Engineers oath" and a serious talk about responsibility and liability. It would greatly cut down on the number of snake oil peddling scam artists who sucker the suits who just don't know any better. Particularly if legal ramifications for doing a shite job became a reality like it is for architects and contractors.

I suspect my working on MORE than just web development is a great part of why I view this industry with a measure of disgust. There are so many dishonest, disloyal, lazy, sleazy, dirtbags out there suckering nubes and rubes alike with "websites" that aren't fit to wipe with.

It is not your (our) decision to tell them how to run THEIR business. You can consult and explain to them but in the end, it is their decision.
And that's where what I do for consulting differs from normal freelancing. It is my job to explain to them why their existing decisions are wrong, where their plan moving forward is going to fail, and if they're not willing to listen to what I tell them, and do what I tell them when I tell them, then it's in my own best interests not to take the job.

But that goes with the fact most of who I take for clients these days have a very short period of time in which to fix things before litigation goes further. Remember, when big names with deep pockets like Dominos and Beyonce can be raked over the coals by the court system, what chance do smaller businesses or larger ones with leaner margins have?

It's literally the job that organized crime calls a "Fixer".  When things go bits up, get messy, and needs a good cleaning, that's when you call a "consultant".

Take the popular media examples: Winston Wolf from Pulp Fiction, Michael Clayton from Breaking Bad... when John Wick calls Charlie on the phone and says "I'd like a dinner reservation for 12".

"You workin' again John?"

These fictional characters often speak to me in that they are dealing with the same type of self-sabotaging idiots. These people you're there to help, are in some deep manure, but seem to want to just keep digging deeper.

Same thing criminal defense lawyers have to often do with clients. You often have to grill and instruct them. They're the employer, but you're the expert. If they want to not go to jail, they better shut the **** up, listen, and do what they're told.

That's the attitude I often have to take with clients. Do you want the bodies hidden, blood removed, and cops gone, or don't you? Nothing THAT drastic, but there are parallels.

Trust me, the one large app I did, the client wanted me to do many, many things I highly advised them not to do, but in the end, I had to do it. They are the ones writing the check.
Which I count myself fortunate enough to be wise enough and financially secure enough to comfortably say no. I can understand the sentiment, but there are some things that just aren't worth that check.

Again, took me a long time and a lot of abuse to realize that. Probably why I'm so bitter and abusive on the topic. And yes, I am PAINFULLY self-aware of that. I'm like the pit bull who's owner kicked it one too many times, then everyone is shocked at how it keeps going off the handle.

"To win a negotiation you have to show you're willing to walk away. And the best way to show you're willing to walk away is to walk away." -- Micheal Weston
« Last Edit: 11 Nov 2020, 02:11:50 pm by Jason Knight »
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

benanamen

  • Full Member
  • ***
  • Posts: 149
  • Karma: +12/-0
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #25 on: 11 Nov 2020, 03:10:16 pm »
Quote
I count myself fortunate enough to be wise enough and financially secure enough to comfortably say no. I can understand the sentiment, but there are some things that just aren't worth that check.

That's great you are able to turn down work if you desire. It's probably safe to say most programmers can't do that. There indeed were many moments of frustration as the client, despite well explained warnings still wanted to do it their way even knowing it would cost thousands more in the long run.
To save time, let's just assume I am never wrong.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 694
  • Karma: +128/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #26 on: 2 Dec 2020, 09:55:41 am »
The newest milestone should reach the create/update/modify you need to do the comparison.

If not then I GENUINELY have zero clue what you're talking about.
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

GrumpyYoungMan

  • Hero Member
  • *****
  • Posts: 519
  • Karma: +5/-0
    • GrumpyYoungMan
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #27 on: 20 Feb 2021, 04:35:04 am »
Code: [Select]
function module_Load()
{
    $IN = array_keys($_REQUEST);

    if( file_exists("modules/". $IN[0].".php")) {
        require_once "modules/" . $IN[0] . ".php";
    }
    else {
        index();
    }
}
Why would doing routing like this be a bad idea?

** EDIT ** I forgot to say that all non-alphanumeric characters would be REMOVED before the require.. :)
« Last Edit: 20 Feb 2021, 04:51:36 am by GrumpyYoungMan »
Trying to learn a new trick to prove old dogs can learn new ones...

Total Novice have-a go Amateur Programmer - not sure that is the right thing to say... but trying to learn...

benanamen

  • Full Member
  • ***
  • Posts: 149
  • Karma: +12/-0
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #28 on: 20 Feb 2021, 01:10:56 pm »
Why would doing routing like this be a bad idea?

Look up Directory Traversal Attack

NEVER EVER TRUST USER SUPPLIED DATA.
To save time, let's just assume I am never wrong.

GrumpyYoungMan

  • Hero Member
  • *****
  • Posts: 519
  • Karma: +5/-0
    • GrumpyYoungMan
Re: To Route Or Not To Route - The Definitive Guide???
« Reply #29 on: 22 Feb 2021, 06:34:33 am »
Why would doing routing like this be a bad idea?

Look up Directory Traversal Attack
But, what risk is there IF all the non-alphanumerics are REMOVED? so you wouldn't be able to change directories at all via URL?

NEVER EVER TRUST USER SUPPLIED DATA.
I totally get that...
Trying to learn a new trick to prove old dogs can learn new ones...

Total Novice have-a go Amateur Programmer - not sure that is the right thing to say... but trying to learn...

 

SMF spam blocked by CleanTalk

Advertisement