I'm completely new to using Nextjs and want to learn it by building a project. I also want to use tRPC with it. I was reading the docs on using NextJS and tRPC and I learnt that there is a built in server in the /api under the pages folder. All the endpoints and server functions lives there.
I was wondering if I should be deploying all my server functions inside just the api folder or creating a separate custom Express server. It seems unscalable and weird to put all my server code into one client endpoint. To be clear I just want to do Authentication and CRUD functions but for future bigger projects, where such code would be split into microservices, would that then be deployed on a custom Express server instead?
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.
Is it possible to build a React Native App with a log-In screen that simulate/mirror a popup window of web-App having in mind that we don't have access neither to the server nor to the database of this web-app?
Thanks
I think the answer will be no, while this might technically possible.
You can of course mirror everything an already implemented login does, from the client side, including the HTTP requests to the server but usually that is very uncommon.
What someone usually does is
either use an existing pattern to talk to a backend service
or implement one (also on the backend side)
In general, you do not want to have any security features implemented in the frontend as it can be manipulated.
I already built a CMS website using ASP.NET MVC with SQLserver 2014,
and now i want to develop it into a mobile app using React Native, that I've been learning and playing with it's components for months now, but I don't know how connect the app with SQL server database. Is there anyway or solutions for connect React Native with SQL server database?
It is possible to connect a react native app with a remote MSSQL database using the react-native-mssql plugin (Android only at the moment).
Although it is best practice for security and performance to create an API interface there is nothing stopping you from connecting directly to the database if this suites your scope better than the API
You will have to create some sort of interface/API. The REST approach might be the correct one for your use case (manipulating data in a database).
Directly connecting to a SQL database from a mobile device is not recommended as the internet/network connection of a mobile device is prone to error and latency.
I would highly recommend you to make an API. The following points should explain you why:
Security (create an API with tokens or auth)
Error handling (your API should detect errors and send the correct headers)
Reusability (what if you want to connect another app or website to the database?)
Performance & API Management (you can control accesses and make statistics)
Once your API is finished, you can use it everywhere (fetch, axios, ...).
Im just in the process of putting together the base framework for a multi-tenant enterprise system.
The client-side will be a asp.net mvc webpage talking to the database through the asp.net web api through ajax.
My question really resides around scalability. Should I seperate the client from the server? i.e. Client-side/frontend code/view in one project and webapi in another seperate project server.
Therefore if one server begins (server A) to peak out with load/size than all need to do is create another server instance (server B) and all new customers will point to the webapi's on server B.
Or should it be all integrated as one project and scale out the sql server side of things as load increase (dynamic cloud scaling)?
Need some advice before throwing our hats into the ring.
Thanks in advance
We've gone with the route of separating out the API and the single page application. The reason here is that it forces you to treat the single page application as just another client, which in turn results in an API that provides all the functionality you need for a full client...
In terms of deployment we stick the single page application as the website root with a /api application containing the API deployment. In premise we can then use application request routing or some content-aware routing mechanism to throw things out to different servers if necessary. In Azure we use the multiple websites per role mechanism (http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx) and scale this role depending upon load.
Appearing to live in the same domain makes things easier because you don't have to bother with the ugliness that is JSONP or CORS!
Cheers,
Dean