What is Reddit's opinion of
Vercel?
From 3.5 billion Reddit comments
100 reviews of this app found across Reddit:
WAIT... so they closed a $102M round in June:
https://vercel.com/blog/series-c-102m-continue-building-the-next-web
and now a $150M round?
https://vercel.com/blog/vercel-funding-series-d-and-valuation
That's nuts!
It indeed is for authentication, localization, bot detection etc.
It indeed is for authentication, localization, bot detection, etc.- https://vercel.com/features/edge-functions#examples
I'm not an expert by any means and can't answer all your questions but I'll say that I think if it is critical the data is as fresh as possible, SSG/ISR is inefficient and you should be using SSR. If the data is coming from a CMS and presumably not changing every second, your revalidate should be longer... and ideally you should use deploy hooks to integrate with your CMS and manually trigger a build when you change/add content.
Vercel has worked very well for us for free, and on top of it provides a full frontend CDN deployment and API serverless deployment automatically on every GitHub commit—it will also allow you to do so for pull requests so you can have separate deployments on commits not on the master branch, say, for staging and development. Super easy to set up as well.
Our pricing is more flexible now and we updated our pricing page to make limits more clear (like 1TB of bandwidth for Pro). We're researching other improvements and I'm open to feedback (feel free to DM me here or on Twitter).
We believe the future of the frontend is "at the edge", meaning it's as close to your customers as physically possible. The only way to beat the speed of light is to be closer. Frameworks and tooling should be designed with this constraint from the start.
If you're using ISR (https://vercel.com/docs/concepts/next.js/incremental-static-regeneration), you can have the page update at fixed intervals.
Assuming the typo is content and being pulled in from a CMS or something, as opposed to being part of the code itself. If you're changing code, you're redeploying.
Or at least the real-time notifications part of your backend. Firebase Realtime Database, Pusher, Ably, etc, can all be providers for just the realtime parts of your application.
https://vercel.com/docs/solutions/realtime
Though you can also just put your entire backend elsewhere too if that makes more sense for your use case.
I'd guess that you're deploying to a serverless environment like Vercel. The problem with file uploads there is that the filesystem is ephemeral; that is, the files stored on it will only exist on that one system, and only until it spins back down shortly after use.
Instead, you'll need to use a different service for storing those files. Vercel has a whole docs page with recommendations.
Check out SvelteKit (https://kit.svelte.dev/) and then deploy it zero-config to Vercel!
Have you heard about incremental static generation? It's a feature for Next.js apps on Vercel, and it's one possible solution to your problem.
Vercel doesn't recommend you use CloudFlare's proxy (see link below for details), but you certainly can use their DNS service. I do.
Vercel already has a CDN for all your static content, so the Cloudflare CDN is sort of redundant.
https://vercel.com/support/articles/using-cloudflare-with-vercel
I think you are maybe trying to do some premature optimization. Your site is clearly a dynamic site and would benefit from Django just dynamically rendering the pages for each request.
What you seem to want is Incremental Static Regeneration. Which have some good solutions out there if you are willing to rebuild your front-end in something more suited towards ISR.
I personally think you should deploy regular Django. If you happen to notice any speed issues then you can rather look into caching the DB data in memory to help speed things up. You just want to reduce the load on your database. You can do this using some kind of memory cache.
I mean you can also just trigger a build on a webhook from your CMS: https://vercel.com/docs/concepts/git/deploy-hooks.
Also, if you set the revalidate to 1 minute or something, is that really so bad? You'd get a hit to your database once a minute maximum. That's not exactly straining the server.
Not sure why you'd use GitHub Actions with Vercel, but it's pretty easy if you're just using Vercel: https://vercel.com/support/articles/set-up-a-staging-environment-on-vercel
Depends on how many function executions you need, but I didn't hit vercel's free plan limits yet. :)
​
https://vercel.com/docs/concepts/limits/fair-use-policy#typical-monthly-usage-guidelines
Hey there! I don’t know if you are using vercel for hosting, but they have something called monorepos. Essentially, it allows you to have a single repo/project to ease the process of managing several different applications. See: https://vercel.com/blog/monorepos
With this, you could manage envs in one single dashboard shared across as many deployments, allowing you to pursue the idea you mentioned in your post.
I absolutely love vercel, and use it to host my own site: https://zluvo.com. Definitely give it a try, even if you just use it for development/previewing.
Hmm, maybe this is just because I'm not nearly as familiar with JS as I am CLJS, but there are lots of things that I think are far more painful in JS land:
- I can't eval stuff as the code is running (how am supposed to test handlers if I have to save and lose the app state every time I make a change)
- you can't map over an object e.g (for [[k v] {:foo "bar"}]...
- I don't think there is a good replacement for assoc/dissoc/update etc
- a bunch more small stupid things like 0 being falsy and commas etc
And then there's the editor experience, again, maybe comes down to experience but I am many times faster in a Clojure file than when working with JS. Is there anything like paredit in VSCode?
And as for the pain of integrating CLJS, it really isn't that bad at all. I definitely spent a lot more time slowed down by React Native/Expo issues than CLJS.
I have been playing a lot with tools outside the Clojure ecosystem and there definitely are a lot of things out there that just don't exist in the CLJS world.
I built my personal blog using this technique, and I don't see how you could achieve such a setup in Clojure (obviously it's technically possible, but realistically no company like Vercel is going to support such a thing).
Overall though, I will still pick Clojure for anything involving non-trivial data processing logic every time. I really believe that even for this simple 2-week project I saved time by using ClojureScript, and that advantage only gets bigger the more complex the application becomes.
You can, actually. You get a bunch of specific optimizations if you deploy Next to Vercel without a custom server, but Vercel provides several different runtimes you can use to deploy all sorts of apps: https://vercel.com/docs/runtimes
It doesn't really for truely real-time scenarios. Vercel developed it and so they push it a lot.
It's a good library, but it's really just a tool for making an old-school HTTP request to a REST backend. As for semi-real-time, you can configure it to refresh the data on an interval (every few seconds) and it handles only re-rendering your react components when data actually changes.
If your real time needs are only semi-realtime (i.e. you have a dashboard and you want to show changes as they happen over the course of a day), then you may be fine with something that is only as real-time as "every few seconds". Using SWR or react-query (a similar open source library) are a heck of a lot easier than something that with real websockets.
But if you are making a chat app or want to create a collaborative document editing app where you want users to see each other typing and moving their cursors around in real time, you'll need something more instantaneous that than and will want to look at one of the other options.
Vercel has a guild on using Pusher here (I have no idea of Pusher, specifically, is good as I have never used it): https://vercel.com/guides/deploying-pusher-channels-with-vercel
I host all my stuff on Vercel. It's super simple, and works with create-react-app out of the box. You just connect your repo and it's done, it deploys automatically on every commit. You can deploy a servlerless function to handle a backend of recaptcha.
The default has changed to us-east now: https://vercel.com/changelog/serverless-functions-are-now-deployed-to-us-east-by-default
I'll outline some benefits of Next.js below (from personal experience).
- File-based routing structure (navigating to your-url.com/pages/about will display component in
pages/about.js) - I've noticed this to be a huge advantage in organizing your codebase - Best of all worlds - supports both SSG and SSR with close-to-zero configuration
- Need API - Need to create APIs? Just write functions in
/pages/api/directory. This also enables you to manage your backend code in the same project (as opposed to havingfrontendandbackenddirectories or projects). - Deployment - You can deploy your next.js projects to Vercel with a few clicks (literally, a few clicks). You can host your full-stack app in a single Vercel project.
- Many, many other reasons to try it out - Next.js is hands-down the most enjoyable framework I've ever used. Gatsby.js is also great, but I didn't like the GraphQL layer. I also love the way next.js handles SSG.
Disadvantages? I can only come up with one at the moment.
- Learning Curve - Just like any other frameworks, there is a bit of a learning curve. If you're familiar with
create-react-app, you'll be fine.
To be clear - you'll still need to run a separate Node.js server if you need functionalities that can't be handled in serverless functions (e.g. WebSockets). But most of the time, you can structure your app to maintain a serverless architecture.
also if you tried next.config CORS variant did you change this
{ key: "Access-Control-Allow-Origin", value: "*" },
to
{ key: "Access-Control-Allow-Origin", value: "https:\\yoursite.com" },
Or again the env variable could be used here instead of hardcoding
Here’s my index.js ```
import React from 'react'; import Head from 'next/head' import Image from 'next/image' import styles from '../styles/Home.module.css' import firebase from 'firebase/compat/app'; import 'firebase/compat/auth'; import 'firebase/compat/firestore'; //import AppBar from '@mui/material/AppBar' //import Toolbar from '@mui/material/Toolbar' import Typography from '@mui/material/Typography' //import Button from '@mui/material/Button' //import Link from 'next/link' import { Container } from '@mui/material' import FirebaseClient from '../FIREBASE/FirebaseClient' FirebaseClient()
export default function Home() { return ( <div className={styles.container}> <Head> <title>Create Next App</title> <meta name="description" content="Generated by create next app" /> <link rel="icon" href="/favicon.ico" /> </Head>
<Container> <h1>HOME PAGE</h1> </Container>
<footer className={styles.footer}> <a href="https://vercel.com?utm_source=create-next-app&utm_medium=default-template&utm_campaign=create-next-app" target="_blank" rel="noopener noreferrer" > Powered by{' '} <span className={styles.logo}> <Image src="/vercel.svg" alt="Vercel Logo" width={72} height={16} /> </span> </a> </footer> </div> ) }
https://vercel.com/blog/nextjs-server-side-rendering-vs-static-generation
When using SSR it renders per request. When using static it renders the HTML at build time.
If really only one minor service needs to be called, I wouldn't go through the hassle of setting up a whole service for it, but rather just use serverless functions or even Github Actions. Vercel has a good example here
We had issues with a end users trying to access from China. This guide fixed it: https://vercel.com/support/articles/how-do-i-prevent-my-vercel-deployment-from-being-blocked-in-china?query=china%2520block
Yup - this is tricky. It's hard to cache pages with presigned URLs that expire.
Here's a few approaches I've used in the past with S3 and Next.js.
1) Use Vercel's ISR and set a revalidate that is a bit shorter than your S3 expire timeout. This allows Vercel to regenerate the cached pages every so often and prevent them from holding stale S3 urls. This can be tricky on very low traffic websites, like 1 or 2 users visiting every few weeks, but works great otherwise. More info here: https://vercel.com/docs/next.js/incremental-static-regeneration#fetching-data
2) Don't generate the S3 urls in getStaticProps. Instead only generate cacheable content and then at client-side runtime have React fetch the S3 urls from a Next.js API route that does all the signing. This ensures you always get fresh URL. Tradeoff here is that you won't have server rendered image tags, so rest of your content might load before your images.
3) If you can avoid it skip the presigned URLs. Instead generate an image url that includes a sha so it's impossible to guess. Depending on your security requirements this might be a non starter, but I've found this simple approach solves a lot of problems with SSG.
Hope this helps! Happy to go into more detail on any of these.
Dreamhost unfortunately sounds like a bit of a nightmare for deploying Node.js apps.
> Node.js is not installed by default on newer DreamHost servers. You must manually install a custom version under your server's username. View the following article for instructions on how to install a custom version of Node.js.
And if you do end up using Passenger, you're stuck with Node <= 12.
> The version of Passenger running on DreamHost servers does not currently function with Node.js versions 14+.
And for what it's worth, the LTS schedule for Node 12 is no longer active, and will reach end-of-life come April 30, 2022.
I'd look to host elsewhere if you have that option. Vercel is free for hobby projects and it's made for Next.js.
Consider an infrastructure where you have 3 nextjs server instances A, B & C, which are fronted by some kind of a load balancer that balances traffic to them. Let's say a user makes some request to your app and it gets routed to A. During the request to A, next/image will save the image (and resized images) to the local filesystem (instance-level cache). Then you can imagine that the next request to A will be served from the cache which will be much faster than downloading from S3, and converting it, and saving it, then sending it back to the user.
But notice, this will only happen if the next request gets to A. Chances are it won't because of B & C. And if you have a thousand instances, you can imagine why it'll be pretty much ineffective. So instead, I recommended the CDN cache because it caches everything returned from a URL pattern you define, with a cache policy you define. So every time a GET request is made to a particular URL for a specific image of a particular size, the request doesn't go to your nextjs server but can directly be fetched from the CDN which is much much faster.
You have to understand what Vercel is, and how it works. Their big selling point is their simplified platform for infrastructure where you don't have to think about it, but unless you're building a personal project, you have to be very careful about that. What they essentially do is abstract all the logic above away from you so you can "focus building your application" but if you expect to get some serious traffic on your site at some point, you have to and should worry about your infrastructure.
TLDR; Vercel has a CDN infront of their architecture (link) that basically does what I described above.
I don’t ever hear much about this, but:
Execution time limits
Depending on your function provider, you may have a limit of 10 seconds of execution per invocation before the request times out. Or it may be 30, or 60, or 600. Again, it depends.
It’s not really an issue for most applications, but for some applications it’s insufficient. Something to think about when deciding which service provider to pick.
Here are Vercel’s limits: https://vercel.com/docs/platform/limits
No, there is no downtime in deployments, regardless of the deployment stage. You can even switch projects to different accounts without downtime: https://vercel.com/blog/transfer-vercel-projects-with-zero-downtime
Your domain just routes to a different/new deployment after deploying.-
You can use https://vercel.com/ and follow this instructions https://calebporzio.com/easy-free-serverless-laravel-with-vercel.
By the nature of a serverless service as Vercel you don't have a MySQL database or even SQLite.
In the other hand, you can use ngrok or even expose to share your local project and make it public through the net.
I personally like Vercel but the steps are similar on Netlify.
(Using Git - Recommended) Simply push your code to GitHub, GitLab or Bitbucket. In Vercel you can connect your GitHub, GitLab or Bitbucket account and code. Vercel will auto detect that it's a Svelte project and build it. Afterwards it will give you a URL to see your code live.
(Non Git) When you are done with your code, run "npm run build" and a folder with your compiled code will be generated. You can then copy/upload the code in the Build folder to whatever hosting provider you like.
Here is a link to Vercel so you can connect your Git repo if you want to go that route.
https://vercel.com/guides/deploying-svelte-with-vercel
Like others have said, you don't need Sveltekit, especially if you just have a simple landing page.
Hope this helps.
I don’t know if this is possible. You do, however, get an email when a deployment is successful via GitHub. Telegram is not integrated as of now, but slack is: https://vercel.com/integrations/slack. This might be what you are looking for. It says, “The Vercel integration for Slack gives your team the full picture on the deployments of Vercel projects in the Slack channel(s) of your choosing.”
They have their own Edge network. It’s documented here:
https://vercel.com/docs/edge-network/overview
In a nutshell:
- Static content is served from a global CDN
- Dynamic content (things in your serverless functions like API code and getServerProps related code) is served from the region your project is configured in.
Note, if the static content (the photos/illustrations) is user submitted and therefore not living in your source tree (e.g. your ./public/ folder) and is stead being served out of a database via an API route, it won’t look like static content to the Vercel engine and won’t be served from the CDN. In that case, you’re probably better off storing your “dynamic-static” images in a third party CDN and not serving them via NextJS/Vercel.
Eu gosto mt da vercel para deploy de nextjs. Podes usar sem problema para FE (client side, ou ssr com next). Backend em node tb e fácil, no fundo é apenas uma lambda que corre o teu backend (express?).
Se o backend for simples o suficiente (uma rest api ou algo do género) e se usares React, talvez valha a pena converter tudo num proj em next.js. O deploy aí é automático (o next.js é da vercel)
You can try making middleware with Vercel Serverless (free to use btw) with scenario where it accepts request, reads incoming data and sends request to ifttt with data you need in value1/2/3. You can go even more further and encode incoming json as value1 and decode it in filter code.
> I've used Heroku [..] but am wary of the cost [..] unless i'm using the Hobby pricing, i'm looking at ~$100/month
I've been running my SaaS on the Heroku hobby tier & it's currently costing about $35 a month. You can get pretty decent performance out of the $7 dynos, my app currently is getting about 100 requests a minute & doing just fine :)
> Digital Ocean's App Platform [..] but i've seen mixed reviewed from people
I had the same experience. It's a decent platform, but isn't quite as good as Heroku yet. I'm pretty hopeful for it though!
> AWS Elastic Beanstalk
Personally I'd avoid AWS Elastic Beanstalk like the plague! If you're going to be on AWS, you'd be better of learning how to deploy via K8s.
If you're concerned about pricing, I'd totally suggest giving Vercel a try. Pretty much instead of a full app, you'd just have serverless API endpoints to handle talking to the database.
Actually no. You're developing with the next command and the page will behave completely differently, e.g.: it will refetch data each time you reload it. Vercel runs next build and then syncs the files to AWS where they will be executed as lambdas. To simulate this behaviour you can try <code>vercel dev</code> or next build && next start.
Nope, you can still deploy with Heroku if you'd like! You need a Vercel account to view the dashboard, but you don't have to move your deployment.
Docs currently say it's $10/month plus $0.65 per 10,000 data points (when hosted on Vercel; $0.95 if self-hosted).
Checkout https://vercel.com/ depending on your traffic it could be entirely free.
The platform is tailored to devs. It might seem a bit hardcore to you but they got very good documentation and a very nice community.
No catch, and no it’s not limited to static sites.
I should have said it STARTS free: https://vercel.com/pricing
As in, they have a very good free tier that doesn’t have silly restrictions. But it does have to be non-commercial (I think that’s new?) and it gets fewer resources. The paid plans are very reasonably priced though so I wouldn’t hesitate to host commercial apps either.
Do you mean (a) deploying a sveltekit app as a docker container or (b) developing your sveltekit app in a docker container?
If it's the latter, I've tried it and highly recommend it. The vscode + docker integration is nothing short of amazing. This is especially true if you're learning or like to tinker around. You can run any command on the command line and install whatever you like. Whenever you finally manage to break your project lol, you can just reset your devcontainer. Also, if you ever want to work on that project after a while, the devcontainer can rebuild itself to the exact same state it was in, including any vscode extensions, settings, etc.
If you mean the former, I've never tried myself. I'd also be interested to know about the pros/cons. The question that immediately comes to mind is whether deploying a sveltekit app as a docker image would interfere with the caching & optimizations done by the cdn hosting providers. AKA, if you deploy your sveltekit app as a docker container, would you be be able to take advantage of things like vercel edge functions (or whatever the cloudflare or netlify equivalents) are?
the google private key environment variable is over 4kb.
you can deploy that environment variable. i found a vercel blog post on how to fix it.
https://vercel.com/support/articles/how-do-i-workaround-vercel-s-4-kb-environment-variables-limit
i was able to get it to work. do you mind figuring out how to you plug the new private key in the submit api route?
I've been looking further into this. It seems that Vercel, for example, infers all pushes to the main branch as production updates, while updates to any other branch are inferred as dev updates. This is an issue for me as I just have the one branch, main. You were saying don't use branches, uses releases (I assume this is what you were referring to when you said 'versions'?). But if I've understood you/Vercel correctly, this doesn't seem to be possible? (Vercel docs link.)
I've been looking into this and it seems Vercel, for example, infer pushes to the main branch as production updates, while pushes to any other branches are inferred as dev updates. (Docs). This is an issue for me as my Git setup as very simple - I just have the main branch, no others. Someone in another thread suggested having Vercel / Netlify etc look at releases, not branches, but from what I've read this isn't possible since, as I say, Vercel seems to care about branches not releases?
Yup, you're pretty much exactly right!
It's worth noting that you can use incremental static regeneration, which will allow static build to regenerate pages on the server as requests come in. This is a nice way to get the best of both worlds, but you could be showing stale data with this approach, so it's not good if you absolutely need the latest information.
Instead of SSR, if you if you need non stale information I would recommend using CSR. With this approach you have the React app fetch the data it needs client side at run time. Most of the time, client side data fetching is the best out-of-the-box approach for data fetching the latest non stale version of the data.
My suggestion would be to move to ISR. Build the 100 most popular pages during the build process and let the others get built on the fly and incrementally as people visit them (use fallback: blocking).
You can totally do it, I’ve done it a few times, if you’ll be deploying to Vercel just make sure to override the build & install commands.
Also you’ll need to create a new Vercel project for each app in the turborepo, and connect all the projects to the same GitHub repo.
Here’s more detailed info about it https://vercel.com/docs/concepts/git/monorepos#setup-turborepo
You might need to set the env variables on the deployment server.
Popular ones has docs like,
- Netlify: https://docs.netlify.com/configure-builds/environment-variables/
- Vercel: https://vercel.com/docs/concepts/projects/environment-variables
on how to configure environment variables.
They have a doc for doing it, but it is not recommended. Perhaps using non-cached dns for your root domain example.com and using cloudflare caching for assets.example.com. Then move all your images to the subdomain.
https://vercel.com/support/articles/using-cloudflare-with-vercel
I ended up using vercel ( formerly now) https://vercel.com/
I never did figure out how to get it hosted, everything I tried just wouldnt work. Vercel took me all of 5 min to get it up and running.
Have you considered ISR?
This way you can build the most important static pages at during deploy/build but then additional pages are generated as and when required.
A typical use case is e-commerce, where you may pre-build the pages for the most popular products, then less popular products are built when first visited.
Next.js website has a great guide that covers this https://vercel.com/docs/concepts/next.js/incremental-static-regeneration
The reason I was turned off by firebase cloud functions was because of its cold start times; you can also take a look at vercel's pricing sheet to see how much it will cost to scale.
On a project we were serving some images from Digital Ocean, we set the Cache-Control header from Digital Ocean’s response, this is what Vercel takes into account to set the caching expiration date.
If not set, Vercel will add its own Cache-Control header, which might not suit all use cases.
See: https://vercel.com/docs/concepts/edge-network/caching#static-files
I don't know why, but I can't find any real documentation on how exactly to use vercel.json (other than that it seems deprecated), nor could I find documentation that explains the "use": "@vercel/static"
This is the only thing I found on it.
https://vercel.com/guides/upgrade-to-zero-configuration
​
Things that I noticed in that guide:
- The builds/src is pointed to package.json/index.js, not just the folder. For frontend, this makes sense to me, as Vercel needs to run the `npm run build` command for you, to create the build folder on their end. (you'll notice that most likely your build folder is .gitignored, and it's missing in your github version of the code). But yeah, I would assume you can't just point at the folder, you have to point to a file, based on the examples.
- it's using "@vercel/static-build" instead of "@vercel/static". Again, I can't find documentation on this, so I have no idea if they are both correct, if they are the same thing, or what not.
If you're simply talking about local development, you can just put it all in your .env.local file, comment out whichever configuration you don't need to "simulate" your different environments. From what I've seen in the documentation, having multiple files for env configuration only helps the automatic detection during build time. To have more custom environments, you can just manually add your config in vercel.
Only part missing I think is the image optimization.
That portion is only offered by Vercel platform (I could be wrong).
https://vercel.com/docs/concepts/next.js/image-optimization#
It’ll be more work to get this working on AWS but it is possible with:
- AWS S3 & cloudfront
- AWS lambda at edge for run time image optimization and sizing
I hope that helps.
I prefer React simply because I am more comfortable in it, but since I've fallen in love with Svelte a couple of years ago (and now even more so with SvelteKit) I do feel my time on Vue did help understand Svelte better.
I wish, since Rich Harris was hired by Vercel, who makes my other love: Next.js, that Svelte will grow to properly challenge (in terms of stake, not quality) both React and Vue (and Angular to some degree).
As for better, you've gotten great answers already. :)
Yes, this is by design since `getStaticProps` is happening at build time. Typically in this scenario you'd have three options:
1) Using the `notFound: true` to redirect to the 404.
2) Using the `notFound: true` to redirect to the 404 page, and also using the `revalidate` flag to tell Next, "Hey, I want to run through this `getStaticProps` logic again on this route after a certain amount of time to see if the page is able to build with proper data now". This turns on [incremental static regeneration](https://vercel.com/docs/concepts/next.js/incremental-static-regeneration) which is super powerful!
3) If you're dead set on redirecting to a 500 page, then there is a `redirect` option in `getStaticProps`, but I believe it can only be used with dynamic routes. So if redirecting in `getStaticProps` doesn't work for you, then you'd have to do the redirect to a custom 500 page on the client with something like this:
```
import React, { useEffect } from 'react';
import { useRouter } from 'next/router';
const Sample = ({ goTo500 }) => {
const router = useRouter();
useEffect(() => {
if (goTo500) {
router.push('/500')
}
});
return (
<div>Sample Page With 500 Redirect</div>
);
};
export async function getStaticProps() {
const someScenarioThatShouldRedirect = true;
if (someScenarioThatShouldRedirect) {
return {
props: {
goTo500: true
},
};
}
return { props: {} }
}
export default Sample;
```
Generally you'll want to avoid 500 pages as this is bad for SEO and a multitude of other things, so you should try to gracefully handle errors whenever possible! This is without any knowledge of your use case, though, so it's totally possible what you're trying to accomplish is valid.
Hope this helps!
people can spin up there own version of the site by going to this link - https://vercel.com/new/git/external?repository-url=https://github.com/chirag-droid/animeflix/&project-name=animeflix&repository-name=animeflix
I am pretty sure vercel uses AWS (https://vercel.com/docs/concepts/edge-network/regions) but I could be wrong.
Their provider regions all list AWS regions. In order for them to move fast, streamline scalability and security, it doesn’t really make sense to integrate multiple providers (ie CloudFlare).
AWS has lambda and Lambda@ Edge.
They’re hosted as serverless functions in AWS Lambda. That’s why you have to take special measures to use your own AWS variables in your deployment, because they’ll conflict with that Vercel is doing under the hood. See the page below. Also if you ever get a server-side error in Vercel you’ll notice that the error message mentions an issue with a serverless function.
https://vercel.com/support/articles/how-can-i-use-aws-sdk-environment-variables-on-vercel
$20 per developer per Team. A team can hold multiple projects. See their limits page for additional details. Additional prices apply if you exceed certain limits.
Publishing an app multiple times per month to the App Store / Play Store just to change text within your app is impractical.
If your app just needs one or more text resources, you can use something like Vercel to host that text resources. Your app then downloads and caches them. No other external server needed and no special Dart package. All you need a an HTTP GET with If-Modified-Since header.
You could even host and then download an sqlite database file and use the sqlite3 package to access the data stored within, if you need to provide tabular data. Creating such a database is of course another task then.
Nope, see incremental static regeneration. Basic idea: first client request for page X gets cached and served to all other users who also request page X. This means you don't really have a "build time" per se. New hits to new, uncached pages will trigger a build but only for that page. So it's much, much faster than, say, a Gatsby site.
Outro lugar onde você consegue rodar seu código de graça: https://vercel.com/dashboard
Você tendo uma conta no GitHub você já consegue trabalhar legal com Vercel, por exemplo.
For the serverless functions there is a built in integration if you deploy on Vercel.
For browser logs, do this
https://docs.datadoghq.com/real_user_monitoring/browser/
Probably need to do that in _app.js
Datadog is awesome
If you use Vercel, you can have whatever you'd like very easily. https://vercel.com/blog/monorepos
If you're using AWS or something else, as long as you get the full feature set of Next.js, you could leverage Next.js rewrites/redirects to accomplish a DNS stitching of applications - even via the same subdomain.
​
I also personally recommend doing ALL Next.js even for your app - statically pre-rendering stuff is beneficial for every user, not just landing page visitors.
I see that NextJS now recommends a pub/sub approach Vercel Support Your client will need to subscribe to the events from a 3rd party service like Pusher Channels and the Pub should be handled by a serverless function
I use Netlify for all my static hosting. It's free, easy to deploy to and has been incredibly reliable for me. Vercel is another popular option but they're explicitly state that they do not want their free tier to be used in a commercial capacity see here.
Hey u/echopulse! Your site is looking really good 🔥 Here are a couple of constructive feedback comments!
- There's some fairly significant layout shift on initial load. This can hurt your SEO score and thereby cause your site to be ranked lower on search engines. Plus, it's just a little jarring for users. See if you can reduce some of that layout shift by adding loading skeletons in their places while things load!
- In the footer, "Linked in" should be spelled "LinkedIn", and might be nice if you can get an icon on that button like what you have for Facebook!
- Not sure if I've ever seen a sitemap link in a footer before... 🤔 I thinking linking to that in your robots.txt should be sufficient?
- I'm probably the last guy who should give styling advice 😂 and I know this is a bit vague, but I get a feeling like the styling of your site is from a few years back rather than a more "modern" look and feel. For example, https://vercel.com/docs has, in my opinion, a very modern feel to it. Maybe have a look around some popular websites and see if you can emulate their "feel"? For example, I think one thing that contributes to this feeling on the home page is the unstyled (i.e. perfectly square, borderless, etc.) pictures hanging out directly alongside some relatively plain text. I know this is a bit vague, but thought I'd comment in case it's helpful!
What I personally recommend is building your API separately and hosting somewhere like Heroku that uses a real long running process (server) rather than serverless. However, if you build your API routes in Next.js and host it on Vercel, they will turn each of your API routes into cloud functions and everything will still work but you'll have to just make sure your DB connections are written in a way that gets reinitialized in a stateless way.
Read this - it explains in detail:
https://vercel.com/guides/using-express-with-vercel
Depending on where you published you might have to redirect your site.
- netlify: https://docs.netlify.com/routing/redirects/
- Page Not Found on Netlify with React Router: my old post shows how to redirect for netlify.
- vercel: https://vercel.com/docs/configuration#project/redirects
Here is the documentation for adding domains to Vercel: https://vercel.com/docs/custom-domains
In your DNS either add an A record with “app” as the host and the IP address as the target.
Or create a cname alias for “app” with the target of “my-app-name.vercel.app”.
I did!
I noticed in Vercel's docs that having a folder called "api" in my routes directory would get picked up by Vercel as a Serverless Function, which met my needs.
From time to time i get a 404 message when requesting data but i get my response from Sveltekit just fine. So I'm sure this is something that needs to be addressed or I'm doing it wrong...😅
As many others have said, you need a backend to store the keys safely if you want to deploy this app somewhere.
However, with the advent of "serverless" architecture, you can avoid having to write your own backend altogether. For example if you host your site with Vercel, you can use their serverless functions feature to write a small API function that grabs your secret key (stored in Vercel), makes an API call, and returns the results. Netlify probably does something similar and I'm sure there are others as well.
Consider either adapting the code to run as a (AWS) Lambda.
Lambda is AWS-only, but is very well supported. You'd write your config file to a S3 bucket, call your Lambda, and it'll return the results directly to you. If you could get the config small enough, you can just pass the config directly to the Lambda and you won't need a bucket. https://aws.amazon.com/blogs/compute/introducing-the-c-lambda-runtime/
For a non-AWS solution, consider Vercel: https://vercel.com/docs/serverless-functions/introduction or OpenFaas: https://www.openfaas.com/
One advantage is persisting cached images between deployments. But it's not drastically different between different image optimization providers. The main advantage of Vercel is that it's zero-config, and works by default.
https://vercel.com/docs/next.js/image-optimization#edge-network-optimization
almost like its mentioned in the docs https://vercel.com/docs/platform/fair-use-policy?query=fair%20use#usage-guidelines which is linked directly below the pricing overview https://imgur.com/a/9WI1qCq
go clown somewhere else for your inability to read, seriously. shit like this is inacceptable
Vercel will probably automatically generate SSL certificates for you. If you run you app on your own servers, then you need to manually create the SSL certs.
If your app always runs on Vercel, even with your custom domain name, then maybe check their docs: https://vercel.com/support/articles/domain-not-generating-ssl-certificate?query=ssl#verifying-the-caa-record
If you're planning to host this on Vercel then be careful as they use Serverless Functions and your database will likely collapse from too many connections without the right setup.
https://vercel.com/docs/solutions/databases#connecting-to-your-database
You can do what you want with deploy hooks and forget about ISR... I think that makes more sense when the data is coming from your CMS. You make a change in the CMS, use a deploy hook to rebuild. If you were pulling data from some external API with no idea when the data will change, ISR would useful.
There are a lot of platforms that handle devops for you, but if you are doing a startup you might as well be as lean as possible, and just launch and validate your idea.
Launch your product and see if it gains any traction, if it crashes because you have bad devops thats probably a good thing since you have a valid idea!
You could also try https://flutter.dev/ for iOS, Android, and Web. Its time to implementation is much shorter than react native and performs better.
In terms of hosting you could check out vercel, or aws, and google cloud. I would probably just use a free aws tier and launch the product and see if it sticks.
I organize my server side requests in a separate folder & import them as needed into getServerSideProps or pages/api
If you use vercel - what's even more important is caching your responses https://vercel.com/docs/edge-network/caching#serverless-functions-(lambdas)
That's not really a Next.js or Vercel related question. You should read about DNS records. It's usually pretty straightforward, just go to your domain name provider and read the docs on how to add a subdomain rule.
On Vercel, there is a page to add a subdomain, they'll give you everything you need to set there. Here is the documentation: https://vercel.com/docs/custom-domains
Seems like the code is just a static HTML file. You can push the file to github and then use vercel.com to deploy to your custom domain name. Very scalable, 100% uptime guaranteed, no need to maintain any server/hosting.
Depends on the hosting options. Some providers allow running Node in a shared hosting environment (see ICDSoft's instructions for how to do so, for example). Other than that — yes, VPS or hosting of Docker containers. There is yet one other option of running the server-side code as lambda functions. Vercel, for example, keeps the api of these lambda functions very similar to the api of Express middleware.
Even if you could, you probably shouldn't do it.
It would probably be a better idea to get a pre-signed URL from S3 and let the client POST directly to the storage bucket.
See the guide at Vercel: https://vercel.com/docs/solutions/file-storage
As promised - here's the reply from Vercel support
​
> Hi there,
>
>Thank you for getting in touch! You need to benchmark cold-starts considering the following:
>
>The location of your function: https://vercel.com/docs/configuration#project/regions. You should always place Serverless Functions closest to your data source.
>
>The dependencies of your code: The larger the function, the less performant it will be. If you are also opening DB connections not optimized for the serverless environment, this can be a factor to consider. Typically, cold starts takes less than a second and anything above that can be attributed to DB connections or other parts of code.
>
>Let us know if you have any further questions!
>
>Kindest regards,
>
>***** ******
Customer Success Engineer
Vercel
You should use a custom domain name because by default vercel prevent search engines fro indexing a subdomain, and this is good for you to avoid duplicated content, read more about this: https://vercel.com/support/articles/are-vercel-preview-deployment-indexed-by-search-engines
As I understand it, Vecel and Netlify do this by analyzing and understanding what URLs are static and which are dynamic. They then use that information to configure a geographically distributed router/proxy that sits geographically near end users in the same way that a CDN is. This router looks at every incoming requrest and routes it either to serverless functions if it is a dynamic request or to a CDN if it is an image, js file, or a static page, etc.
Replicating that outside of yourself is certainly possible, but not simple and certainly not plug and play. If you want to attempt it, I'd start with looking at the various generated manifest files under .next folder in the serverless subfolder. Those files contain the information that Vercel and Netlify use to know how to route requests. I don't believe those files are very well documented, but you can probably tell what most of them do experimentation.
See https://vercel.com/docs/edge-network/overview
Alternatively you could put something like CloudFlare in front of your real deployment. It does a fair job of determining what requests are static and caching them in their CDN without needing that to be preconfigured.
If you're hosting it on Vercel you can create a Deploy Hook on the project which would initiate a deployment, independent of any changes in GitHub. Then you would just need to have your CMS post to the deploy hook when something is published.
If you want to properly host this, you can use a free web application deployment site like Vercel
You can also make a more robust application and use a backend framework like FastAPI (Python) and a frontend framework like React (Javascript).
yeah this one and a bunch of others (like https://www.playingwithfire.co/retirementcalculator) were tools i'd used before -- part of my goal with this project was to see if I could still code & use a brand new frontend framework. I used vercel.com btw which is just awesome and super easy to deploy
Hey,
there's nothing wrong with hosting the frontend on the same machine.
​
Just keep in mind what you need, if you self host the frontend, and if you have time for these things.
- nginx / apache with vhost + proxypass configuration
- ssl cert (+ maybe let's encrypt + certbot for auto renew)
- setup node (and keep it secure/updated)
- pm2 or other process manager (configured to restart when you reboot the server)
- building the next frontend and / or maybe some kind of auto deployment (with github actions setup?)
​
On vercel you import a git project and you're ready to go. If you want, you can redirect multiple domains, or simple install a SSL cert. With the click of a mouse button. And you can also test every git branch and even every commit with a different vercel.app url. With next.js 10 you got analytics too, where you can see the performance and find problematic pages.
​
In the end it depends on you and on the project needs, Jamstack is not always the best soluation.
​
We host multiple sites on vercel.com with different backends (GraphCMS, CraftCMS, Rest APIs, etc.) and we also self host sites, for ex. larger ecommerce site, where traffic and data protection is a thing (eu law, content security policy, etc.).