# (Routes & Methods & Search Params) vs. (Route-focused Data Fetching)

(just loose thoughts for now, we can organize later)

### Ultimately both are just abstractions around a server handling requests

## Route-focused:
* Purely GET requests
* The URL is all of the data
* Easier to share links (contrast that with how difficult it would be to share a link that required some action to trigger a post request to some endpoint to replicate the view)
* Great for lots and lots of content, much of which is public anyway
* Doesn't have a set convention (like key=value& ) so more freeform ways to pass data without pre-conceived notions about how to structure it
* Seems like e-commerce fits really well with this. Also Social media. News sites. All are highly content-driven, LOVE when their users share links to their sites - and want to send them directly to a _very specific part of the site_ - and tons of the content is public in nature
* URLs have a much smaller limit on total size of request than the request body, right? 🤔 Can't remember off hand
* Outside servers that want to communicate have a much less standard way of doing it (they could stringify JSON and send as a request body no problem, but any custom serialization schemas we use for the app internally could be a big barrier)
* Hooks sent by 3rd parties are often rigid. "Must be a post request, here's how **we are going to** send the data." can't really change that.
* At the project level, quickly turns into configuration-based routing but under the veneer of file-based routing. Double-edged sword I think
* Dumping the kitchen sink into the URL has some security implications

## Routes & Methods:
* All requests are possible
* Fits much more neatly with REST design and expectations
* Doesn't preserve the same easy sharability of links except by using search params
* Search params are a familiar convention. Blessing and a curse. Devs are more readily used to them, but may be more easily tampered with. Like by devices (thinking about Apple with its recent anti-tracking stuff)
* Keeps file-based routing more clear. More descriptive from the top-down. The other approach would naturally find itself using lots of catch-all routes which means you need to now go see the implementation to understand the depth of what it's for.
* Search params have the flexibility of order not mattering. Just key-value pairs. Route paths naturally build a hierarchy, unless it's just a ton of catch-alls (which could get frustrating to maintain, inaccordance with previous bullet)
* `shirts/[productId]/[color]/[size]` sort of implies that size is a subset of color when it's not.
* `shirts/[productId]/[...options]` can level that hierarchy but now you've lost of the top-level surfacing of the details. Gets funky when you *do* then need a subset of `[...options]` but it's already a catch-all now
* But search params are not surfaced as easily in the project. `user/[userid]` lets you know right away what you might send. having to check `user` to see that it uses a search param is annoying
* More sensible for in-place, web _app_ type of sites. The url may need not change much for any valuable reason, but user just needs to interact, have server respond, and have UI update accordingly. Having the familiarity of various HTTP methods to call would probably just help with the comfort level of average dev

_The more I'm thinking it through, it's pretty clear we'll need good support for both. The pros and cons are very mixed and quite dependent on the industry domain._

# Let's think of example apps and then picture trying either way when building them

(not thinking it through yet, just laying out kinds of apps)
* Administrative dashboard to manage staff
* Local coffee shop
* Sports betting site
* Data visualization dashboards
* Online shoe store
* Simple link shortener
* Twitter clone