Surge – Static Web Publishing for Front-End Developers

Hi, Brock here from surge.

We are having growing pains no question. We have learned lots about our system recently due to some of these incidences. Changes are underway to make the system more fault tolerant and resilient to attacks.

Give us time to make things better and please keep us on your radar.

Brock from surge here. I would just like to clarify causes of our downtime because we like DigitalOcean very much and dont want people to have the wrong idea.

In the 1 year we have been available we have had 3 incidences each for different reasons.

The first was DigitalOcean taking us offline for not complying with a DMCA takedown request. This was before Digital Ocean knew who we were and they expected foul play. From this incident DO reviewed their policies on removing network access to customers and show genuine remorse for the downtime. Like I say we have been very happy with DO and would definitely recommend them.

The second downtime was due to user error on a bad deploy and the system unraveled in a sense. This was a result of several poor things that made the system more brittle than it should be. Somewhat significant architecture changes have happened as a result and more are underway.

Last, and most recently was two DDoS attacks on our floating IPs within days apart. Learning lots still about how to best protect our customers from this. System changes and mitigation plans are being put in place to protect our customers from these sorts of attacks in the future.

Static generally means the assets and code are created and cached at deploy time, without any changes or code generation after deploy. Static sites use the same base code for every user, and interact with APIs to customize the experience. Loading new context-specific code, even if cached along the way, is not generally considered static.

This is part 1 of "the dream", the next step is being completely serverless - that is, not managing your own servers and using hosted services instead. The challenge there is mainly authentication and the security model, but with something like firebase with it's clever security model (or another similar authentication-only service who's name escapes me) you can basically build an app of almost any complexity.

CDN > Auth Service > Message Queue > Lamda-type processing > Hosted DB

No one is suggesting compiling a giant project like wikipedia into a static site and deploying to surge. its about the web client being a static front-end that can be cached and run offline.

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.