Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Done this many times, in fact currently I deploy to S3 (look for "static website") and the static site interacts with an API.

This is the whole point of JavaScript frameworks to me. And definitely not trivial stuff.



> This is the whole point of JavaScript frameworks to me.

What does it matter if your front endpoint is on S3 or being served by your own web server? Delivering static assets isn't that hard and you don't solve a lot by hosting the front end point of your app on S3.

Your bottleneck is way more likely to be your API long before static asset serving is a problem.


I understand the architecture you are describing, and I don't think that it is trivial. My confusion is over what really constitutes a "fully static" app.


IMO, static doesn't have to have a correlation to being simpler.

HTML, CSS, JS, and media are all static assets but you're welcome to request whatever datatypes you want behind the scenes via AJAX and/or CORs.

The benefits are entirely in the rendering speeds of an optimized web server and cache layer. Also, this approach plays extremely nicely with CDNs.

Difficulties can arise if you have to begin dealing with versioning of your assets to avoid cache invalidation, but that's what a proper build process can add to the static site.


Is the performance/simplicity that much better than setting up Cloudflare yourself?


In this particular case, my understanding is, the fully static code is just the frontend, in other words to not render HTML from your Web Server to the Browsers.


Indeed this is how I have build all my projects for the last two years. Currently I am building a platform to easily deploy a graphql api called https://graph.cool




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: