@philhawksworth
Developer Experience, Netlify
Nothing here yet.
Nothing here yet.
No blogs yet.
Nodding along pretty aggressively to Sarah's reply. For me, one of the biggest challenges is in choosing what to focus on first. It feels like a really exciting time not just for Netlify, but also for the JAMstack as a category, which is wonderful, but I sometime find it hard to decide which opportunity to focus on. Especially when they are all so compelling.
In addition to Divya's post, you might also find this example of a serverless function which acts as a proxy, adding a secret API and calling a service. https://github.com/depadiernos/token-hider-inator I find these useful to dip into... a wide range of examples and references gathered here. https://functions.netlify.com/examples?search=proxy
Another thing I noticed here from the moment I joined, is that the team works very hard to be thoughtful about what goes into the experience. That is to say that everything that appears in the UI has really had to fight for its place to be there. And to justify how it is presented. The result is something that I was enjoying long before I joined, and that is a clear and seemingly simple UI. I observed really painstaking rigour in the team's efforts to maintain this, and to not let things creep in which might feel fun or satisfying to those of us who work on this and see it every day, while introducing noise or distraction. It's interesting to me to see how much effort goes into keeping something feeling simple.
For me a typical day starts with some correspondence catch up. Since I'm based in the UK and most of my colleagues are in the US, they have been busy working and talking while I was asleep. So I like to try to catch up on what was going in email and on slack while I start my day and slurp my coffee. I also spend some time seeing what has been grabbing people's attention on twitter (which is usually rather delightful as people using Netlify often seem enthusiastic or full of valuable ideas). Then I dip in to https://community.netlify.com where there is also often some useful conversation or some people I might be able to help out. Most of this is possible because of the head start I have on the day. As the US wake up, my time gets to be more in demand so I try and get my head down on some writing or technical exploration before people get up if I can. When the US is awake I'm more likely to have some project meetings, 1:1s or team catch ups. As a distributed company (50% remote, 50% in SF) we're mindful of making connections between people even when they are remote. So we put some effort into that too. Another big part of my job is attending or speaking at conferences. This often involves travel which, while I love it, does eat up time and quickly make everything I've written so far in this answer a work of fiction. then it can be a scramble. Divya mentioned our weekly team planning, but beyond that, I use Things to help me list and prioritise the things I personally want to achieve that day. It helps me to get the list out of my head and onto a screen somewhere. And it gives me the chance to gleefully check things off.
Also worth keeping in mind that if your site is html (rather than a self contained, JavaScript Single Page Application), then each navigation to a new page, will be making a traditional HTTP response, and be met with the lates resource held there. So it's true that Netlify deploys are atomic, navigating to a new URL is a fresh request, so you'll not be navigating around a "stale" version of the site. So this situation is limited to SPA's I think, and those often have mechanics to indicate something like TTL or similar to safeguard from long running stale content.
This is a great example of some tooling to export content from Medium over to something more ...JAMstacky. I've seen a few similar to Mathieu's excellent project emerging, and something I really like is that even though many of them might target a specific static site generator or framework as their destination, they typically take the first step of grabbing the content from a Medium export, and formatting it into something suitable for a static site generator to consume. Once content is extracted and help as markdown files, or xml, or json, or yaml... there are wonderfully broad possibilities for the static site generator you might wish to use to consume them. Data portability FTW!
Ha ha. Me too! As a stretch goal. The other thing to mention is that we have a wonderful team of engineers, designers, documentarians... all working together to ship these features. Those of us on this AMA are often in the position of contributing to that work, but also fortunate to be able share the information about the work of a larger, and really rather gifted team. (it's a fun part of my job to be sure) The product team is really well organised and function brilliantly together. And we're in a happy position of being able to release many incremental improvements over time to keep pressing forward. And we also use a time machine.
This is is a great question. But not a very simple one to answer. It’s actually been a topic of discussion a number of times recently here with the founders. Let me see if I can give a good summary... Firstly, since the Netlify platform (the hosting platform and the build infrastructure) is built to sit across as many as 7 different cloud hosting providers (including those you mentioned above) and gracefully balance across them, it is difficult to give very specific details about the exact service on which Netlify sits and the resultant carbon offsetting in place. As you mention, many of those cloud providers give some level of carbon offsetting themselves, but they each differ, as does our usage across them, so good data is tricky here. However... We care a lot about this issue too, and have been exploring the possibilities for doing real, effective carbon offsetting not just for our hosting infrastructure, but also for other aspects of our operations like long haul travel etc. There are lots of schemes which allow payments to be made towards carbon offsetting. But our research has not shown that these are often as effective as we’d like. We don’t want to just pay a fee and feel better. We would prefer to make a substantive effort to truly offset. We are exploring a number of possible options for this at present, but I can’t currently give a more definitive answer than that, I’m sorry to say. Our investigation into this is ongoing. One other thought... I need data data to back this next statement up, and perhaps this is something we might put some research into at some point, but the model of building a site only when it’s code or content changes, and then serving the static assets which result from that build should be far more energy efficient than serving a site with a traditional model. Particularly at scale and under load, the JAMstack model where static assets are served should require far less ‘work’ than having a dynamic back end which must scale to perform more and more logical operations as load increases. I hope we’ll be able to give more information about all of this in future.