@DinisCruz @Azizur @Netlify I think the same properties are true of @GoHugoIO. You can run the site locally during dev (the speed of that makes developing and populating a delight, BTW) or push to a github for an instant rebuild and deploy on @Netlify.
But whatever #jamstack setup is working for you!
@_munter_ @RyanTownsend @Netlify This is handy.
In my case I spotted inbound links from a post from @adactio back in 2009, which used a url format I had on my blog and later simplified.
https://domscripting.com/blog/display/120
I thought I had correctly redirected everything around 2011, but I forgot a pattern I once used.
In my case I spotted inbound links from a post from @adactio back in 2009, which used a url format I had on my blog and later simplified.
https://domscripting.com/blog/display/120
I thought I had correctly redirected everything around 2011, but I forgot a pattern I once used.
@RyanTownsend @Netlify I was just looking at my Google Analytics and seeing some 404 hits.
Currently that type of logging access and reporting is not available directly from Netlify.
Currently that type of logging access and reporting is not available directly from Netlify.
@robmuh @captainsafia @Netlify I like that mindset shift. #jamstack by default (unless something more is *genuinely* warranted) rather than LAMP or MEAN stack by default, even if all the moving parts could have been avoided.
🤔 Spotting 404s on my blog caused by links to an old URL pattern I later simplified. Thought I dealt with that years ago, but fixed it in moments today thanks to @netlify's simple _redirects config:
/blog/:year/:month/:day/:slug /blog/:slug 301
😎
https://medium.com/netlify/10-netlify-features-to-surprise-and-delight-225e846b7b21#7007
/blog/:year/:month/:day/:slug /blog/:slug 301
😎
https://medium.com/netlify/10-netlify-features-to-surprise-and-delight-225e846b7b21#7007
@auchenberg Sorry to hear that you've been having such a tough time. Thank you for sharing this thoughtful and inspiring post. So many valuable lessons in there for all of us. Irrespective of our own health status.
Giant hugs and huge respect. x
Giant hugs and huge respect. x
@magicspon @Netlify It could be that you've somehow got 2 webhooks firing the build.
In your admin, take a look in your Deploy Settings at the Build Hooks
(https://app.netlify.com/sites/{your-site}/settings/deploys#build-hooks)
In your admin, take a look in your Deploy Settings at the Build Hooks
(https://app.netlify.com/sites/{your-site}/settings/deploys#build-hooks)
@Jack_Franklin @Netlify You should probably read further down in the ToS. "An ice cream for Phil" is in there somewhere.
@Jack_Franklin @Netlify Correct. There is a soft limit in the terms of services... but it is massive. 100GB network bandwidth per month on free plans.
https://www.netlify.com/tos/
https://www.netlify.com/tos/
@livmadsen @Netlify Happy to hear it was useful, Liv. Thanks!
Yeah, the form handling and was the first things to make me realise that Netlify was not just a static web host. And that feature combined with notifications and triggers opens the doors to using it for so many things (for me, at least).
Yeah, the form handling and was the first things to make me realise that Netlify was not just a static web host. And that feature combined with notifications and triggers opens the doors to using it for so many things (for me, at least).
@m5 @brianleroux Some more "application-y" sites lend themselves better to client-side rendering driven by user actions etc as you mention. But the more you can deliver "ready to render" html down the wire, the better the perf and the fewer points of failure to worry about.
@brianleroux By the by, if someone was to write an article on how @smashingmag migrated to a #jamstack architecture and used things like https://github.com/netlify/gotrue to power authentication and user sessions...
...would it pique your interest enough to put it in your eyes?!
...would it pique your interest enough to put it in your eyes?!
@brianleroux Yes. That's where a term like #jamstack can be useful. As the ecosystem of static hosting, automation & microservices gets richer, we can go beyond what we thought of as the limits of static sites.
@smashingmag's move from lots of stacks to jamstack on @netlify is a good example
@smashingmag's move from lots of stacks to jamstack on @netlify is a good example
@m5 @brianleroux Heh. Not so much "naming a foundation", as trying to find a convenient term to refer to "static hosting with automated build and deployment infrastructure" – Which is a bit cumbersome to refer to.
Like how "LAMP stack" became a handy way to refer to quite a few moving parts.
Like how "LAMP stack" became a handy way to refer to quite a few moving parts.
@brianleroux I like to think of putting as much distance as practically possible between the user and the complexity. If the f/e can just request static assets which were baked earlier, there are fewer things to break or be attacked.
As Aaron Swartz said in 2002(!) — "Bake, don't fry"
As Aaron Swartz said in 2002(!) — "Bake, don't fry"
@brianleroux No problem. Except often we render on the b/e (or "generate HTML") in response to a request, when we could have done that at build time & de-risked all of our hosting infrastructure.
Not all cases of course, but do blogs really need a DB to reply to get requests? (For example)
Not all cases of course, but do blogs really need a DB to reply to get requests? (For example)
@lucianadrian Although I'm not the product manager.
*Puts hands in pockets and glances over at @phae as she unpacks her belongings onto her desk*
*Puts hands in pockets and glances over at @phae as she unpacks her belongings onto her desk*