Vercel Service Markup
service-markup.vercel.app
service-markup.vercel.app
Overall I think AWS is one of the greatest products to ever come about in my lifetime, though I think one of their greatest fumbles is not getting AWS Amplified more right, they could have squashed both Vercel, Netlify and most other "resellers" like a bug.
It's straight up one of the smoothest developer experiences ever to exist.
I'll point out this is nothing new. Heroku being another (maybe dated) example.
Fly.io isn't perfect but I have to hand it to them, atleast they self-host and work to differentiate their stack.
As I type this the responses are mostly negative, so to balance that I'd like to point out that (1) integration is often undervalued, and (2) nothing prevents developers from using the other services directly, or even creating and managing their own databases, object storage, etc.
However we’ve been badly burned by vercel, netlify and render.com switching their pricing models to user based instead of infrastructure based pricing. We’re migrating to AWS amplify right now, which also happens to be wonderfully integrated into our wider IT landscape with an AWS landing zone, automated internal chargeback etc. It’s 90% the same for our use case and charges only for infra at standard AWS rates.
At this point I’m starting to wonder why it isn’t more popular.
If you don't want to be burned by vendors changing the pricing model on you, don't choose a proprietary stack to build on.
If it's just the number of people who can go in the UI and press the button (when it automatically gets deployed from git anyway), or change env secrets, can't you just have a single admin account and call it "one user"? That could be a single actual person (how often do you change those things?) or could even be a single account shared by the whole team
What am I missing?
Render.com was more lenient in a model like you describe but still we have different people manage different apps and it adds up.
The last time I tried it, most of the "automagic" quickly turned into "do everything by hand if you don’t want to get burned, and oh, we say we handle this use case but, as obliquely mentioned in passing, you really shouldn’t use it. Also, we don’t see the point in having our CLI tool spit anything more than the most generic errors.
What? What do you mean access control? What is that?"
I ended up on Firebase.
And, on my current project, found a single-table DynamoDB to be more reliable and predictable.
But perhaps things have improved since then?
In my mind, this is so basic, that anyone (who is a developer), should be able to do it. But that's just my take.
Vercel is a hyper for-profit and closed platform, is that blocking innovation on Next.JS as an "open-source" framework?
The services Vercel offers have to do with deployment mainly. That's never going to be something a back end or front end framework will help you with directly.
App hosting and deployment has always been a secondary concern. Choice of database, caching, queuing service, etc has also always been a secondary concern apart from a backend/frontend framework.
Then again when they introduced their new Image component for the longest time it would by default use Vercel's paid image optimisation services, eventually it could be disabled but only with some weird and poorly/confusingly documented custom configuration entry.
There are more instances of similar such questionable actions by the NextJS maintainers. I'd rather have seen them just be open about what drove them to do these things.
Of course we are talking more about auxiliary stuff like landing pages, marketing sites, blogs and documentation, not hosting for their core business.
The auto branch deployments on PRs is pretty cool.
Larger companies already have their workflow, compliance etc.
Developer productivity alone is not going to be worth going through audits / signoffs. It doesn't add enough to the product itself e.g. does it beat Cloudflare, Fastly, Akamai, etc in that space? No.
The wrapper is pretty straightforward, I can see how it's a teensy bit simpler to have Vercel manage things for you, but it's not really much easier...
Paying twice the $300k engineers to develop your VC scale app in 2023 using HTML templates or Create React App. Priceless
There are tons of really good solutions to this problem that are incredibly affordable but they just aren’t popular in the React ecosystem which is once again off doing its own thing seemingly detached from everyone else and trying to just fit the React mental model into any abstraction they come across and patting themselves on the back about innovation in the process.
Honestly React is an actively terrible place to have as your center of the universe when trying to build the kind of app you described. Not to say you can’t or shouldn’t use it but it most certainly shouldn’t be where the core is.
Isn't next.js too big to fail? Currently we are trying to define a modern stack for our front-end, and I always thought next.js/react to be the next java -> Perhaps Solid.js is much better (IMHO it surely is) but I probably won't get fired for choosing next.
If not, what would be the alternative? I really don't want to restart with the hassle of configuring a js project from scratch. Done it already a thousand times, and that's a thousand times too many :)
But history has shown that when a framework or backend was sufficiently popular that people did indeed step in to support it. It happened with Node.js itself (which Next is built on) a while back with what was then called io.js, before io.js eventually re-merged with Node.js after the organizational kinks were worked out.
The question is exactly what would happen if it lost its backing, even if it wouldn't outright fail:
- Meta forks it and/or takes over from there?
- Multiple community forks that fracture adoption?
- Stagnation and slow decline as it stops shipping big upgrades and goes into community-maintenance mode?
This is the key. For small apps, it's far more effective to pay the premium to not deal with any DevOps. Once an app gets bigger, it'll make sense to spend more time optimizing cost.
I feel like Vercel is the new Heroku circa 2015. I'm hoping it won't follow Heroku's trajectory, but who knows.
There is a huge amount of difference.
Java is currently backed by Oracle, which has a huge history of staying around (setting the reputation aside for a moment).
Vercel is currently not profitable, raised too much money and is stuck trying to generate enough profit to match that valuation.
Also NextJs is relatively small in the world you compare to.
Javascript <-> Java React <-> NextJs <->
i.e. it sits another 2 layers below.
Without supply side limitations, resellers generally become reduced to commodities over time. This is especially likely with high margin markups, which seems to be the case with Vercel.
Is the integration of Next.js on Vercel really that superior to other platforms?
I know fly also has free dB's, but it really isn't a managed dB service.
Much much better :)
On a serious note, Neon is Postgres and Planetscale is MySQL. Neon has 100% compat with Postgres and Planetscale supports most but not all MySQL. Neon has unlimited storage a single node compute. Planetscale is scale out architecture on top of Vitess.
Neon scales to 0 and more cost effective b/c the architecture.
From what I understand there isn't any logical replication: https://community.neon.tech/t/plans-for-logical-replication/...
This prevents makes it incompatible with our Realtime server and a few other CDC tools like Debezium
(mentioned previously: https://news.ycombinator.com/item?id=33912348)
Also there are some storage plugins that won't work b/c we take over Postgres low level storage.
It’s impossible to give 100% performance compatibility.
1. When scaling to zero, what is the cold start for a request (including the time needed to make the connection)? Do you have benchmarks on this you could share?
2. Does Neon run a pgbouncer service or are customers expected to run their own? Is it better for AWS lambda functions to leave a connection open for the duration of the container lifecycle or open/close on each request?
3. Does Neon support HTTP for doing queries like serverless Aurora v1 does with its Data API? The use-case I have is direct AppSync GraphQL resolvers, not V8 isolate runtimes.
2. Yes to pg bouncer. You have two connection strings with and without it
3. Yes. Check out our serverless driver.
I saw your serverless driver, but it looks like it uses WSS, not HTTP. Is that correct, or is there an HTTP variant as well?
But the lack of postgres was why I never used it. I'll have to give neon a go.
#######
I'm very much starting to distrust these huge companies with infinite product/feature lists and generic marketing-lingo websites.
"Vercel is the platform for frontend developers, providing the speed and reliability innovators need to create at the moment of inspiration."
Seriously?
I want serverless providers that tell me the 4-5 products they offer (Compute, maybe a KV store, maybe a database, maybe some pubsub, maybe a queue?), give me the pricing, and leave me the Hell alone.
I don't want to feel locked into a system promising end-to-end whatever, ones that heavily push a certain framework, and most importantly ones that look like the homepage was designed by a team of sales people instead of a team of engineers.
It's the difference between the Cloudflare Workers website and the Vercel website: Vercel looks like the new-age big-brother con artist, while Workers looks like a utility.
Sorry, what were we talking about? A runaway bill?
#######
This kind of stuff is exactly why I don't trust Vercel. They're selling some """experience""" on top of utilities. This works for Apple in the non-technical space, but for developer tools? Absolutely no chance.
I wasn't going to use Vercel before, but I'm certainly not going to now.
Yes, for hobby projects and proofs of concept you can easily get away with a VPS from DigitalOcean or Vultr (are they still around?), but for anything with super variable traffic? Planning to post a link to HackerNews or ProductHunt? Cloudflare Workers and Fauna keep your site online, the VPS crashes.
Hardening your servers, ensuring proper port exposure, ensuring upgrades and security patches, is thought and time you need to spend. It's hard to keep track of all vulnerabilities in all software. That'd before even talking about zero-downtime deployments and all of that.
Running NGINX and Postgres is not the difficult part that people are avoiding. There's a good reason these services exist.
which is why i switched to kubernetes
There are some things I’ve deployed without much care and yet they’re always as I left them.
I’m not saying there’s nothing to worry about. I’m just not sure it’s all that difficult with some rudimentary (but sane) security practices.
If you put it out there and don't actively secure it it's bound to get compromised - just a matter of when.
Having said that I never said it was "hard" - just something needs to be done. I responded to a comment that took it for granted that you'd automatically be safe on the Internet.
I'm not saying there can't be a problem, but it's so easy and the alternatives (cloud+terraform+ansible+packer et al.) are so complicated in comparison that it beggars belief that people are choosing an "easy" path here.
I much prefer the above, then waking up to my droplet dead on a Tuesday night because I forgot to also rotate my stdout logs.