
Ask HN: “Multi Page App” design/architecture/advice? - _------------_
For context, I find SPAs overrated, over engineered and complicated as hell to manage for 99% of the projects&#x2F;businesses that use them. Let&#x27;s leave them out and let&#x27;s leave out any specific languages&#x2F;frameworks.<p>I have built a solo side project that makes $XX,XXX&#x2F;MRR and it was done with a very popular server rendered web framework. I am in the middle of building a second solo business, but this project requires quite a lot more performance and after building a prototype using the previous web framework, I have confirmed it would be difficult (ie, expensive) to scale to meet the needs of the service I am building.<p>I have built my own &quot;multi page app&quot; solution from the ground up with another language&#x2F;technology that far surpasses the performance requirements. I&#x27;m at the point where I&#x27;d like to learn more about multi page apps from the fundamental level so I can ensure my multi page app solution has a solid base (security, performance, reusability, etc). Therefore enabling me to use and reuse it for all of my businesses going forward.<p>I&#x27;m having a hard time finding solid resources that discuss security, architecture and other considerations for &quot;old school server rendered pages&quot;. I&#x27;d like to learn a lot more so have a very solid base for my project and future projects!<p>Are there any good resources out there you&#x27;d recommend?
======
eb0la
For MPAs security is as "simple" as:

\- Throwing away everything you don't need. \- Don't trust inputs. Actually
you shouldn't trust anything - not even this comment. \- Since you dont trust
inputs, add a version tag for all you input because your app will evolve. \-
Sanitize all input (ints should be ints, not drop database strings for
instance). \- Assume system/framework/service calls can fail. Log that. \-
Check your routes. Some frameworks expose routes that you didn't knew about
until some bastard asks Googlebot the path to remove some data and drives you
mad for weeks. \- Remember to log all input data for further analysis. Well,
maybe not all; but 1-5% of all (and tell users about that and dont' use that
data for other stuff).

For me Javascript is good for small stuff. Maybe a simple "micro" service that
updates something is good. Angular, React, and friends are too much for me
because I need too much stuff to debug a simple app.

And don't misjudge the programmer time. Some frameworks allow you to start
iterating quickly, but debugging is a nightmare. Also, don't use two (or more)
technologies at the same time that you are still learning. One is fine, but
learning two at the same time makes debugging #@!ng hard.

------
ed_at_work
Eh? There's stacks upon stacks of books and web sites written about
traditional MVC frameworks...

~~~
cimmanom
OP probably just didn’t know the term to search for was “MVC”.

------
beaconstudios
check out laravel. It's a modern PHP MVC framework and it's very easy to use.

------
mackross
Postgres + gobuffalo.io + turbolinks + stimulusjs might work fo your
requirements. IMHO this will scale pretty well for most projects while giving
you enough frontend magic to still feel fast.

