Building the next generation web
a16z.com
a16z.com
Hmm .. I've observed that microservice architectures often end up having large deployment footprint, higher usage of the network and a larger surface area for attacks since the "edge" is orchestrating more of functionality..
Does investing in Netlify really warrant such BS bingo? It's a really neat product in its own right.
That alone piqued my interest. For static sites, I've been using a combination of GitHub Pages and CloudFlare, mainly for SSL support on custom domains, since you can't do that with just GitHub. I used Netlify for the first time on a small side project a few days ago, and the experience was awesome. I plan to move all my static sites to them in the future.
For dynamic sites, the idea of a frontend being served up from a CDN and having just an API backend is so appealing. My big concerns are SEO impact and users who have JS disabled. There is prerendering[3], but I need to learn more about how well it really works and what potential edge cases exist. I went to the trouble to implement server side rendering for my day job website (React frontend), but it adds a fair amount of complexity. It almost certainly wasn't worth it for a MVP product.
[1] https://www.netlify.com/blog/2016/07/20/introducing-deploy-p...
Microservices have plenty of downsides. Choosing between a monolith or a bunch of microservices is an engineering decision that needs to be made on a case by case basis, not a rejection of an obsolete architecture.
Goes on to describe deploying static sites. Maybe they meant: by avoiding dynamic server-side stuff we can push microservice routing and integration to the client (trading away some levels of cache for more demand on clients and microservice providing dynamic content)?
[ed: the statement does make some sense if the intent was to contrast static server provisioning with dynamic server (vps/container/PaaS) provisioning]
Features off the top of my head:
* SSL support (through Let's Encrypt), even with custom domains
* A global CDN
* Instant cache invalidation
* Redeploy with one click
* Roll back support
* Custom build commands (whereas with GitHub Pages, you either have to use Jekyll or commit generated files)
* An API
* Preview websites for GitHub pull requests, so you can easily view changes in browser before merging
For sites that persist data, you could still use Netlify to deliver the frontend and then use Ajax to talk to the backend.
Sounds like Netlify is competing either on simplicity or on price, with a (likely temporary) advantage in developer tooling integration.
That's exactly what's wrong with the web today: Too many "web developers" that only know how to point and click. Schools are churning out thousands of people with degrees who were taught to start with the trendy framework du jour, then keep piling on JavaScript libraries until the given problem is solved. The result is a disaster of bloated, conflicting, accessibility-hostile code. But that's OK! Just run it through a post-processor and everything LOOKS professional.
The world doesn't need another Angelfire. It needs more web developers who understand programming.
If anything I think the push button web app publishing has done more good than bad. For example I can't imagine how I would have taught myself to program if there weren't things like AWS or heroku.
We shouldn't make value judgment on the technology because of the bad actors that take advantage of it.
What schools award CS degrees with this kind of curriculum?
That sounds more like what I'd expect from a programming boot camp.