tbarn

The post from the reporters is much more useful for this: https://zhero-web-sec.github.io/research-and-things/nextjs-a...

Nice, someone just shared it with me yesterday!

Just in case you haven't seen it, there's a new free plan with no overages for small projects that you don't want to worry about overages for: https://www.netlify.com/blog/introducing-netlify-free-plan/

I've been working with the team at Not Diamond and trying out the private beta for a couple of weeks, and the routing experience is great. It makes it really easy to use different models and also route based on different tradeoffs. All I had to do was grab API keys from the different LLM APIs and quickly set it up.

I totally agree. If anyone has tried to hire a technical product marketer who "gets it," they will understand there is a really small group of people who have the technical understanding and ability to communicate beyond "X is the best platform." Sometimes early stage companies think their engineers will be able to do it, but often it is not true. They need someone who both sees the internal AND external view of things.

Just wait until December, we will release more information about foreign key constraints on PlanetScale then!

It shouldn't be too many hoops, fairly standard foreign key constraint support. Let us (PlanetScale) know if it is!

The good news on the PlanetScale side is that foreign key constraint support is coming, so in the future this would no longer be an issue.

This number of connections on any of the paid plans should be no issue.

We are working on foreign key constraint support right now. :)

We are getting the chart updated with the pricing now. Thanks for pointing that out.

KubeCon talks should be out in the next month or so and it has more details.

I'd need to dig into the code, but it looks like someone has used PlanetScale with ent before: https://betterprogramming.pub/how-to-connect-ent-to-planetsc...

Did you follow that blog post already?

We are hearing from some users that the performance with Lambda is really good with the new driver. We are going to do some comparisons soon to see if there is more worth sharing on it too. We are going to do a Twitch stream adding it to a Lambda on Tuesday at 11am CT if you are interested. https://www.twitch.tv/planetscale

They still require external connections to be made over HTTP and not other networking protocols. This is part of why this new driver is useful. Before today, it would have been impossible to use PlanetScale directly from a worker without it.

Author here. Funny you mentioned that, we worked with the Fly.io team to get this guide created for just that: https://fly.io/docs/app-guides/planetscale/

(I swear we didn't plan this response.)

basically do this for sites that are on Netlify too.

Agreed, it's a whole new git based workflow. When I was doing full stack applications 10 years ago, it looked similar in some ways, but it was a lot different to me. I also had to care much more about servers. CDN caching is just one feature.

I'm less worried about 3.1 as I was with 3.0. It took years (like more than three) for the move from 2 to 3, and still there's a couple of popular tools that still haven't fully supported 3.0 yet.

Yes! And this is why I wrote the piece. There will always be developer and engineers writing documentation for projects, why not help them be better at it?

Author here. I did mention part of this in the blog post:

The study also found some alternative scanning patterns such as layer-cake pattern, spotted pattern, marking pattern, bypassing pattern, and commitment pattern.

It’s important to note that F-pattern is [negative for users](https://www.nngroup.com/articles/f-shaped-pattern-reading-we...), but good content design can help prevent F-shape scanning.

This is very closely related to the idea of a single source of truth that good docs built with OpenAPI Specification use, which is what the company I work for is built on top of (https://stoplight.io/). There will almost always be docs you need to update manually though.

Author here. This is a great point! Stay tuned for part 3 or 4 in the series where I cover some of this stuff.

Yay! I'm going to try it out later today.

That’s awesome, and I’m super glad this will be useful! This repo is a fork of our of private Explorer in order to move quickly and provide a good experience for Keen IO users. The private Explorer will be for internal bug fixes, new features, and design changes. Some of those changes may rely on specific items in Keen's infrastructure, and need to go through a migration phase to work properly in the open source version.

Good news is those migrations will happen frequently (it is likely that the two versions will usually be in sync). There may be periods of lag after new larger features come out that this open source repo will behind what Keen shows on its website.