Huge kudos to the @letsencrypt team for rapidly collaborating with Netlifyers to help mitigate this.
https://community.netlify.com/t/lets-encrypt-certificate-revocations-3-4-march-2020/9945 https://twitter.com/Netlify/status/1234970055760199686
Wow. You are all great people. ❤️ https://twitter.com/philhawksworth/status/1234908754581295105
Heartbroken for my wonderful @Netlify colleague who lost his home in the Tennessee tornado last night.
Thankfully not seriously injured, but @hazards_of is such a generous person and as member of the support team does so much for others.
Let's help. ❤️
https://www.gofundme.com/f/netlifolk-for-the-padiernos-family
Thankfully not seriously injured, but @hazards_of is such a generous person and as member of the support team does so much for others.
Let's help. ❤️
https://www.gofundme.com/f/netlifolk-for-the-padiernos-family
@denicmarko @scriptconf @youyuxi @marcysutton @simona_cotin @andrestaltz @FischaelaMeer @devdevcharlie That one was a blast!
Good times :)
Good times :)
RT @DavidDarnes: Building a @Netlify Build Plugin: https://david.darn.es/article/2020/03/02/building-a-netlify-build-plugin/
@JonSpeek These are GOLD! I like using @alfredapp, but only tap into a small part of its potential. You're inspiring me to up my game!
More please!
More please!
@TejasKumar_ @ScribblingOn Well shucks! You, my friend, are undoubtedly one of the good ‘uns!
You put a big smile on my face with this thoughtful surprise birthday gift. I’ll get plenty of practice to improve my technique with this apparatus over the next month. Big thanks! 😘
You put a big smile on my face with this thoughtful surprise birthday gift. I’ll get plenty of practice to improve my technique with this apparatus over the next month. Big thanks! 😘
@_baxuz @kentcdodds @sarah_edo I know of business built on offering the skills to manage your assets into a CDN. The unknown landscape upstream can make it very nuanced and tricky.
By removing the moving parts at request time, you open up great automated caching and serving possibilities.
By removing the moving parts at request time, you open up great automated caching and serving possibilities.
@_baxuz @kentcdodds @sarah_edo Thats' a great question!
Caching is hard. Especially when there are many servers or layers in the infrastructure. Setting rules for what gets cached vs what needs to be fresh, and how to invalidate and update on changes is tough.
Ability to cache everything per deploy is a win!
Caching is hard. Especially when there are many servers or layers in the infrastructure. Setting rules for what gets cached vs what needs to be fresh, and how to invalidate and update on changes is tough.
Ability to cache everything per deploy is a win!
@ojrask @sarah_edo @benbyford @joeflateau (The caveat to that of course is that some services might be a company's special sauce, and where they differentiate. Nothing to stop us specialising in our specialism! Often then, its good to build those as an API anyhow)
YMMV
YMMV
@ojrask @sarah_edo @benbyford @joeflateau They're not exclusive that (a site which has zero JS can be JAMstack - automatically regenerated & deployed with content from an API every hour if you want. Still no server)
...but if you thing that language is an easier term to convey the approach... 👍
Naming things is hard.
...but if you thing that language is an easier term to convey the approach... 👍
Naming things is hard.
@ojrask @sarah_edo @benbyford @joeflateau A specialised company whose entire business depends on the quality of their [database|auth|search|payments] service is likely to have more rigorous practices, domain expertise, disaster recover, economies of scale, resources... than the teams I'd put together in-house for those.
@ojrask @sarah_edo @benbyford @joeflateau The consideration of selecting vendors that you believe will stick around is wise.
I'd challenge the comparison of back office complexities though. And also ask what levels of expertise and SLAs most internal teams have in place, who need to assure all these home-made services.
I'd challenge the comparison of back office complexities though. And also ask what levels of expertise and SLAs most internal teams have in place, who need to assure all these home-made services.
@ojrask @sarah_edo @benbyford @joeflateau You should measure this at every step of the way. Careful not conflate JAMstack and SPAs. JAMstack does not have to mean doing everything in a JS app. It's about pre-generating as much as possible, and where appropriate, enhancing in the client using progressive enhancement.
@ojrask @sarah_edo @benbyford @joeflateau It depends. I'd not suggest that this is the architecture everyone should use for everything.
I've worked on projects which benefited from gaining clear separation between services & presentation. Better agility & perf for both teams. And content became portable to more channels
I've worked on projects which benefited from gaining clear separation between services & presentation. Better agility & perf for both teams. And content became portable to more channels
@joeflateau @sarah_edo If you want to kick these sorts of conversations around with more characters...
https://jamstack.org/slack
You can use more characters and there are more characters there.😌
https://jamstack.org/slack
You can use more characters and there are more characters there.😌
@joeflateau @sarah_edo Right! Once you start having to handle your own cache management, things can start getting lively in my experience! That's one of the areas I try to design around or use some service to do that for me.
@joeflateau @sarah_edo ...but it is a conceptual model, not a religion.
And I think that serverless and JAMstack are the best of friends!
And I think that serverless and JAMstack are the best of friends!
@joeflateau @sarah_edo Yeah, I think Id say so!
You serve your views pre-rendered, populating those at build time. And then use some craft serverless fu to service requests for missing assets directly from the source while you back-fill. Right?
One could argue that serverless isn't JAMstack...
You serve your views pre-rendered, populating those at build time. And then use some craft serverless fu to service requests for missing assets directly from the source while you back-fill. Right?
One could argue that serverless isn't JAMstack...
@joeflateau @sarah_edo Sounds like that starts to blur the edges 😀
I myself have used a lambda to render routes _as a fallback_ while those new routes were being generated. Then they get served from the CDN.
I think of any server-side request-time render as not jammy. But can be a great complement
I myself have used a lambda to render routes _as a fallback_ while those new routes were being generated. Then they get served from the CDN.
I think of any server-side request-time render as not jammy. But can be a great complement
@ojrask @sarah_edo @benbyford @joeflateau Yeah, your UI's back-end can be a simple file server... but better still an optimised CDN. With ALL assets being served from there. This makes dev/deployment way easier to manage.
Then thanks to the decoupling of services through APIs, internal or 3rd party APIs can enhance.
Then thanks to the decoupling of services through APIs, internal or 3rd party APIs can enhance.
@joeflateau @sarah_edo I think of pre-rendered pages as part of what jamstack is. Jamstack enjoys the benefits of pre-rendering as much as possible (in some cases 100% so... yes) and then being able to serve directly from a CDN. Then if needed, using JS to enhance pages with APIs (browser/content/etc)