Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 1 year ago.
Improve this question
NextJS has a solution to build your own API and have it handle things like authentication and making database requests.
If I'm using using Vercel to host my app, is there a real reason (other than cost) to use Firebase Cloud Functions separate from NextJS, or do they work the same?
Will it be easier to have all my server side things on NextJS and Vercel rather than have it on Firebase Cloud Functions?
There are a few things to consider when deciding between Firebase Cloud Functions and Next.js API routes.
Reasons to use Cloud Functions
Trigger on database changes
If a document is added, you can use a Firebase Cloud Function to do something with the data. Next.JS will not be automatically triggered.
Integration with Google Cloud
If you want tight integration with Google Cloud, you may wish to just stick with Firebase. Other than error logging, I can't think of any specific reasons why this would be a deciding factor, but it may be a factor for your use case.
You need more then a REST API
There are multiple types of Firebase functions. Callable, HTTPs, triggered, etc. If all you need are HTTPs functions, you can probably just use Next.js functions. But anything more isn't possible with Next.js.
Deploy functions independently
With Next.js, to update a function, you need to redeploy the entire site again. With Firebase functions, you can deploy one function at a time.
Reasons to use Next.js API functions
If on Vercel, they're basically free
Since the entire Next.js app is broken down into serverless functions, Vercel essentially doesn't place [its normal limits on Next.js API function calls][1]. I haven't had a project where the price was really a factor since Firebase functions are so cheap, but perhaps it's something for you to consider.
Simpler development
With Firebase Functions, you also need to setup and use the emulators when in development. Next.js API functions are, well, apart of Next.js and work automatically in development.
My choice? If the project can work with only Next.js API routes, I stick with that. IF not, I code everything in Firebase Cloud Functions. It just keeps things simpler that way.
Related
My website will perform CRUD operations and will work with MongoDB and Firebase storage+auth.
What are the reasons / advantages to developing a separate Express server instead of integrating everything in my next.js app?
As far as I have seen, it can all be done in my next.js app, but I still see many projects working with a separate server.
Depends on what your app does and how you are hosting it.
Running Next.Js on a standard server will be of little difference whether you are using nextjs's /api or expressjs.
However if you are hosting on serverless (e.g. Vercel), I would recommend using a separate express server if you have alot of CRUD operations because the warming up of serverless is really bad user experience.
Build and Deployment
Next/JS - If you want to edit something on the backend, and push the changes, it will require you to build the entire JS app, and depending on how big is your app, it can take alot of time (especially if alot of static generated pages).
Express - If you running express separately, you can build and deploy front end and backend separately. It's time saving, and you can also better organise your codes frontend/backend.
Choice of deployment
I have a choice to take advantage of Vercel to host my frontend, with static generated pages and some server side generated pages (automatic scaling, caching, CDN etc), and host my backend with a separate cluster of servers.
PS: I moved from single Next.JS app to NextJs+Express
I can think of a few things why they would have a different server from the one NextJS provides:
Familiarity with Express, Koa, etc. All next-connect helps with this
There is an already existing API in PHP, Express, Flask, etc.
It is literally based on what you would want to do, the extra interactions with MongoDB & Firebase would be same on both the technologies, unless you want to isolate respective things separately, I don't see any harm in doing everything together on next.
Given that the idea of using next.js, as per my understanding would be to utilise server side rendering.
I've been using Next.js with Typescript for quite a while now and I, as of now, have found one reason not to include express.js in my project. And the reason is Vercel.
Since I use Vercel for continuous deployment of my projects, and Vercel Not supporting any custom server as of there Docs here, I refrain from using Express or any other custom servers.
I didn't face any problem performing CRUD operations with MongoDB, can't say about firebase.
On Next.js Docs, I found these points to be considered:
A custom server can not be deployed on Vercel, the platform Next.js was made for.
A custom server will remove important performance optimizations, like serverless functions and Automatic Static Optimization.
But at the end of the day it very personal opinion weather to use a custom server or not. It might depend on a very specific use case you might be looking for.
Personally, I try to keep it to just NextJS, but if I have to manage real-time data with Socket.io, I get a separate server because other than WebSockets, serverless functions can do everything else.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm a student who study web development by myself.
I'm developing a shopping mall site as my personal project and I've got some elemental questions when I tried to make a login page.
First of all, I will tell you about the main concepts of my project on the beginning for you to understand my questions more easily.
My initial concepts and ideas are in below :
Database(MySQL)
I needed some data to show on the web site. So I decided to use 'Fashion Product Images Dataset' on the Kaggle. Users who sign up will be stored as well.
I just assumed that there is everything that I need, in order to make the website.
Web Application Server(API server)
I thought this is a kind of bridge which are able to make the javaScript on the browser to get some resources, a sort of product images and prices, when the page is loaded for the first time or the resources need to be changed by users or codes.
Web Server(Built-in the React)
I made the React application using 'create-react-app', so I don't need to think about the web server actually. The only thing that I have done is building some components which display the UI using react library.
FRONT-END BACK-END
---------- ----------------------------------------------------------------
| CLIENT | < --- > | REACT | < --- > | API-SERVER | < --- > | DATABASE |
| REACT | |(WEB-SERVER)|
When users request my page, React(The built-in server) reply it.
Then, the users will get the SPA(client-side).
The SPA doesn't have any data, it will fetch the data from the API server(Because fetching codes are inserted in the .js files).
Then, The query inside of the api server will get the data from the database.
And then, the API server gives the data to the SPA.
It was quite going well until I start to think about the security. As you can see, when we visit other web sites, they use the https not the http. So I wanted to use the https, because it is really important to protect personal data from bad people. When I consider my idea, but, there wasn't any place to put the code which changes http to https.
Plus, I understood React is just a library, like reactjs.org said. So I think the reason why I am able to use the built-in web server is because the application is made by 'create-react-app'.
Finally, here are main questions.
As I know, the https logic should be in the web server. I mean the server which deal with the client's request.
If what the react is a library is true, do I have to build a web server?
(I think building a web server by Node.js or other languages is the right way, because a library is just a library..!)
If I don't need to build a web server, where should I put the logic?
Let's imagine that I am totally ready to use https (I made a web server by Node.js and I got a CA to use TLS), and then, the client and the web server are able to communicate safely. But, all of the code which call the API are written in the .js files.
And the files are now the client's browser. It means client and the API server doesn't have safe connection, because the API server and web server have different domain or port.
Maybe summary of the question 3:
3.1. When I searched on google, I understood web application server is to deal with requests that web server can not service. In the SPA, but, the request is from the client. Is this right?
3.1.1. If the question from the client, how to prove it is safe communication between client and web application server? because web server and web application server have different domain or port!
there wasn't any place to put the code which changes http to https.
Somewhere you have code which makes an HTTP request to a URL to fetch data from the API. That code must state what the URL is. You can specify the URL scheme there.
So I think the reason why I am able to use the built-in web server is because the application is made by 'create-react-app'.
React is a JS library. It doesn't have a built-in web server. create-react-app installs React, generates some default project files, and includes lots of tooling.
The web server is intended for development use only. It includes features that are useful for development but inefficient for production such as Hot Reloading.
It also has a build script that outputs static files for deploying on your production web server.
Your production server can support HTTPS. It may or may not be the same server that hosts your API.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
The community reviewed whether to reopen this question 9 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I understand that Nextjs is a Node framework that requires server capabilities and therefore, using it for server-side rendering could not be hosted on an S3 only.
However, does that mean that the only alternative is to host the entire app on an EC2 - which is significantly more expensive - or is there another mid-way solution?
Next.js SSR + Serverless framework + AWS Lambda
For deploying your Next.js SSR App, instead of following a traditional approach of managing and running a whole AWS EC2 instance which keeps running 24x7. There is actually one more cost effective and modern approach which uses AWS lambda and Serverless framework.
Q. What is AWS lambda?
AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume.
Q. What is Serverless framework?
Serverless Framework Open Source lets you develop applications with serverless architectures and deploy using AWS Lambda, Azure Functions, Google CloudFunctions & more.
Q. What is Serverless-Next.js?
This is a Serverless component built just for deploying Next.js app. Also any of your assets in the static or public folders are uploaded to S3 and served from CloudFront automatically, so I think this is what you are exactly looking for.
Below is the architecture explaining how it serves your app to the user.
If you are new to serverless framework, I will suggest you to go thru a free course by Serverless community called Serverless for Frontend Developers
EDIT: 03/03/2021
#super7egazi put forward a genuine concern in the comment below. Thankfully there are few ways to keep the Lambda function warm. This is the act of sending scheduled ping events to your functions to keep them alive and idle, ready to serve requests.
You will find various methods and plugins to achieve this, if you just search "How to keep lambda functions warm?" on google.
Below are some links which I'm attaching for reference.
How to keep your lambda functions warm?
How to Minimize AWS Lambda Cold Starts
Keep your lambdas warm
AWS Next.js Terraform module
We created an Open Source Terraform module as a lower cost alternative to the Serverless framework for this use case. Instead of relying only on Lambda#Edge for all SSR operations we use Lambda#Edge only for routing (as some kind of reverse proxy) and then redirect the request internally via API Gateway to an regional Lambda.
Since we use CloudFront as a reverse proxy we can also split most of the requests for static files against _next/static/* for css, js, etc. and serve them directly by S3 without touching the Lambda#Edge proxy at all.
So the cost per request are different per route:
Requests for static assets: css, js, images
Only costs for CloudFront and S3 (For misses from CloudFront) apply
Requests for HTML: Prerendered HTML-Routes or Routes that need Server-Side-Rendering (SSR)
Costs for Cloudfront, Lambda#Edge (Proxy, metered at 1ms steps) apply.
Rewrite routes that serve pre-rendered HTML
Costs for S3 apply.
Routes that use Server-Side-Rendering (SSR)
Costs for HTTP API-Gateway and regional Lambda (SSR, metered in 1ms steps) apply.
The total costs are usually far below 0.50$ / month for a few thousand requests with this model, while having a fast-serving site powered by CloudFront edge caching.
Find more information on the GitHub repo: https://github.com/dealmore/terraform-aws-next-js
NextJS + Serverless is not Free.
NextJS + Serverless is currently deployed on Lambda Edge which is not free. You do not enjoy the free tier from Lambda (not Lambda#Edge).
Vercel + NextJs is Free
If you have a low traffic website I would recommend you to deploy it with Vercel.com which uses Lambda (AWS Network) on the backend.
*Their hobby version is free and gives generous free traffic and invocation comparable to AWS Lambda Free tier.
Deployment of a NextJS App is as easy as uploading to Github + Vercel's auto deployment with GitHub integration. You do not need to bother about S3, or hosting or your static files, everything gets hosted on Vercel the moment you push to Github. You just need to concentrate on development.
When your your requirement goes up (you go past the Hobby package, and you go past the Pro package), then it becomes more cost effective deploying on Serverless#Edge.
By then, all you need to do is to switch your domain over.
Update: Just deploy it on a VPS
Serverless is a nice concept, and the ability to launch your websites for free on various platform is a plus.
However, cold start can be a big problem as it sometimes take 3-4 seconds to load a page for your visitor.
This is not so much of a problem if you are doing static OR static incremental generation. It's just NO GOOD for getServerSideProps.
If you are struggling for cold starts, trust me and move on to a VPS. A $5 VPS can run a site pretty well.
You can use AWS Lightsail: https://aws.amazon.com/lightsail/
In my experience with nextjs the cloud functions are not a good place to deploy a large application, so, this would be your options:
Only go with cloud functions if your app is super small and is never gonna grow. Cloud function have limitations on file size, dependencies, bundle size, etc, etc, etc
AWS Lightsail: https://aws.amazon.com/lightsail/ and a small VPS that you can set up your self with Nginx and node. Is like $5 / month and you can use your credits.
Same as numbers 1, but on Digital Ocean.
AWS Ec2
Not sure if you have a requirement to host on Amazon or not, but you can host on DigitalOcean for $5/month, or you can host on the free tier for Heroku until you confident you want to move to Amazon you can later move to a more expensive solution and host of EC2:
DigitalOcean That will give you 1 GB Memory - 25GB SSD - 1TB Transfer for $5/month
Heroku That will give you 512MB Memory - 1 Web and 1 Worker Dyno for free and even if you will pay there are some affordable prices and Heroku is managed service so they will take care of everything and you don't have to set up anything
I believe that should be a good start for you before pay for more expensive solutions
And that answer for your questions, Yes, EC2 is the cheapest for Amazon and Elastic beanstalk if you prefer for a more manged solution within Amazon
To deploy our nextJs website, we have been using AWS lambda: https://github.com/serverless-nextjs/serverless-next.js
It was amazingly simple to use it.
Unfortunately sometime the load of the page was very slow. It was from 2 seconds to 7 seconds.
It was also confirmed by google search console.
We could not find a way to really deep dive this issue and how we were able to solve this, but I suspect a cold start. After some research, AWS it was theoretically possible to solve it with concurrency:
https://aws.amazon.com/blogs/compute/new-for-aws-lambda-predictable-start-up-times-with-provisioned-concurrency/
But I could not managed to make it work, as it is a Lambda#Edge and it is also very expensive!
At http://nachonacho.com we focus on SEO, so the time to load the page was our biggest concern.
We finally decided to move to a simple AWS EC2.
Here you have the comparaison:
source: https://www.site24x7.com/
Light blue: EC2
Dark Blue: Lambda image image
Source: https://www.dareboost.com/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I need to integrate Zoho CRM to my react project(External application) and am new to react.Any one can give a solution? Is this integrating through back end or front end?
There is only one method which is through API's. Just go through the API docs. Api documentation has all the required information and also the sample json data. If they are not sufficient kindly try using Zoho postman collections.
Documentation: https://www.zoho.com/books/api/v3/
I understand that you wish to integrate React Project (External application) with Zoho CRM. However as now, There is no any method for direct integration of Zoho CRM - React Project. Hence, you can contact the API developer of ZOHO organisation & check the possibilities of completing the integration based on the business requirement using the API methods.
As previously mentioned you need to use the API's, the correct link for the CRM API is:
https://www.zoho.com/crm/catalyst/rest-api.html
A quote from Zoho:
"Zoho CRM offers the perfect collection of REST APIs and client libraries for building exciting new apps, for businesses of all sizes. The APIs are also secured by OAuth2.0 and API key methods to enable you to seamlessly integrate your Zoho CRM account with any third-party application.
Seamlessly push and receive information into your Zoho CRM account, or into any app that your team develops, using Zoho CRM API. Extract CRM data in JSON format, including any errors using simple HTTP methods."
I know this thread is quite old now but I still would like to contribute anyway.
Zoho's API is mostly used for extension apps or integrations; not if you want to add a user when the latter submut a form on your app; and their OAuth protocol is overkill, especially if you just want to add a new contact or whatever.
Plus their documentation is reaaaaaally organized (sarcasm obviously).
The simplest way to integrate any SPA with any Zoho apps is to use Zoho Flow (10$/mo or 25$/mo).
You can seamlessly create your own API using webhooks on it AND create workflow between any Zoho apps (CRM, Campaigns, Bookings and even third party apps.
You might be asking why should you pay an extra just to call their API?
Well it's just less of a nightmare, it's a small price to pay to make everything easy with Zoho
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
As I understand, App Engine Apps are OAuth 1 providers by default.
Is there a way to use OAuth2, e.g. with Google+ Sign-In or (mobile) chrome.identity API while still taking advantage of the GAE Users API and not having to implement a custom provider?
If not possible, what are the alternatives?
Can't say anything about what you refer to as "(mobile) chrome.identity API," but, inasmuch as I got to your question because of its google-chrome-app tag, I can answer for a Chrome App: Yes, it's possible to use the chrome.identity API to connect to an OAuth1 server (I've done it), but it's a lot of work, and you have to horse around with all of the OAuth1 handshaking. It's somewhat easier than trying to connect without chrome.identity, but not nearly as easy as connecting to an OAuth2 server, which is pretty much automatic.
Note that this is not a way of using OAuth2 to connect, which is what you literally asked. Rather, it is a way of using chrome.identity (for a Chrome App) to connect to an OAuth1 server.
Cloud Endpoints seem to be exactly the solution I need. They are not (yet?) a part of the official GAE for Go documentation, but can be found at Github.
Probably the best way to start is the examplary tictactoe app.
A quick test with the Google+ Sign-In button was successful (although with my probably wrong config it is performing multiple calls under the hood and some of them resulting in scoping errors).