When building a full fledged web app I prefer JavaScript - when I do want to do more in Python I find Streamlit is a perfect fit for Python native, low code, but not trying to do too much
Thought the same when I read - and honestly I think the larger growth vector for OpenAI is their B2B and API potential. But good product leaders can span both, but curious none-the-less
Given that Alpaca strictly specified that they released purely for academic use and any commercial use was prohibited given doing so would violate terms of service, I don’t see this as viable for use. Looks like marketing gimmick
saw this on reddit. ended up watching for 45 minutes. yes its mostly nonsense but its understandable and with twitch chat, opens the imagination. can absolutely see ai-generated content on the horizon.
right now the state of streaming there is a show for every interest. can see a world there is a show for every individual
Wow - these types of changes make it hard to justify using Netlify for static hosting if your contributing team will even possibly grow. Once you get more than 7 contributors for the codebase you have to switch to an enterprise plan ($$) is a scary cliff. What fundamentally changes in hosting costs when I get that extra team member? The pricing structure feels very illogical - are they really adding that much more value in hosting my site just because I have more contributors? Everyone knows exactly what this is - a desperate attempt for cash flow.
It also seems like an unconscious acknowledgement that their add-on services (form handling, post-processing, identity, analytics, auth, etc.) are woefully inadequate in some cases and uncompetitive in others. $20/mo for form handling beyond 100 submissions? Okay, maybe. But the feature set is so bare it's laughable. There's minimal to no customization for notification emails, no confirmation emails, and their post-processing for form detection will bring the speed of your build pipeline to its knees on any serious site. On one site turning off post-processing yielded a build time reduction of more than double the actual build time of the site.
Not to mention the fact that by foregoing any concept of a server and forcing everything into some flavor of lambda they've created a scenario where every framework with any such functionality requires open source shepherding to function on their platform[0]. At best they've diluted their initial mission and at worst they've created an unmanageable mess. They can't even make Next.js work on their platform without causing what should issue 404s to return 500s instead[1]. The SEO implications for that are a potential death sentence and that issue has now been open for five months.
I was very optimistic about Netlify at the outset, and it worked great and still continues to work great for our test cases where we've deployed individual LPs. Where the pain seems to start is anything above a thousand pages or more, which is also coincidentally where the stakes start to get higher. I don't know how they could expect anyone at an enterprise or growing business to seriously scrutinize this platform and view it as ideal with that in mind.
Yeah, and they can be stupid expensive for small side projects with a handful of contributors. If you want a Netlify site with a background function that serves 10 visitors a day with 3 people occasionally logging in or pushing code, you pay $57/mo to execute $0.0001 worth of Lambda functions. Maybe it's worth it if things take off, but before then you're paying a lot for very little. So, you host on a DigitalOcean droplet or directly on AWS, and bear a migration cost if you were to choose Netlify as soon as things start growing.
If the value proposition isn't for you, then don't use it. You can't focus on a single feature while ignoring all the others. (ie - your 3 people team would pay $300/mo if you wanted SAML)
> are they really adding that much more value in hosting my site just because I have more contributors
... Yes? Netlify removes a lot of DevOps overhead, and the more people you have working on a site the more DevOps overhead it's eliminating. Imagine, for example, you have non-developer contributors like technical writers or marketers. Netlify makes it easy for them to see local and branch previews that exactly mirror production.
I think this disconnect is from thinking of Netlify as just hosting. (And this is a perception they've been fighting for many years -- rather successfully.) When you realize they're a dev workflow and collaboration tool, this pricing starts to make more sense.
> a desperate attempt for cash flow
It's not an unreasonable thing to do in the current market.
Before this pricing change, I paid them $99 a month + bandwidth + build minute overages, with the sort of tacit understanding that until and unless my users need to log in to the site, they aren't billable. After this pricing change, all my developers get a login that they don't need or use, and my baseline price goes from $99 to $693.
I technically gained functionality in that developers can now log in and see why their builds failed, but with the rare exception of something being broken in the netlify build image, there is zero utility in that. They can see any of the errors that would be failing the build by looking in their local developer console to see what the linter complains about.
Yes, preview and feature branches are handy, as is the ability to rollback to a previous commit's deployed state, but that feature doesn't scale with "number of team members who have access to the repository" nearly as linearly as the pricing model wants it to be.
Beyond that, I moved from the $20 a month plan to the $99 a month business plan because of the premium edge network before they imposed a $99 per month per team member pricing change (so really I went from $20 a month + overages to $700 a month plus overages) only to see that now they want me to upgrade to the $3,000 a month enterprise plan to get the edge performance I signed up for.
In addition to Vercel, I would also suggest considering Cloudflare Pages. Although Vercel’s platform is more mature, CFP is slightly more framework-agnostic while Vercel, understandably, is a bit tilted in favor of Next.js development. (Of course, if you’re already a Next.js shop, that may seal the deal in favor of Vercel.) Both offer the same high-quality CDN performance at all pricing tiers, including their free tiers.
I think trying to justify their pricing on hosting alone misses their point. Nothing fundamentally changes in hosting, probably in any environment. However, the development workflow does change with extra team members. Netlify's tools for collaborating are fantastic. I think that's the value they're pricing.
I think the main issue I have is a lot of that workflow is no longer as differentiated as it was - definitely not to justify the premium they are asking. Cloudflare, AWS, and Azure now all have similar workflow offerings. I have choice now where I didn’t as much before, to where I’d be unwilling to swallow this premium. Maybe there’s value here I’m not seeing, but I’m not seeing it
We are actively moving away from netlify for that reason- we have a mostly stable website that maybe sees 10 deploys a month, but usually from 10 different people. I just can’t justify an enterprise account for that.
Great post. Nothing flashy, walks through basics and principles. I do love the simplicity of REST and unless you need some graph would recommend folks stick with it over GraphQL
When I looked into implementing GraphQL, it didn’t seem to require the data I was serving be a graph. I found the big difference with REST was that GQL allows the consumer to define the properties returned rather than having backend engineers have to think through every use case. It wasn’t enough of a killer feature to risk the timeline on that project, so my experience is limited.
That was my initial thought too, but looks like these lambdas have to derive from a specific set of Lambda base images. Cloud Run lets your publish ANY docker container from any base image. So this feels much more like a deployment and development feature of Lambdas and not "run any container as a Lambda"
Worth noting this isn't bring any application and publish as AWS Lambda, but rather build from a specific Lambda base image and package your Lambda code into it. Fargate likely closer to what you are describing here
You don't need to build from a Lambda specific base image - you can use (nearly) any base image you choose. Your application just needs to implement the Lambda runtime API, which we provide clients for in multiple languages.
reply